Cryptography Reference
In-Depth Information
to available certifi cates. Prefer the fi rst? Prefer the last? I know of no TLS client
that supports SNI but also sends more than one host name. OpenSSL, reason-
ably enough, regards it as an error if you pass more than one (prior to version
1.0, though, OpenSSL just ignores this).
The implementation presented in this topic is only capable of sending one certifi -
cate, so all this code does is print out the host name it receives from the client and
throws away the negotiated server name. A more robust implementation would,
of course, keep track of this. If the server recognized, accepted, and understood
the server name extension, it should include an empty server-name extension in
its own hello message, to let the client know that the extension was recognized.
This might prompt the client, for instance, to tighten its security requirements if
the received certifi cate was invalid. Of course, this wouldn't be useful against a
malicious server, but might expose an innocently misconfi gured one.
There are quite a few other extensions defi ned; RFC 3546 defi nes six, and
there are several others that are fairly common and are examined later.
Safely Reusing Key Material with Session
Resumption
Recall in Chapter 6 that the server was responsible for assigning a unique session
ID to each TLS connection. However, if you browse through the remainder of the
handshake, that session ID is never used again. Why does the server generate it, then?
SSL, since v2, has always supported session resumption. Remember that SSL
was originally conceived as an HTTP add-on; it was only later retrofi tted to
other protocols. It was also designed back when HTTP 1.0 was state-of-the-art,
and HTTP 1.0 required the web client — the browser — to close the socket con-
nection to indicate the end of request. This meant that a lot of HTTP requests
needed to be made for even a single web page. Although this was corrected
somewhat in HTTP 1.1 with pipelining of requests/keepalives, the fact still
remains that HTTP has a very low data-to-socket ratio. Add the time it takes to
do a key exchange and the corresponding private key operations, and SSL can
end up being a major drain on the throughput of the system.
To get a handle on this, SSL, and TLS, allow keying material to be reused
across multiple sockets. This works by passing an old session ID in the client
hello message and short-circuiting the handshake. This allows the lifetime of
the SSL session — the keying material that's used to protect the data — to be
independent of the lifetime of the socket. Regardless of the protocol used, this
is a good thing. After a 128-bit key has been successfully negotiated, depending
on the cipher spec, it can be used to protect potentially hundreds of thousands
of bytes of content. There's no reason to throw away these carefully negotiated
keys just because the top-level protocol itself has ended.
Search WWH ::
Custom Search