I'm referring to the Figure here.

TLS resume

Since the client already knows the session key and only the authenticated server can decrypt the session ticket, why can't the client start sending encrypted application data immediately after Client Hello, without waiting for server's Finished response?

2 Answers 2


The client knows the session master secret, but that's not yet the keys (plural!) which are derived using the nonces from ClientHello and ServerHello, so client has to wait for (roundtrip and) first server response anyway. See https://www.rfc-editor.org/rfc/rfc5246#section-6.3 and/or https://crypto.stackexchange.com/questions/1139/what-is-the-purpose-of-four-different-secrets-shared-by-client-and-server-in-ssl .

This also avoids MORE changes to the state machine, which although not known when 4507 was written have actually proven to be a source of vulnerability cf. FREAK and more at https://www.smacktls.com/ .


With Session Identifiers

There's no guarantee that the server remembers the session identifier. It may have fallen out of cache, or another server may be handling the request if SSL isn't terminated at the load balancer.

The client needs to know the server can resume the session before sending any data, because otherwise a the full handshake process will need to be repeated.

With Session Tickets

Even with Session Tickets there is no guarantee that the server will be able to resume the session. The session key may have changed, or the request may hit another server with a different, misconfigured session key.

Therefore, the client needs to wait for the FINISHED message before proceeding.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .