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

variable-length structures each of which includes their length. The receiver can
easily fi gure out where the record ends without being given an explicit length.
So, why restate the length? Well, the designers of the protocol anticipated,
correctly, that they might not have covered all the bases when they described
the handshake, so they allowed extra data to be appended to the client hello
handshake message. This is the reason why the code in the last chapter handles
the parsing of client hello messages differently than all the other messages. In
fact, if you tried using TCPdump to sniff your own browser's traffi c, you probably
noticed some of these extensions in its client hello messages. The TLS protocol
designers didn't, however, specify what form these extensions should take. This
wasn't actually standardized until years later, when RFC 3546 was drafted.
One of the most important of these standardized extensions is the server
name identifi cation (SNI) extension. It's common in today's Internet for low-
traffi c websites to share a hosting provider. There's no particular reason why a
blog that gets a few hundred hits a day needs a dedicated server; it can share
bandwidth (and costs) with several other sites on a single host. However,
this can pose problems for TLS. Each physical server on the Internet has its
own IP address, even if that physical host maps to multiple domains. So, for
instance, if a shared hosting provider had three hosts named www.hardware.com ,
www.books.com , and www.computers.com , all hosted from a single physical server,
each one would resolve to the same IP address.
This doesn't seem like a problem for TLS until you consider that TLS must
send a certifi cate whose domain name matches the requested domain name
to avoid the man-in-the-middle attack described in Chapter 5. However, TLS
doesn't know what domain was requested. Domain names are for people; com-
puters deal in IP addresses. Therefore, the client has to have some way to notify
the server that it should present the certifi cate for www.books.com rather than the
certifi cate for www.computers.com ; wildcard certifi cates don't help here, because
it's specifi cally prohibited to generate a wildcard of the form *.com — for obvi-
ous reasons.
Therefore, the client is optionally permitted to indicate with a client hello
extension the name of the host it's trying to connect to, and all modern browsers
do this. It's easy to add client hello extension parsing to the parse_client_hello
routine from Listing 7-9 as shown in Listing 8-1.
Listing 8-1: “tls.c” parse_client_hello with client hello extension support
static char *parse_client_hello( char *read_pos,
int pdu_length,
TLSParameters *parameters )
{
char *init_pos;
init_pos = read_pos; // keep track of start to check for extensions