Cryptography Reference
In-Depth Information
Figure 8-2 shows that the certifi cate, hello done, and key exchange messages
have all been elided. Because the client and the server have already negotiated
a master secret, there's no reason to resend these parameters.
client
server
client hello
server hello
change cipher spec
finished
change cipher spec
finished
Figure 8-2:
Shortened session resumption handshake sequence
Interestingly, when the handshake is shortened for session resumption, the
server sends the fi nished message fi rst, whereas for a normal handshake as
shown back in Figure 6-1, it's the client. This is a nod to effi ciency: The server
needn't wait for the client to send a key exchange before it computes its fi nished
message, so it can go ahead and pipeline all three of its messages in a single
burst if the server is willing to renegotiate.
Adding Session Resumption on the Client Side
What if the server isn't willing to renegotiate? According to the specifi cation,
the server should go ahead and silently begin a new handshake, and send its
certifi cate and hello done message. It's technically up to the client if it wants to
abort at this point, or go ahead and just negotiate a new session. In most cases,
the client wants to continue anyway. It's hard to imagine a scenario where a
client wouldn't want to negotiate a new session in this case. All TLS-based
software that I'm familiar with automatically does so, without prompting or
notifying the user. It's possible, though, that some particularly security-conscious
(say, military) software somewhere may say, “Hey, you gave me this session ID
two minutes ago, and now you're not willing to resume it? Something's wrong
here, I'm bailing,” and notify the user to investigate what could possibly be a
security breach.
Search WWH ::
Custom Search