|
|
6.4. SSL on the WireLet's look at some SSL exchanges. First, we look at a "normal" SSL session that corresponds to the packet flow depicted in Figure 6.2. Many of the SSL messages contain a great deal of information, so we examine them one at a time. Handshake MessagesSSL uses handshake messages to negotiate cipher suites and to exchange keying material. All handshake messages begin with a simple 4-byte header (Figure 6.5) that gives the handshake type and the length of the message, exclusive of the header. The values for the handshake types are given in Figure 6.6. Figure 6.5. The Handshake Header
Because several layers of encapsulation are involved with the handshake messages, it's beneficial to review what that encapsulation looks like. Figure 6.7 shows the layout of an IP datagram that is carrying an SSL handshake message. The sizes given for the IP and TCP headers assume that neither has any options. Recall that the HMAC and padding will not be present until after a ChangeCipherSpec message is sent. Figure 6.7. SSL Handshake Message Encapsulation
The Client HelloThe message format for the ClientHello is shown in Figure 6.8. Figure 6.8. The ClientHello Message
The major and minor version are the latest version of SSL that the client understands. This allows the server to determine which protocol version to use for the rest of the session. Both the client and server will contribute some random data that will be used for key generation. The random data changes with each ClientHello or ServerHello, helping prevent replay attacks. The random data field comprises a standard UNIX 4-byte time valueseconds since midnight, January 1, 1970and 28 random bytes. The session ID is used to resume a previous session, thereby sidestepping the key-generation phase, which requires considerable resources. We'll see an example of its use later. In the current exchange, it is not used, so the session ID length is set to 0. Each cipher suite is represented by a 2-byte number (see Figure 6.1). The client sends a list of the cipher suites it is prepared to support, sorted in order of preference.
None of the SSL versions support compression; RFC 3749 [Hollenbeck 2004] describes compression for TLS. Some proprietary implementations and OpenSSL also support compression, but we hardly ever see this capability used. Thus, the compression list contains a single byte of 0, representing NULL. Now let's look at a ClientHello message. To capture the data, we use ssldump, a tool developed by Eric Rescorla for SSL development, debugging, and his book [Rescorla 2001]. The ssldump program is similar to tcpdump but is specialized to decode SSL packets. Here is the first message, a ClientHello, in the SSL handshake: 1 1 0.0021 (0.0021) C>SV3.0(47) Handshake
ClientHello
Version 3.0
random[32]=
3e 5e 6f d3 6b a3 1e ca 45 3f 3a 87 50 92 8e 6b
c4 9f 74 1e b4 45 b8 44 e7 41 72 31 36 fd e8 63
cipher suites
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_IDEA_CBC_SHA
compression methods
NULLThe first line tells us that this is a handshake message from the client to the server (C>S), that it is a version 3.0 message (3.0) of 47 bytes. The first 1 tells us that this is the first connection in the capture, and the second 1 tells us that this is the first record in this connection. The second two fields are the time since the beginning of the capture of this record, and the time since the last record. The next two lines tells us that this is a ClientHello and that the client understands version 3.0 and below. We also see the client's random number and that the client is willing to use the two cipher suites SSL_RSA_WITH_3DES_EDE_CBC_SHA and SSL_RSA_WITH_IDEA_CBC_SHA. As expected with SSL, the client is unwilling to use any compression methods and lists NULL as the only method. The Server HelloAs shown in Figure 6.9, the format of ServerHello is similar to that of the ClientHello, except that instead of lists for supported cipher suites and compression methods, only the single chosen value for each is specified by the server. Figure 6.9. The ServerHello Message
The server's response to our previous ClientHello is 1 2 0.0033 (0.0012) S>CV3.0(74) Handshake
ServerHello
Version 3.0
random[32]=
3e 5e 6f d3 f8 e3 4d 89 e7 9d 2d 5f 0e b9 8f f8
77 44 45 95 cb 69 ae 4e 4a 9b c8 29 29 76 da b4
session_id[32]=
14 17 3a 80 5e 1d 50 9f 46 1c 38 12 2f e6 d8 3d
b6 6c 18 59 8b 00 f4 3d a1 1c 2f 22 72 80 37 50
cipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA
compressionMeth NULLThe server has agreed to the version 3.0 protocol and has chosen to use the SSL_RSA_WITH_3DES_EDE_CBC_SHA cipher suite and NULL compression method. The server has contributed its own random data and has specified a session ID. The client can use this session ID to resume the session later. We'll see an example of this shortly. CertificateThe next message is the server's certificate. This message is usually a chain of certificates, with the first being the server's own certificate, followed by any authenticating certificates from certificate authorities.
The Certificate message is shown in Figure 6.10. Figure 6.10. The SSL Certificate Message
The output from ssldump merely reflects the fact that the server has sent its certificate to the client: 1 3 0.0033 (0.0000) S>CV3.0(571) Handshake
CertificateThe Server Hello DoneThe next message in our typical SSL session is the ServerHelloDone. Recall that it is used to tell the client that the server has finished its hello sequence and that the client may begin the key-transfer process. The ServerHelloDone message consists merely of a handshake header with a type of 14, as shown in Figure 6.11. Figure 6.11. The ServerHelloDone Message
As with the Certificate message, ssldump merely notes that the message was sent by the server: 1 4 0.0033 (0.0000) S>CV3.0(4) Handshake
ServerHelloDoneThe Client Key ExchangeAfter the server sends its ServerHelloDone message, the client responds with a ClientKeyExchange message. This message contains what SSL calls the PreMasterSecret encrypted with the server's public key that was in its certificate.
Figure 6.12 shows the format of the ClientKeyExchange message. The PreMasterSecret is composed of the client's version and 46 cryptographically secure random bytes. Both sides use the PreMasterSecret along with the random bytes from the client and server hellos to generate the MasterSecret, which in turn is used to generate the various keys used by the encryption and digest algorithms. Figure 6.12. The Client Key Exchange Message
The message length field specifies 128 bytes. The enlargement from 48 to 128 bytes is the result of the RSA encryption. One other important point is that the TLS implementation is slightly different. In TLS, the EncryptedPreMasterSecret is defined as a variable array of between 0 and 216 1 bytes and therefore has a 2-byte length prefix. We see the expansion of the EncryptedPreMasterSecret to 128 bytes in the ssldump output for the ClientKeyExchange message: 1 5 0.0052 (0.0018) C>SV3.0(132) Handshake
ClientKeyExchange
EncryptedPreMasterSecret[128]=
cb d0 b0 29 2a 7d 0b 52 52 2b 9a 63 49 62 28 ce
cf 22 cb 65 c3 0b 2b f6 9b a4 d0 50 20 a6 a3 cd
c8 73 34 19 c9 cd b7 87 2b 9f 4b 28 b0 86 64 4a
da 67 8e d4 49 9a 7e b0 41 60 29 46 c1 d8 b6 6c
13 47 1d 3d cb 39 e7 5b f2 dc 11 19 dc 45 96 a6
9b 43 36 fe 69 70 41 25 a8 ff 69 50 f9 68 f3 e3
c6 a5 a4 45 ae 1f 8a ee 25 e0 82 ae a4 21 f1 ff
ea 3b 2b a1 d1 a3 45 19 f0 55 b6 a3 76 22 36 20The ChangeCipherSpec MessageAfter the ClientKeyExchange message, both sides can generate keys for the rest of the session. The next message in our typical session is a ChangeCipherSpec, by which the client indicates that it will henceforth use the new cipher suite: 1 6 0.0052 (0.0000) C>SV3.0(1) ChangeCipherSpec Recall that the ChangeCipherSpec message is one of the four basic record types (Figure 6.4) and is therefore not a Handshake message. The format of the message is just an SSL record (Figure 6.3) with a type of CHANGE_CIPHER_SPEC (20) and a data field of the single byte of value 1. The Finished MessageFinally, the client indicates that it is finished with the handshake by sending a Finished message. This message is encrypted as promised by the previous ChangeCipherSpec message. Figure 6.13 shows the format of the Finished message. Figure 6.13. The Finished Message
The two HMACs are computed over all the previous handshake messages, verifying that the unauthenticated messages were not tampered with. Because the Finished message is encrypted, we normally wouldn't be able to see its contents, but we used our own certificate for the session and therefore know the private key. With access to the private key, ssldump is able to decrypt the PreMasterSecret and generate its own set of keys. Thus, we can see the values of the HMACs in the client's Finished message: 1 7 0.0052 (0.0000) C>SV3.0(64) Handshake
Finished
md5_hash[16]=
09 92 f4 f1 16 c6 17 a8 39 a2 c8 c8 44 89 7f df
sha_hash[20]=
ae 15 cc e0 8e 5f 13 c3 e2 1e 9c 10 5f 30 8c 24
cf 6a 83 5eNote the discrepancy between the message length from the SSL record header (64) and decoded contents (40). The difference is the (SSL record) HMAC and the padding added to fill out the 3DES block size. The server next sends its own ChangeCipherSpec and Finished messages, and the session is ready for the data transfer stage: 1 8 0.0141 (0.0089) S>CV3.0(1) ChangeCipherSpec
1 9 0.0141 (0.0000) S>CV3.0(64) Handshake
Finished
md5_hash[16]=
62 57 8c f7 1e 4b 88 81 8b 92 2b 73 dd ce 2e d3
sha_hash[20]=
a8 6a b6 04 f1 ed 67 ce d1 c9 aa 1a 82 60 8c f3
ef 00 61 c4The client and server exchange application data: 1 10 2.7108 (2.6966) C>SV3.0(24) application_data
-----------------------------------------------------------
-----------------------------------------------------------
1 11 2.7108 (0.0000) C>SV3.0(32) application_data
-----------------------------------------------------------
hello
-----------------------------------------------------------
1 12 2.7125 (0.0016) S>CV3.0(24) application_data
-----------------------------------------------------------
-----------------------------------------------------------
1 13 2.7125 (0.0000) S>CV3.0(32) application_data
-----------------------------------------------------------
hello
-----------------------------------------------------------Record 10 from the client and record 12 from the server do not appear to have any data. These records are called empty fragments and are inserted by OpenSSL as a countermeasure against a vulnerability in version 3 and TLS involving CBC ciphers. Recall that the SSL data transfer is indistinguishable from a normal TCP data transfer except that the TCP payload appears to be random data. The following tcpdump output is the trace of the preceding four application data records. Notice that there is no obvious indication that this is an SSL session. In lines 1.4, 1.6, 2.4, and 2.6, we can see the SSL record headers (in boldface). In line 1.6, for example, we see that the SSL record type is 0x17 (2310), indicating that this is application data (see Figure 6.4). The next 2 bytes are the version (3.0), followed by the length, which is 0x0020 (3210). The rest of the SSL record is encrypted, so we can't see the data. Observe that SSL records 10 and 11 were sent in a single TCP segment, as were records 12 and 13. 1 15:06:45.828412 127.0.0.1.1526 > 127.0.0.1.5001: P 265:331(66) ack 740 win 57344 <nop,nop,timestamp 2879023 2878753> (DF) 1.1 4500 0076 5b26 4000 4006 e159 7f00 0001 E..v[&@.@..Y.... 1.2 7f00 0001 05f6 1389 d87a 3458 d386 d023 .........z4X...# 1.3 8018 e000 c246 0000 0101 080a 002b ee2f .....F.......+./ 1.4 002b ed21 1703 0000 1848 2ce9 04b5 4071 .+.!.....H,...@q 1.5 f2df faf1 2ab4 eb6f e012 3e68 cf5b db2f ....*..o..>h.[./ 1.6 5217 0300 0020 7821 6be6 0b08 3567 559c R.....x!k...5gU. 1.7 8d62 74e8 3af8 7f1d 6557 3e82 52f8 7fc1 .bt.:...eW>.R... 1.8 fff8 2b0f 94e6 ..+... 2 15:06:45.830097 127.0.0.1.5001 > 127.0.0.1.1526: P 740:806(66) ack 331 win 57344 <nop,nop,timestamp 2879023 2879023> (DF) 2.1 4500 0076 5b29 4000 4006 e156 7f00 0001 E..v[)@.@..V.... 2.2 7f00 0001 1389 05f6 d386 d023 d87a 349a ...........#.z4. 2.3 8018 e000 d64b 0000 0101 080a 002b ee2f .....K.......+./ 2.4 002b ee2f 1703 0000 18de 1c26 9d57 55f4 .+./.......&.WU. 2.5 c411 2363 93af e9fc c4b4 1fd8 7956 c557 ..#c........yV.W 2.6 0517 0300 0020 7493 732e b754 89c4 40d1 ......t.s..T..@. 2.7 cd48 6bff 8db9 46dd 6b52 4605 1988 c942 .Hk...F.kRF....B 2.8 52c5 e1b1 0b24 R....$ Alert Messages and Closure NotificationThe final type of record is the Alert message. It consists of 2 bytes carried in the SSL record, as shown in Figure 6.14. Figure 6.14. The Alert Message
The level field indicates the severity of the alert. It can be either WARNING (1) or FATAL (2). Description is an alert code that indicates what type of alert this is. The values and the protocol versions that support them are given in Figure 6.15.
1 14 4.9688 (2.2563) C>SV3.0(24) Alert
level warning
value close_notify
1 15 4.9690 (0.0001) S>CV3.0(24) Alert
level warning
value close_notify
1 4.9723 (0.0032) C>S TCP FIN
1 4.9726 (0.0002) S>C TCP FINResumed SessionsWe saw earlier that the server sent the client a session ID in its ServerHello message. The client can use this ID to bypass much of the handshake negotiation in subsequent sessions. Although this may seem to have little utility, it arises in a natural way. After a Web server replies to a browser's request for a Web page, it typically closes the TCP connection to indicate an EOF (see Tip 16 of ETCP). If, as is typical of the financial transactions protected by SSL, the client makes another request, being able to resume the session saves time and resources. Although this may not amount to much for the client, it can be significant for busy Web servers. A resumed session differs from a normal session only in the handshake, as shown in Figure 6.16. The client asks to resume the session by including the session ID from the last session. The server, which has cached the state of that session, agrees by returning the same session ID. We see that the server does not send its certificate and that the client does not send the PreMasterSecret. Both sides will use the existing MasterSecret to generate new keys. Because the new random data from both sides will be used to generate these keys, they will be different from those in the previous incarnation of the session. Figure 6.16. Data Flow for a Resumed Session Handshake
The following exchange is a resumption of the previous one: 2 1 0.0011 (0.0011) C>SV3.0(79) Handshake
ClientHello
Version 3.0
random[32]=
3e 5e 6f db 15 04 57 00 03 5a a8 ae 30 89 8b 6c
e9 21 e6 0e 08 23 18 cc 5a 9c 4e bb 20 36 aa f9
resume [32]=
14 17 3a 80 5e 1d 50 9f 46 1c 38 12 2f e6 d8 3d
b6 6c 18 59 8b 00 f4 3d a1 1c 2f 22 72 80 37 50
cipher suites
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_IDEA_CBC_SHA
compression methods
NULL
2 2 0.0016 (0.0004) S>CV3.0(74) Handshake
ServerHello
Version 3.0
random[32]=
3e 5e 6f db 3c 45 6f 38 d4 1e 83 79 91 fe 84 6a
f3 db 09 6e 23 aa 10 96 e0 63 cd c0 81 15 5c 55
session_id[32]=
14 17 3a 80 5e 1d 50 9f 46 1c 38 12 2f e6 d8 3d
b6 6c 18 59 8b 00 f4 3d a1 1c 2f 22 72 80 37 50
cipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA
compressionMethod NULL
2 3 0.0016 (0.0000) S>CV3.0(1) ChangeCipherSpec
2 4 0.0016 (0.0000) S>CV3.0(64) Handshake
Finished
md5_hash[16]=
c1 c7 66 99 cd 32 9a 20 7d d6 e2 82 e1 67 1f a0
sha_hash[20]=
5b 04 2f df a1 bb 47 75 44 35 20 62 4d 56 e1 66
54 54 38 b9
2 5 0.0018 (0.0002) C>SV3.0(1) ChangeCipherSpec
2 6 0.0018 (0.0000) C>SV3.0(64) Handshake
Finished
md5_hash[16]=
5c 5b 69 d3 d1 59 86 7f 2a d3 40 3e a1 6e 0f b5
sha_hash[20]=
48 ac 60 8e 45 39 b1 c0 3e b1 86 1f eb ec 9e 89
5d fa d7 f7
2 7 4.5853 (4.5834) C>SV3.0(24) application_data
-----------------------------------------------------------
-----------------------------------------------------------
2 8 4.5853 (0.0000) C>SV3.0(40) application_data
-----------------------------------------------------------
hello again
-----------------------------------------------------------
2 9 4.5870 (0.0016) S>CV3.0(24) application_data
-----------------------------------------------------------
-----------------------------------------------------------
2 10 4.5870 (0.0000) S>CV3.0(40) application_data
-----------------------------------------------------------
hello again
-----------------------------------------------------------
2 11 6.2698 (1.6828) C>SV3.0(24) Alert
level warning
value close_notify
2 12 6.2700 (0.0001) S>CV3.0(24) Alert
level warning
value close_notify
2 6.2730 (0.0029) C>S TCP FIN
2 6.2732 (0.0002) S>C TCP FINVersion 2 Client HelloIn order to interoperate with version 2 servers, many browsers will start the handshake with a version 2 ClientHello message that indicates their ability to support version 3. If the server also supports version 3, it will respond with a version 3 ServerHello, and the rest of the session will take place using the version 3 protocol. If the server responds with a version 2 ServerHello, the browser will continue to use the version 2 protocol.
The version 2 SSL Record and ClientHello format is shown in Figure 6.17. Figure 6.17. The Version 2 Record and ClientHello Format
The following session is between a Mozilla 1.2 browser and a bank's secure Web site. We can't tell for sure which Web server the bank is using, because the traffic is encrypted, but the rest of the bank's Web site is hosted by Netscape-Enterprise Server. 1 1 0.0512 (0.0512) C>S SSLv2 compatible client hello
Version 3.1
cipher suites
SSL2_CK_RC4
SSL2_CK_RC2
SSL2_CK_3DES
SSL2_CK_DES
SSL2_CK_RC4_EXPORT40
SSL2_CK_RC2_EXPORT40
TLS_RSA_WITH_RC4_128_MD5
Unknown value 0xfeff
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Unknown value 0xfefe
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
1 2 0.1077 (0.0564) S>CV3.0(1286) Handshake
ServerHello
Version 3.0
random[32]=
00 00 07 98 0d 95 99 80 1f 6c d2 f9 20 9a ed cf
f6 5c 95 f8 b1 d5 3f cb b8 49 4d a5 c8 89 63 99
session_id[32]=
36 79 c6 ba c7 40 1b dc f3 0b 95 a7 e5 ed b9 e5
60 65 f0 48 85 25 80 b2 f9 e4 33 18 b7 cf 64 7d
cipherSuite SSL_RSA_WITH_RC4_128_MD5
compressionMethod NULL
Certificate
ServerHelloDone
1 3 0.1229 (0.0152) C>SV3.0(132) Handshake
ClientKeyExchange
EncryptedPreMasterSecret[128]=
c2 61 ad 31 a3 3e 2e 8b 6f 77 81 e1 8a 76 b1 20
76 54 fa 11 57 14 e7 4e f8 85 c1 2e a9 99 eb 5c
7b d5 54 04 7c 04 70 0b b7 41 39 0c c6 78 05 39
ce 83 40 31 15 95 9d 7f 03 c7 06 3d a8 8b 13 5d
4a 82 8a 53 1a 06 e6 25 f3 29 14 21 04 1b a0 f4
bb bd 00 b3 ca 60 11 07 5e 36 ba 20 1b f4 05 b6
4e e7 b2 f2 91 14 c0 68 78 af 23 83 8f 9e 30 3a
63 a6 2b 20 13 3c ca 76 ab 85 7e dd 09 64 7e 8a
1 4 0.1229 (0.0000) C>SV3.0(1) ChangeCipherSpec
1 5 0.1229 (0.0000) C>SV3.0(56) Handshake
1 6 0.1828 (0.0599) S>CV3.0(1) ChangeCipherSpec
1 7 0.1828 (0.0000) S>CV3.0(56) Handshake
1 8 0.1842 (0.0013) C>SV3.0(473) application_data
1 9 0.2371 (0.0529) S>CV3.0(253) application_data
1 10 0.2399 (0.0027) S>CV3.0(18) Alert
1 0.2409 (0.0009) S>C TCP FIN
1 11 0.2459 (0.0049) C>SV3.0(18) Alert
1 0.2460 (0.0000) C>S TCP FINMozilla sends a version 2 ClientHello but offers to negotiate at version 3.1 (TLS) or lower. The cipher suites beginning with SSL2_ are those that are defined in version 2. The others are the normal version 3.0/3.1 cipher suites. The server responds with a version 3 ServerHello, saying that it will negotiate with version 3 using RSA, 128-bit RC4, and MD5. The rest of the session proceeds in a normal version 3 manner. SSL record 2 contains three handshake messages: ServerHello, Certificate, and ServerHelloDone. This behavior is normal. An SSL record can contain multiple messages as long as they are all the same record type: Handshake, in this case. It is also legal for a single message to be split across more than one SSL record, but this does not happen in practice [Rescorla 2001]. Client AuthenticationIt is possible for the server to require that the client authenticate itself just as the server must. To do this, the server issues a CertificateRequest, and the client replies with its certificate and a CertificateVerify message. Figure 6.18 shows the handshake portion of the data flow. The handshake begins with the normal exchange of hello messages, followed by the server's certificate. Then, instead of sending the ServerHelloDone, the server sends a CertificateRequest, asking the client to send its own certificate to the server. This is our first example of the necessity for the ServerHelloDone message; the server has an extra message to send before it is done with its hello sequence. Figure 6.18. Client Authentication Handshake
The client responds with Certificate and ClientKeyExchange messages. At this point, both sides can generate their keying material. Before sending the ChangeCipherRequest, however, the client sends one additional messagethe CertificateVerify messagea digest of the previous handshake messages, encrypted with the client's private key. The server then decrypts the message with the client's public key from its certificate and verifies that the digest is correct. In this way, the client verifies that it is the owner of the certificate, as only the owner will know the private key. This is important, because the certificate is sent unencrypted and could easily be captured and reused by an attacker. As before, the random values in the ClientHello and ServerHello messages prevent a replay attack by ensuring that the digest will differ from any other handshake between the peers, even if everything else is the same. We can learn a little more about these messages by watching them on the wire.
1 1 0.0050 (0.0050) C>S Handshake
ClientHello
Version 3.0
cipher suites
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_DHE_DSS_WITH_RC2_56_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
SSL_RSA_EXPORT1024_WITH_RC4_56_MD5
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5
compression methods
NULL
1 2 0.0056 (0.0005) S>C Handshake
ServerHello
Version 3.0
session_id[32]=
1c f7 13 97 e5 fb e4 7f d8 43 4c 78 dc 7b 68 22
86 a2 e1 f2 04 d5 bd c6 7b 45 3d 91 11 64 36 4d
cipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA
compressionMethod NULL
1 3 0.0056 (0.0000) S>C Handshake
Certificate
1 4 0.0056 (0.0000) S>C Handshake
CertificateRequest
certificate_types rsa_sign
certificate_types dss_sign
ServerHelloDone
1 5 0.0179 (0.0122) C>S Handshake
Certificate
1 6 0.0179 (0.0000) C>S Handshake
ClientKeyExchange
1 7 0.0179 (0.0000) C>S Handshake
CertificateVerify
Signature[128]=
87 d7 11 5e fa fa ed e1 87 d5 25 5e 19 71 35 e6
c3 c8 5f c6 ed de ee b8 c1 b6 9c 50 97 45 33 b2
5f c7 6f 91 d6 db 7c a4 ed 05 b0 1d 16 8a d4 37
4c c1 50 92 61 6b fd 3d 1c 71 ea e5 d1 a5 d5 89
8f d4 b5 c1 d2 d7 ed 33 37 82 b4 93 9c e1 07 3a
a9 dd d5 20 82 2e b0 b5 68 20 c6 e3 2d d5 b4 59
14 74 dc 79 a7 73 13 88 af a0 75 1d 5c 81 9b 59
c9 67 3a e2 61 50 b8 f6 7e 62 64 7b 6f 55 09 d0
1 8 0.0179 (0.0000) C>S ChangeCipherSpec
1 9 0.0179 (0.0000) C>S Handshake
1 10 0.0242 (0.0063) S>C ChangeCipherSpec
1 11 0.0242 (0.0000) S>C HandshakeIn record 4, the CertificateRequest includes a list of certificate types that the server is willing to accept. In this case, the server will accept either an RSA or a DSS signed certificate. Figure 6.19 shows the format of the CertificateRequest. Figure 6.19. The CertificateRequest
As shown in the figure, the server can also specify which certificate authorities it is willing to accept. This capability was not used in the previous exchange. Diffie-Hellman Key ExchangeUntil now, all our example sessions have used RSA key exchange. With RSA key exchange, the client generates a random PreMasterSecret and encrypts it with the server's public key, which it obtains from the server's certificate. It is also possible to use Diffie-Hellman to exchange keys. With Diffie-Hellman, the process is different. The usual method is for the server to generate a Diffie-Hellman key, sign it with its DSS key, and send it to the client. The client also generates a Diffie-Hellman key and sends it to the server. Both sides then compute the Diffie-Hellman shared secret from these keys and use it as the PreMasterSecret. The server can also use a permanent Diffie-Hellman key, in which case the key is included with the server's certificate. We see this exchange of messages in Figure 6.20. Note that the server sends its Diffie-Hellman key in the ServerKeyExchange message right after sending its certificate. Figure 6.20. Diffie-Hellman Key Exchange
The format of the ServerKeyExchange is given in Figure 6.21. In addition to the Diffie-Hellman key, the message contains the prime modulus and group generator to be used with the Diffie-Hellman exchange. Figure 6.21. ServerKeyExchange (Diffie-Hellman)
We can see the messages by examining the output of ssldump: 1 1 0.0041 (0.0041) C>SV3.0(83) Handshake
ClientHello
Version 3.0
random[32]=
3e 7e 03 ef c9 db 73 e5 3f 85 6d 79 0d c0 d4 81
d6 db ea 8f 92 14 68 ac 6f db 2e 83 a9 02 1a 3b
cipher suites
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_DHE_DSS_WITH_RC2_56_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
SSL_RSA_EXPORT1024_WITH_RC4_56_MD5
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5
compression methods
NULL
1 2 0.0069 (0.0028) S>CV3.0(74) Handshake
ServerHello
Version 3.0
random[32]=
3e 7e 03 ef bb 3b 30 7d d5 02 ea f4 d4 e7 c5 6a
61 9f 93 ca 0c 4c d1 98 3d 67 9f e3 7a 28 e2 a1
session_id[32]=
b8 9b 8d 85 19 56 8a 28 c8 16 fc c6 cc 55 a0 1e
ba 24 4b 73 63 1d d7 b6 7c fd 5d 51 1e 90 8c 4e
cipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
compressionMethod NULL
1 3 0.0069 (0.0000) S>CV3.0(767) Handshake
Certificate
1 4 0.1035 (0.0965) S>CV3.0(189) Handshake
ServerKeyExchange
params
DH_p[64]=
da 58 3c 16 d9 85 22 89 d0 e4 af 75 6f 4c ca 92
dd 4b e5 33 b8 04 fb 0f ed 94 ef 9c 8a 44 03 ed
57 46 50 d3 69 99 db 29 d7 76 27 6b a2 d3 d4 12
e2 18 f4 dd 1e 08 4c f6 d8 00 3e 7c 47 74 e8 33
DH_g[1]=
02
DH_Ys[64]=
9d 5d 2e ac b2 95 20 83 a0 87 37 68 f6 be 25 19
d6 eb e0 21 fd 38 88 83 d6 cb 84 6f 10 d2 98 e5
72 5b ef a4 52 23 65 9d b1 c4 22 21 1a 90 d2 e7
53 f0 8b 63 43 12 43 22 ef 7d 45 77 1e 67 79 9b
signature[48]=
30 2e 02 15 00 ad b4 23 61 61 1e 44 35 da 8e f4
9b 5b d7 c0 cd e0 c6 35 07 02 15 00 98 d3 df d7
04 48 d5 d3 ed bb fe 5d e4 30 e5 31 fb 5f 0b c1
1 5 0.1035 (0.0000) S>CV3.0(4) Handshake
ServerHelloDone
1 6 0.1106 (0.0071) C>SV3.0(70) Handshake
ClientKeyExchange
DiffieHellmanClientPublicValue[64]=
7e 80 ba 59 2e 63 d2 e6 ca f4 03 c9 8a c8 16 02
e1 3c 39 61 97 a0 61 d0 f3 30 57 a7 a9 5c a4 83
40 35 83 d6 7a 9d 1f 72 d7 d6 35 96 27 52 a6 60
5c 75 92 ec 04 c8 6f cd d2 10 1d b3 1c ca 0a 90
1 7 0.1106 (0.0000) C>SV3.0(1) ChangeCipherSpec
1 8 0.1106 (0.0000) C>SV3.0(64) Handshake
1 9 0.1131 (0.0024) S>CV3.0(1) ChangeCipherSpec
1 10 0.1131 (0.0000) S>CV3.0(64) HandshakeThe ServerKeyExchange is in record 4. As indicated in Figure 6.21, the server sends the prime modulus (DH_p) and group generator (DH_g) as well as its key (DH_Ys) and the signature. Because the client must use the same prime modulus and group generator, it merely responds with its key in record 6. The rest of the session proceeds as usual. |
|
|
