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

structures so, in TLS style, are prepended by their lengths. Here you can see,
they're each loaded into huge structures.
That's it; you already added support for the rest of the Diffi e-Hellman key
exchange in Listing 6-42. It was just a matter of getting the parameters to com-
plete the exchange.
You can use this on a live server. The cipher suites that are named DH_anon_
XXX work correctly with this code, as is, if the server supports the cipher suite.
Wait — “if the server supports them”? Why wouldn't the server support them?
Well, the name of the cipher suite offers a clue: DH_anon . This means that the
handshake is anonymous and no protection against man-in-the-middle attacks
is offered. How could you even check? There's no certifi cate, so there's no com-
mon name to compare to the domain name. Even if there were, there'd be no
signature to verify with a trusted public key.
Authenticating the Server Key Exchange Message
Strictly speaking, it's not necessarily the case that certifi cate messages and server
key exchange messages are mutually exclusive. Remember DSA certifi cates,
which didn't seem terribly useful because you couldn't use the DSA public key
for a key exchange? This is what they're useful for. A DSA certifi cate can provide
a public key that can be used to verify a signature over a set of ephemeral
Diffi e-Hellman parameters. This same certifi cate can include a verifi able com-
mon name and a trusted signature. The signature itself can even be an RSA
signature (which is fortunate, because I have yet to fi nd a certifi cate authority
that uses DSA to sign certifi cates).
In fact, the server can even send an RSA certifi cate before sending the server
key exchange message in support of a Diffi e-Hellman key exchange. You may
wonder why anybody would want to go to all this trouble if they've already
gotten an RSA certifi cate that can be used directly to do a key exchange, but
remember that Diffi e-Hellman achieves perfect forward secrecy. If RSA is used
for key exchange, and the server's private key is ever compromised, every com-
munication that is protected by that key is at risk.
Therefore, TLS defi nes another set of cipher suites called DHE_DSS_XXX for
Diffi e-Hellman with a DSA signature and DHE_RSA_XXX for Diffi e-Hellman with an
RSA signature. In both cases, the server key exchange is preceded by a certifi cate
bearing either a DSA public key or an RSA public key. (There are also DH_XXX
cipher suites that skip the server key exchange and expect the Diffi e-Hellman
parameters to appear in the certifi cate itself. As has been noted, this is rare).
As presented so far, though, this is still vulnerable to a man-in-the-middle
attack. You can verify that the certifi cate belongs to the site you believe you're
connecting to, but you can't verify that the key exchange parameters are the
ones that were sent by the server itself. The man in the middle can replace
the server's DH parameters with his own and you have no way of detecting this.