Advanced SSL Topics - Implementing SSL/TLS Using Cryptography and PKI - page 436

close_notify
This message notifies the recipient that the sender will not send any more
messages on this connection. The session becomes unresumable if any connection
is terminated without proper close_notify messages with level equal to warning.
This was not widely implemented, and later versions of the specifi cation
rescinded this requirement. However, to be technically compliant with RFC
2246, this implementation ought to include this requirement when the negoti-
ated protocol version is 3.1.
There's also a theoretical problem with this implementation. The server
remembers the session ID and the master secret, and nothing else. What
happens if the client sends a hello request with the same session ID, but a
different set of cipher suites? What if, for example, the original session used
RC4/MD5, but the new client hello only includes AES/SHA-1? In this case,
it actually does work correctly because the master secret is just expanded
as many times as it needs to be to generate the appropriate keying material.
If the client is requesting the wrong cipher suite, though, you should just
abandon the connection because it's most likely that somebody is trying to
do something nasty.
A more robust server implementation should also keep track of which client
hello extensions are successfully negotiated and ensure that the second hello
request includes those same extensions. Depending on the negotiated extension,
omitting it on a resumption request might be a fatal error.
Avoiding Fixed Parameters with Ephemeral Key
Exchange
Chapter 6 states that after the server hello, the server should follow up with
a certifi cate for key exchange. Technically, this isn't always true. Recall from
Chapter 5 that although X.509 defi nes and allows the server to provide Diffi e-
Hellman parameters — Ys , p and g — in a certifi cate, the reality of Diffi e-Hellman
is that it works best when Ys is computed from a different secret value a for
each instance. If the key exchange parameters aren't in the certifi cate, is the
certifi cate strictly necessary?
As it turns out, no. There is a class of cipher suites referred to as ephemeral
cipher suites that don't expect a key to be supplied in a certifi cate at all. Instead,
the server sends a server key exchange message that contains the key exchange
parameters — normally a set of Diffi e-Hellman parameters. This way, each con-
nection gets its own, unique, key exchange parameters which are never stored
anywhere after the connection ends.