AnsweredAssumed Answered

Read Timeout / Session Resumption IDs not accepted

Question asked by ckahlo on May 14, 2012
Latest reply on May 15, 2012 by Ivan Ristić

Hi there,

 

at first thanks for the great tool. It's rather interesting to get an overview over certain

TLS-based sites on the net as well as comparing our own stack with others.

Anyway we've got two problems:

 

https://www.ssllabs.com/ssltest/analyze.html?d=eid.vx4.nethttps://www.ssllabs.com/ssltest/analyze.html?d=eid%2evx4%2enet&s=89%2e146%2e218%2e58

https://www.ssllabs.com/ssltest/analyze.html?d=eid.vx4.nethttps://www.ssllabs.com/ssltest/analyze.html?d=eid%2evx4%2enet&s=89%2e146%2e218%2e58 says "Read Timeout", the only difference is that the stack triggers an embedded Tomcat

container. A onnection is etablished, handshake finishes successfully, we can't tell why

your system claims there is a read timeout. Could you please have a look?

 

https://www.ssllabs.com/ssltest/analyze.html?d=gw%2evx4%2enet&s=86%2e56%2e97%2e93

is the same TLS stack but only with a small HTTP-like server thread. (currently offline)

Session resuming has been implemented according to the RFCs and tested againt OpenSSL,

GnuTLS and several browsers. We've implemented the capability of long-term session resuming

which is working fine everytime someone connects with Google Chrome (long term, too).

However your system claims the ID is assigned but not accepted. I tracked all the Hello-

handshakes and I can't see any session ID submitted by your system. There is no session

identifier the server could use to resume an existing session. (the length field is zero)

I compared our logs with other servers listed as "Session Resumption: Yes", the behaviour is

the same.

 

Thanks for hints.

 

Best regards,

Christian

Outcomes