On Sat, Oct 01, 2016 at 04:05:32PM +0000, Daniel Janzon wrote: > Hm... Thanks, but I think I miss some piece of the puzzle. How does client > and server side session differ and how do they interact? I thought the TLS > session was always cached on the server side and all the client would have > to do was to send its session ID. Well, the client needs a lot more than just an "id". It needs to retain the session master key, protocol version, ... so that if the server agrees to resume the session the client can do so. With session tickets, all the storage is the client side, the client stores the server's session too, encrypted under a key that only the server knows. The client sends along the server's session back to the server in the sessiont ticket extension (RFC 5077). Client session caching is off by default, and in any case there's no automatic resumption. The client must call SSL_set_sesion() to trigger resumption. -- Viktor.
