Kai, On 1/12/2014 03:26, Kai Engert wrote:
Have you ever seen a TLS server that was incompatible with TLS session IDs?
No.
Do you agree this is bug on the server side?
Yes.
RFC 5246 section 7.3 says this : The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server MUST send ChangeCipherSpec messages and proceed directly to Finished messages. Once the re-establishment is complete, the client and server MAY begin to exchange application layer data. (See flow chart below.) If a Session ID match is not found, the server generates a new session ID, and the TLS client and server perform a full handshake. That last sentence is quite clear. The server is not compliant.
Should we attempt to identify which TLS toolkits and versions show this broken behaviour?
That would be a good shaming exercise.
At least NSS/PSM currently don't expect such behaviour. We don't automatically retry without a TLS session ID. Should we?
No. The fix belongs on the server side, not the client side. Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
