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

21:43:42.826911 IP localhost.40795 > localhost.8443: Flags [P.], ack 1125, win
274, options [nop,nop,TS val 103403 ecr 103396], length 75

0x0000: 4500 007f 5ad8 4000 4006 e19e 7f00 0001 E...Z.@.@.......

0x0010: 7f00 0001 9f5b 20fb c914 cc99 c8dd 046d .....[.........m
0x0020: 8018 0112 fe73 0000 0101 080a 0001 93eb .....s..........

0x0030: 0001 93e4 1603 0100 4610 0000 4200 4092 ........F...B.@.
0x0040: 7029 733b 045d dc11 0944 9189 588d a503 p)s;.]...D..X...

0x0050: 62ae 134b 81cc 5d85 aab1 bc7b 7855 b291 b..K..]....{xU..
0x0060: 8ca2 b919 7d3e ad58 9ba3 781b c6ee 564f ....}>.X..x...VO

0x0070: ac15 1de4 a83a 8a77 c7bb d112 f964 6f .....:.w.....do
21:43:44.786284 IP localhost.40795 > localhost.8443: Flags [P.], ack 1125, win

274, options [nop,nop,TS val 103893 ecr 103403], length 75
0x0000: 4500 007f 5ad9 4000 4006 e19d 7f00 0001 E...Z.@.@.......

Certificate
Verify

0x0010: 7f00 0001 9f5b 20fb c914 cce4 c8dd 046d .....[.........m

0x0020: 8018 0112 fe73 0000 0101 080a 0001 95d5 .....s..........
0x0030: 0001 93eb 1603 0100 460f 0000 4200 4016 ........F...B.@.

0x0040: 7c3c 9b7a a26d 300d b155 b494 ef9e f96c |<.z.m0..U.....l
0x0050: a09b 262a bab7 409f dc93 79e1 cc4d 3565 ..&*..@...y..M5e

0x0060: 2f55 c50a ed35 8c8c 1d49 ab5e 4678 cd58 /U...5...I.^Fx.X

0x0070: 4d01 aca8 d312 7b74 21ff b2eb 5595 bd M.....{t!...U..

The client certifi cate is followed fi rst by a key exchange — in this case, an
ordinary RSA key exchange of the sort in Chapter 6 — and then a certifi cate
verify message. This is an RSA signature of the MD5, followed by the SHA-1,
hash of all of the handshake messages that preceded this message. The remainder
of the handshake proceeds as normal, assuming the server accepts the certifi cate
and its verifi cation.
You may have been struck by the utility of the server indicating a list of cer-
tifi cate authorities it trusts. Why can't the client do the same thing? Although
TLS 1.0 itself doesn't allow for this, RFC 3546 defi nes client hello extension 3,
trusted CA keys , to pass a list of CA identities that it trusts; if the server doesn't
have any certifi cates signed by any of the trusted CAs it can just abort the con-
nection and not waste time completing the handshake.
It's also permissible, if the client and server are both able to negotiate it via
client hello extension 4, client certifi cate URL , for the client to pass, rather than an
entire certifi cate in its certifi cate message, a URL from which the server should
download its certifi cate. This isn't a security risk, because the client follows up
with the certifi cate verifi cation message after the key exchange; this proves that
the client is in possession of the certifi cate's private key and that the client is
not replaying an older verifi cation message.