TLS: could the resumed session and the original session in the same connection?

Question

In tls 1.2, we know that every connection is associated with one session, and session resumption can be used to establish a new connection quickly by using the session ID of the original session of an old connection, what's more, the resumed session is not a new session. However, if it is true that there is only one session in one connection, why TLS can renegotiate within an existing connection to create new session, and can we use session resumption to refresh keys in an existing connection since the resumed session is not a new session?

Answer 1

There is no problem in having several sessions on a single connection -- of course not simultaneously, but if, within a connection, a new handshake is performed (a "renegotiation"), then that new handshake may resume an existing session, including the one which was active before that new handshake. As for any session resumption, this works only if both the client and server agree, and remember the session parameters in some way (if session tickets are used, the server's memory may actually be offloaded on the client).

---

However, this raises the question of why you would renegotiate, if that is only to keep the current session running. A common case of renegotiation is when IIS (Microsoft's Web server) is configured to use certificate-based client authentication. IIS, by default, uses client certificates on a per-directory basis, not for the whole server; thus, things go normally the following way:

• The client connects to the server. A "normal" handshake is performed, with no request for a client certificate.
• Once the handshake is done, the client sends the HTTP request. At that point, the server learns the exact target path for the request (up to that point, the server knew, at best, the intended server name, through the SNI extension, but not the full path).
• If the target path is configured to use client certificates, then the server buffers the request, and initiates a new handshake (HelloRequest and so on).
• The client responds with a ClientHello and normally tries to resume the ongoing session. However, the server refuses, and instead initiates a new session. This is so because the whole point (in that situation) of starting a new handshake is to ask for a client certificate, and this can happen only with a full handshake, i.e. with a new session.
• Once the new handshake is completed and the client authenticated, the buffered request is processed (this is safe as long as client and server implement the secure renegotiation option, which was designed exactly for that usage).

The point I am making here is that the client really tries to resume the same session, as is allowed by standards, and the server rejects the resumption because it triggered a new handshake precisely so that a new session may be opened. In practice, performing a new handshake but resuming the same session can be done by people who feel that they must "renew keys" for some ill-justified reason; we are more in the domain of Tradition than Science here. Conceptually, doing a new handshake with the same session could be used as a way to exchange some new TLS extensions, but there currently are hardly any defined extension for which such a thing makes sense (but extensions are, by definition, open-ended, so this may be useful some day).