0

I couldn't find a satisfactory answer to this question anywhere. Hoping to get some respite here!

Client and Server engages in handshake, decides upon a cipher suite to use say X.

Now, next time client sends a request (regular), it will be encrypted and then send.

Consider the diagram :-

Request response

Here, in Transaction1 cipher suite is negotiated? Request is sent in Transaction2. As http is a stateless protocol, Transaction2 will have no knowledge of Transaction1 then how does it know what was negotiated? Is it using session OR this information is sent with each request? In either case request has to be decrypted to findout sessionid OR cipher suite. So i dont think it is done either way.

Ouney
  • 101
  • 1
  • HTTP sessions and TLS/SSL sessions are completely different things. A single TLS session can be kept open and used for multiple HTTP transactions. – EEAA Apr 13 '16 at 18:58

1 Answers1

1

When TLS session caching is used, the session ID is provided by the client in the clear, as part of the ClientHello message which starts the TLS handshake. (Thus decryption is not needed to find out the TLS session ID.) The server can then check its cache for that session ID, and find the previously negotiated SSL session information cached for that session ID, which will include (among other things) the cipher suite negotiated.

If, on the other hand, a TLS session ticket is used, then the TLS session information (including cipher suite) is encrypted by the server, and cached by the client (similar to a cookie). When the client performs a TLS handshake next with that server, it will send this encrypted "session ticket"; the server decrypts the ticket, and obtains (among other things) the cipher suite negotiated.

Hope this helps!

Castaglia
  • 3,349
  • 3
  • 21
  • 42