Creating a Network of Trust Using X.509 Certifi cates - Implementing SSL/TLS Using Cryptography and PKI - page 223

algorithms discussed in Chapter 4 — and the client must verify this signature.
Such a signed public key is called a certifi cate , and a trusted intermediary respon-
sible for signing certifi cates is called a certifi cate authority (CA) . The client must
have access to the public key of the CA so that it can authenticate the signature
before accepting the key as genuine. Web browsers have a list of trusted CAs
with their public keys built in for just this purpose.

client attacker

ignore request, issue own
request

server

request public key

request public key

replace with own public
key

send public key

encrypt a symmetric
session key using the
public key

send public key

decrypt session key using
private key; re-encrypt using
server's public key and re-send

send encrypted session key

send encrypted session key

acknowledge

acknowledge

normal conversation
begins, everything is
intercepted and first
decrypted and then re-
encrypted by attacker

Figure 5.2: Man-in-the-middle attack

This buys a bit of security against a man-in-the-middle attack, but not much.
After all, if the server can get a certifi cate signed by the trusted CA, you must
assume that the attacker, if suffi ciently motivated, could do so too. He could
present himself to the CA as a legitimate business, for example. This makes his
job a bit more diffi cult, but hardly insurmountable.
What you really need is some way to associate the public key with the server
you're connecting to. Thus, a properly formatted certifi cate needs to have not
only the public key of the server included, but also the domain name of the
server that the public key belongs to, all signed by the trusted intermediary.
This foils the man-in-the-middle attack. The client requests a certifi cate from
the server, and the man in the middle replaces it with his own. The client
then validates the attacker's certifi cate as legitimate — it's signed by a trusted
CA — but observes that the domain doesn't match that of www.server.com , as
expected. Nor can the attacker forge a certifi cate with the domain name www
.server.com — this is protected by the digital signature. If he obtains a digitally
signed certifi cate from the CA, with the domain name www.attacker.com , and
then changes his own domain in the certifi cate to www.server.com , the hash