logo
TLS HANDSHAKE Back to Home Page


Secure Server Layer (SSL) Version 2 was a breeze when compared to Transport Layer Security (TLS) Versions 1, 2, & 3. SSL was developed by Netscape as far as Version 3. The IETF developed the TLS standard based upon SSLv3, as evidenced by the fact that internally SSLv3 is referred to as Version 3.0, while TLSv1 is referred to as Version 3.1. For all practical purposes, SSL is deprecated and no longer in much use.

I am not here to judge whether TLS is overly complex or not. There are many explanations available at the theoretical level. My intention is to provide an easy to follow explanation of the process at the byte level. What is happening in that first half second as you establish a secure connection with a remote server? If something like this was available to me before I attempted to write a TLS program, I could have saved myself countless hours. Jeff Moser did a very good job of explaining this process in The First Few Milliseconds, although he tended to concentrate on explaining the principles of cryptography rather than what was actually happening in the computer. He used a specially compiled version of Mozilla Firefox to log certain information. Not having that facility available, I took advantage of Mikes Toolbox to recover some information. From his Home Page, he has links to test TLS client software, although it defaults to Diffie-Hellman. I was more interested in RSA using either MD5 or SHA1 as a hash, which is commonly supported by virtually all servers and browsers.

Mozilla Firefox supports many different Cipher Suites (36 on my computer), so I needed to limit that selection. I loaded "about:config" as the URL in Firefox, and toggled most of the Security settings to False. Then I enabled my packet sniffer and connected to the ".org" link. The other link (".net") is used to test client software that has it's own certificate and key pair, and that only serves to confuse the issue. Of the few suites I left active, Mike's server chose TLS_RSA_WITH_RC4_128_SHA. After making the connection, the server then returned as text, information about the connection, which is included below. Although quite lengthy, I included all the packet data broken down and explained. The Sniffer data is enclosed between lines of asterisks with a title.

##################################################################
### Mike's Toolbox Enhanced Multi-Threaded SSL/TLS Test Server ###
###                                                            ###
###               https://www.mikestoolbox.net/                ###
###               https://www.mikestoolbox.org/                ###
###                                                            ###
### Mike's Toolbox contact info:                               ###
###                                                            ###
###             EMAIL:    mikestoolbox@pobox.com               ###
###             WEB:      http://mikestoolbox.com/             ###
###             TWITTER:  @mikestoolbox                        ###
###                                                            ###
### Copyright (c) 2010 Michael D'Errico, All Rights Reserved   ###
##################################################################

Connection from:        [206.116.168.xxx]
Current time:           Thu, 21 Nov 2013 18:09:15 GMT
TLS negotiation time:   0.34652 seconds
*********** CLIENT HELLO ***********
16:03:01:00:5B: Record Header (len=91)
01:00:00:57: Message Header (len=87) - Client Hello
03:01: Version 3.1
52:8E:4C:3E:5E:78:99:95:66:45:41:62:AE:FD:E3:25: Client
D2:3D:36:E2:1D:CA:1F:B0:55:36:DC:CD:3C:96:9E:03: Random
00: Session ID Length (len=0)
00:08: Cipher Suite Length (len=8)
00:96:00:04:00:05:00:15:
01: Compression Support Length (len=1)
00: Comppression Support - None
00:26: Server Name Extension Length (len=38)
00:00:00:19: Message Length (len=25) Server Name Indicator
00:17: (len=23)
00:00:14: (len=20)
77:77:77:2E:6D:69:6B:65:73:74:6F:6F:6C:62:6F:78:2E:6F:72:67: (www.mikestoolbox.org)
FF:01:00:01:00:00:23:00:00:
************************************
Client Version:         TLS 1.0
Client Random:          52 8E 4C 3E 5E 78 99 95 66 45 41 62 AE FD E3 25 
                        D2 3D 36 E2 1D CA 1F B0 55 36 DC CD 3C 96 9E 03
Client Random Time:     Thu, 21 Nov 2013 18:09:02 GMT
Client Session ID:      
Client Cipher Suites:   0096  TLS_RSA_WITH_SEED_CBC_SHA
                        0004  TLS_RSA_WITH_RC4_128_MD5
                        0005  TLS_RSA_WITH_RC4_128_SHA
                        0015  TLS_DHE_RSA_WITH_DES_CBC_SHA
Client Compression:     0     NULL
-----------------
Server Name Indication: www.mikestoolbox.org
Max Fragment Length:    16384 bytes
Truncated HMAC:         No
Signature Algorithms:   Not Specified
Session Ticket:         Empty
Renegotiation Info:     Empty

The Client Hello is very straight forward. The client opens the connection on port 443 and sends a 32 byte random string along with the Cipher Suites that it supports. The Server Name Extensions are optional, but they give the server advance information of what is coming. The Server Name Indicator allows the server to host more than one secure site with more than one certificate and key pair.

*********** SERVER HELLO ***********
16:03:01:00:39: Record Header (len=57)
02:00:00:35: Message Header (len=53) - Server Hello
03:01: Version 3.1
52:8E:4C:4B:2C:BC:24:E8:B2:98:6D:A9:5D:55:05:08:
E5:40:FA:59:0C:C8:3E:C8:57:51:14:4C:00:4A:E0:84:
00: Session ID Length (0)
00:05: Cipher Suite - TLS_RSA_WITH_RC4_128_SHA
00: Compression Length (len=0)
00:0D: Extension Length (len=13)
00:00:00:00:00:23:00:00:FF:01:00:01:00:
************************************
Server Version:         TLS 1.0
Server Random:          52 8E 4C 4B 2C BC 24 E8 B2 98 6D A9 5D 55 05 08 
                        E5 40 FA 59 0C C8 3E C8 57 51 14 4C 00 4A E0 84
Server Random Time:     Thu, 21 Nov 2013 18:09:15 GMT
Server Session ID:      
Server Cipher Suite:    0005  TLS_RSA_WITH_RC4_128_SHA
Server Compression:     0     NULL
-----------------
Server Name Chosen:     www.mikestoolbox.org
Max Fragment Length:    16384 bytes
Truncated HMAC:         No
Session Ticket:         264 Bytes
Renegotiation Info:     Empty

The Server Hello actually consists of 3 messages, each with it's own Record Header. The actual Hello portion from the Server sends it's own 32 byte random string, and the Cipher Suite that it selected from the choices offered. It then sends it's Certificate data, which can include a fairly long chain of Certificates. The one shown here is relatively short because it is not registered with a Trusted Authority.

NOTE: Microsoft servers do not return a record header for each message. The 3 Server Helo messages are all sent under a single record header.

*********** SERVER Cert ***********
16:03:01:07:07: Record Header (len=1,799)
0B:00:07:03:  Message Header (len=1,795) - Certificate Data
00:07:00: Total size 1,792
00:03:A8: First Cert size 936
Start of Certificate data
30:82:03:A4: ;SEQUENCE (len=932)
30:82:02:8C: ;SEQUENCE Part 1 (len=652)
A0:03:02:01:02:02:04:4D:82:CF:3E:30:0D:06:09:2A:
86:48:86:F7:0D:01:01:05:05:00:30:47:31:0B:30:09:
06:03:55:04:06:13:02:55:53:31:17:30:15:06:03:55:
04:0A:0C:0E:4D:69:6B:65:27:73:20:54:6F:6F:6C:62:
6F:78:31:1F:30:1D:06:03:55:04:03:0C:16:4D:69:6B:
65:27:73:20:54:6F:6F:6C:62:6F:78:20:54:65:73:74:
20:43:41:30:1E:17:0D:31:31:30:33:31:38:30:33:31:
39:32:32:5A:17:0D:31:36:30:33:31:38:30:33:31:39:
32:32:5A:30:45:31:0B:30:09:06:03:55:04:06:13:02:
55:53:31:17:30:15:06:03:55:04:0A:0C:0E:4D:69:6B:
65:27:73:20:54:6F:6F:6C:62:6F:78:31:1D:30:1B:06:
03:55:04:03:0C:14:77:77:77:2E:6D:69:6B:65:73:74:
6F:6F:6C:62:6F:78:2E:6F:72:67:30:82:01:22:30:0D:
06:09:2A:86:48:86:F7:0D:01:01:01:05:00:03:82:01:
0F:00: (230 bytes)
30:82:01:0A: ;SEQUENCE (len=266)
02:82:01:01: ;INTEGER (len=257)
00:          ;NULL
BF:93:92:BE:7C:82:7E:C4:BF:08:12:5E:9F:D4:75:F2: Public
8F:10:1C:09:D0:99:E8:B7:33:68:38:D0:97:C9:01:13: Key
7D:5D:12:D6:19:61:A1:34:B3:DA:AE:66:8E:B0:6E:FC: (reversed)
36:D4:A7:62:AD:65:66:E1:BB:0D:92:96:30:D6:67:DE:
2E:8A:81:F0:75:B2:FE:90:E2:F2:7D:BA:73:74:34:84:
64:D5:22:2E:08:0F:F0:99:F3:DA:6F:72:6B:E6:61:C4:
DD:DC:06:3E:72:E6:0D:FA:7D:78:99:7B:B4:E8:48:9F:
29:E2:7D:E8:53:6C:A8:D9:B5:6F:BF:CC:71:69:1D:14:
A3:94:6B:E2:76:97:9B:31:5C:F0:FF:32:3D:47:7E:95:
CD:C5:8A:92:5D:D0:C9:5D:9D:75:0F:E9:3A:48:F8:A4:
FA:25:0A:60:7A:38:D0:20:18:77:00:82:2A:7A:42:13:
1F:CC:AB:AB:A8:93:E1:62:5B:48:89:CF:F1:45:85:04:
8C:F5:8A:04:B5:C8:8A:DB:A1:60:29:4F:06:42:8B:B9:
B7:DB:3D:15:74:40:9C:32:8A:E8:69:01:BD:CE:81:48:
65:7E:53:D9:CC:9A:A6:67:B6:6E:5F:5E:9A:96:AD:5D:
C8:14:E9:D9:38:3B:08:3B:C5:27:FA:3A:FC:13:61:FD:
02:03: INTEGER (len=3)
01:00:01: Exponent (65,537) (500 bytes)
A3:81:99:30:81:96:30:0E:06:03:55:1D:0F:01:01:FF:
04:04:03:02:05:A0:30:13:06:03:55:1D:25:04:0C:30:
0A:06:08:2B:06:01:05:05:07:03:01:30:2F:06:03:55:
1D:11:04:28:30:26:82:12:2A:2E:6D:69:6B:65:73:74:
6F:6F:6C:62:6F:78:2E:6F:72:67:82:10:6D:69:6B:65:
73:74:6F:6F:6C:62:6F:78:2E:6F:72:67:30:1F:06:03:
55:1D:23:04:18:30:16:80:14:23:A8:AF:F6:06:58:DF:
FB:58:4F:F1:08:2C:09:4F:C0:A1:F7:D2:AA:30:1D:06:
03:55:1D:0E:04:16:04:14:EB:3E:6C:12:ED:9A:30:B8:
A9:AB:7B:EE:E4:EE:03:7A:DC:6F:61:1E: (656 bytes)
End of Part 1/Start of Part 2
30:0D: ;SEQUENCE (len=13)
06:09: ;OBJECT_ID (len=9)
2A:86:48:86:F7:0D:01:01:05: DSASHA1 Algorythm
05:00: ;NULL (671 bytes)
03:82:01:01: ;SEQUENCE (len=257)
00:          :NULL
53:14:D3:8C:00:84:65:C6:B4:12:1D:23:2A:DF:1F:04: Signature
1C:46:A8:BC:59:36:33:6A:B9:D1:4B:4F:17:AC:B8:14: (reversed)
1B:60:31:43:70:4B:A5:57:F4:6C:01:E5:65:51:5D:55:
4B:EB:E9:1F:D4:3B:F9:8D:A1:01:5E:F4:10:C7:11:CA:
08:B9:45:EF:1E:65:1D:FC:2F:39:02:25:5D:0F:2F:4C:
6B:60:00:E9:34:67:96:63:E9:F5:27:E6:B1:9D:39:44:
D2:7F:40:8F:B5:63:7A:6B:A5:86:2D:86:4C:D9:37:EE:
CE:94:0B:C1:16:45:4C:12:D0:6F:2B:6C:37:3D:A2:BE:
4E:04:30:7C:64:F1:49:B2:22:A4:E6:BF:BF:54:ED:3C:
2A:8D:85:D1:17:E0:06:22:15:BF:2F:64:0E:D2:44:F3:
7C:77:F3:EF:55:2F:BB:A9:53:7E:23:57:DD:73:71:E1:
95:C7:1A:25:27:B0:8A:F2:77:20:7C:7C:B6:1F:32:54:
D5:C7:92:68:D0:35:6C:CC:E1:12:86:A2:93:EC:E2:A3:
85:6C:01:56:6A:92:97:06:8E:1D:BD:FA:58:E2:E5:B4:
3F:A2:70:5C:51:E7:5F:87:67:AE:D8:AD:A0:81:B4:37:
A0:EE:1C:DF:B1;C8:AF:B6:7D:A8:4D:65:AA:CB:BF:63:
End of First Certificate  (932 bytes)

00:03:52: CA Certificate (len=850)
30:82:03:4E: ;SEQUENCE (len=846)
30:82:02:36: ;SEQUENCE (len=566)
A0:03:02:01:02:
02:04:4D:82:CF:3A:30:0D:06:09:2A:86:48:86:F7:0D:
01:01:05:05:00:30:47:31:0B:30:09:06:03:55:04:06:
13:02:55:53:31:17:30:15:06:03:55:04:0A:0C:0E:4D:
69:6B:65:27:73:20:54:6F:6F:6C:62:6F:78:31:1F:30:
1D:06:03:55:04:03:0C:16:4D:69:6B:65:27:73:20:54:
6F:6F:6C:62:6F:78:20:54:65:73:74:20:43:41:30:1E:
17:0D:31:31:30:33:31:38:30:33:31:39:32:32:5A:17:
0D:31:36:30:33:31:38:30:33:31:39:32:32:5A:30:47:
31:0B:30:09:06:03:55:04:06:13:02:55:53:31:17:30:
15:06:03:55:04:0A:0C:0E:4D:69:6B:65:27:73:20:54:
6F:6F:6C:62:6F:78:31:1F:30:1D:06:03:55:04:03:0C:
16:4D:69:6B:65:27:73:20:54:6F:6F:6C:62:6F:78:20:
54:65:73:74:20:43:41:30:82:01:22:30:0D:06:09:2A:
86:48:86:F7:0D:01:01:01:05:00:03:82:01:0F:00:
30:82:01:0A: SEQUENCE (len=266)
02:82:01:01: INTEGER (len=257)
00: Null lead character
AD:66:7B:B3:9E:D0:B2:8D:92:2B:43:4B:98:E8:C7:71: Public Key
69:8A:6B:A9:6C:20:54:8C:EE:18:B8:D6:23:A3:61:BB: (reversed)
ED:A5:F7:F9:E0:03:19:27:8C:B3:84:D9:BD:AA:83:5C:
40:4B:94:63:58:0A:EF:01:EF:FA:E5:A0:41:AA:A0:80:
F9:62:B2:98:8F:13:28:15:66:5B:B9:C3:F0:9A:BA:C8:
88:60:98:76:8C:22:32:A5:99:26:D1:6A:F2:A2:BC:41:
73:FE:A6:64:89:E5:09:00:8A:60:E4:57:62:7F:DE:C5:
D8:BB:00:E2:BE:41:71:C6:08:84:07:38:28:2C:25:E8:
39:69:BD:F0:82:A6:1C:7C:69:4E:36:69:93:5A:F8:95:
E8:08:6C:7D:00:3F:36:9F:FE:CB:92:AE:8B:15:8D:56:
5B:8E:6A:E9:A7:38:AB:7B:21:A1:F2:C8:2D:35:18:4A:
10:82:BD:C6:88:75:96:6B:3A:25:F5:B4:8D:F4:E9:83:
E2:68:F5:AF:F2:02:BF:21:9A:1F:E8:81:D3:41:BD:36:
19:EB:A6:B1:5B:7F:7C:1F:8B:63:61:94:EC:D1:CB:2A:
61:B9:0A:04:12:60:C4:BD:18:7C:42:CF:E6:1C:60:2E:
D4:20:46:2A:4E:FE:1F:98:FF:CC:24:93:22:25:49:35:
02:03: INTEGER (len=3)
01:00:01: Exponent (65,537)
A3:42:30:40:30:0F:06:03:55:1D:13:01:01:FF:04:05:
30:03:01:01:FF:30:0E:06:03:55:1D:0F:01:01:FF:04:
04:03:02:01:06:30:1D:06:03:55:1D:0E:04:16:04:14:
23:A8:AF:F6:06:58:DF:FB:58:4F:F1:08:2C:09:4F:C0:
A1:F7:D2:AA:
30:0D: ;SEQUENCE (len=13)
06:09: ;OBJECT_ID (len=9)
2A:86:48:86:F7:0D:01:01:05: DSASHA1 Algorythm
05:00: ;NULL
03:82:01:01: ;SEQUENCE (len=257)
00:          ;NULL
95:F8:99:81:A8:DA:40:30:21:95:40:7F:16:20:82:21: Signature
3D:06:BE:39:F9:45:8F:E2:D1:8E:3A:48:7E:E8:B0:6D: (reversed)
60:84:2A:2A:0B:10:A7:EB:6B:2C:AA:D6:DE:82:65:56:
77:D7:D9:2B:40:8F:03:A7:3D:68:DA:97:DD:C8:50:7F:
3E:50:76:52:BA:B5:E2:B0:D8:7C:55:1D:63:8C:11:DB:
90:14:71:24:28:97:43:40:3A:9C:70:CA:5D:1C:30:97:
E0:E7:14:34:CB:74:04:49:C5:EE:E5:D4:B7:37:58:F4:
25:9D:3F:6E:0F:F4:3D:68:E1:FA:FD:CD:E8:CD:68:61:
16:6C:4B:7B:70:40:B4:0B:CD:D9:FC:29:E9:9D:CF:3B:
6A:34:58:B6:E5:F9:0A:10:6B:43:15:A1:28:27:29:F1:
86:F8:1A:F4:42:6E:89:E0:46:6D:95:52:10:2A:10:56:
7A:9E:90:81:F4:FE:52:3B:64:14:94:BB:BC:C1:2E:55:
7C:F6:E3:DF:FA:92:05:4A:A1:9D:2F:9F:30:19:27:A9:
C4:D7:A6:76:83:2D:32:4D:74:E2:12:01:3D:23:B6:AE:
E5:9B:8F:FC:C5:76:EB:20:74:2F:4E:59:AB:E1:56:81:
9A:B2:EC:74:D7:55:E9:D4:C7:8E:92:7A:DD:11:7D:4D:
End of CA Certificate

16:03:01:00:04: Record Header (len=4) - Server Done
0E:00:00:00:
************************************

I have not completely broken down the Certificate data, because all we are interested in is the Public Key. The Public Key from the Server is needed by the Client in order to transmit to the Server the Pre-Master Secret. The Certificate is formatted using ASN.1, which makes it rather difficult to read manually. You can however use your browser to examine the certificates in more detail. Unlike Mozilla, the Microsoft Certicate Reader does not show the Signature.

In theory, the receiver is supposed to verify the signatures. The Signature was created by the Server using the Private Key, so we can decrypt it using the Public Key and compare it to a Hash of Part 1 of the certificate (obviously not including the signature part). This Hash is not the same as the Thumbprint, which is a hash of the entire Certificate, including the Signature. This is true of a single self-signed certificate, but for a Certificate purchased from a Certificate Authority, the certificate is signed with the Private Key from the CA. Browsers come complete with the Root Certificates from the well known and trusted providers. For verifying signatures, the Public Key from the provider must be used instead of the Public Key from the server. For self-signed Certificates that use a self-signed Root Certificate so that they can service multiple web sites, the Public Key can be obtained from the Handshake Certificate record above, or the Root Certificate can be imported by some other means into the Trusted Root Store.

So you can see that self-signed Certificates can be just as secure as the expensive purchased ones. All you need to do is import the Root Certificate into the Root Store for the Client browser.

*********** CLIENT KEY EXCHANGE ***********
16:03:01:01:06: Record Header (len=262)
10:00:01:02: Message Header (len=258) - Pre-Master Key 
01:00: Pre-Master Length (len=256)
1A:87:82:C8:F8:A8:C2:22:05:7F:46:86:DC:6E:62:6C:
79:E1:43:97:DC:82:2A:D8:20:6C:85:EA:80:D6:B1:CC:
9E:9B:BB:0A:BC:32:AA:4B:D5:AA:40:68:AD:23:0B:C6:
30:8A:AC:1B:1D:48:99:29:E3:1C:40:E9:75:D3:5E:6B:
C9:E7:3E:E9:72:26:42:3A:AC:AE:7C:E9:1A:86:09:97:
FD:64:04:9F:9F:41:F7:C6:A2:6F:55:25:B4:B4:AE:93:
4F:C2:59:75:A5:39:00:DF:7F:E6:1B:8A:E3:C0:0C:91:
14:09:3F:22:A2:BE:80:E4:E4:C1:67:8A:F1:34:32:84:
87:AE:FF:11:88:1A:9A:06:8F:C4:BC:2D:7B:BC:1B:10:
0E:3F:04:6A:D1:09:60:4F:0D:F8:3C:5A:51:4C:05:DF:
11:7F:B6:DB:25:B7:EC:6A:27:4C:1D:62:2E:F4:DE:DB:
18:29:0F:1D:6C:F6:25:43:99:39:8C:16:C6:5D:B8:87:
3E:0B:E4:57:1A:3D:E5:DD:D4:20:4B:3E:67:E8:B1:78:
4E:47:B4:05:73:32:A2:84:96:02:93:90:90:33:9A:A5:
E7:41:88:5C:33:24:A8:AF:C3:A7:00:47:0D:7E:23:40:
F8:8A:62:46:92:1F:04:EA:25:9A:31:98:D9:4C:1B:64:

14:03:01:00:01: Record Header (len=1) - Change Cipher Spec
01:

16:03:01:00:24: Record Header (len=36) - Client Finished
56:AB:F5:CF:30:5A:1A:ED:58:28:31:85:5F:02:F0:9D:
B4:3F:50:0C:D9:98:B2:A0:A4:9A:D6:36:20:A8:76:32:
C2:E0:A0:AC:
*******************************************

Security Parameters
-------------------
Client Finished:        DC 79 1D D4 34 9B D4 80 C6 99 D8 56
Server Finished:        3C A7 46 92 C2 67 CC 22 1F AA 53 9B
Master Secret:          46 75 09 5E 15 D8 EE 59 57 51 86 BC 25 0E 71 C9 
                        99 D5 4D DE 39 49 88 AC A1 4D 8C 26 6B 0F D3 4C 
                        3B 57 71 47 F2 D7 DE 05 B1 58 18 66 4C 53 81 FA

Handshake Details
-----------------
Bytes Sent:             2150
Bytes Received:         369

So what does the Pre-Master Secret have to do with the Master Secret? The Public Key that the Client got from the Server is used to encrypt a random 48 byte Pre-Master Secret, sent to the Server as a 256 byte record because we used a 256 byte (2048 bit) key to encrypt it. If it is intercepted, it is virtually useless to the hacker. The receiver would need the Private Key in order to decrypt it. We cannot use the Public Key. This part of the TLS Handshake is known as Asymmetric Encryption. Once received and decrypted by the Server, both sides now have all the ingredients necessary to create the Master Secret (or Master Key).

The Pre-Master Secret, the Client Random, and the Server Random are combined using what is known as a Pseudo Random Function (PRF). Unlike a hash, which is a fixed length, the PRF can be any length. This is achieved by iterating through the function until the desired length is achieved.

Along with the encrypted Pre-Master Secret, the Client sends the Change Cipher Spec to indicate to the Server that all future transmission will be encrypted with the newly created Master Keys. Since both sides will be using the same keys, this is known as Symmetric Encryption.

Also sent with the Pre-Master Secret and Change Cipher Spec, is the Client Finished Record. This is a very special record. Both an MD5 (16 byte), and an SHA1 (20 byte) hash of the messages sent and received are created. This does not include the Record Headers, nor does it include the Change Cipher Spec message. These 2 hashes (PRF_SEED) are combined with a PRF_LABEL ("client finished"/"server finished") as a 12 byte PRF message as Mike's server has shown above. Since it follows the Change Cipher Spec, before sending it to the Server, the Client prepends it with a 4 byte message header, and appends it with an HMAC (Hash-based Message Authentication Code) of the entire message (HMAC will be explained in the next paragraph). The message plus the HMAC is then encrypted with the Write Key (explained later) before being sent to the Server. The Server will be able to decrypt it, and compare it to the same hash message that it has maintained. In this manner, the Server is able to verify that none of the messages have been tampered with.

After the Master Secret is created, a hash of the Master Secret is used to create a Read Key, a Write Key, a Read MAC Key, and a Write MAC Key. Read keys are used to decrypt messages, and Write keys are used to encrypt messages. When a message is ready to be encrypted, an HMAC of it is created using the Write MAC Key. This is then appended to the original message, and both are encrypted with the Write Key.
HMAC(Key, m) = Hash((Key XOR opad) ++ Hash((Key XOR ipad) ++ m)
(++ means concatenate, "opad" is the bytes "5c 5c ... 5c",
and "ipad" is the bytes "36 36 ... 36")
"m" is not just the message being sent. It is "seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment" where:
seq_num = 8 bytes = Sequence number incremented after each encrypted record
type = 1 byte = Type of record = 22 for handshake and 23 thereafter
version = 2 bytes = internal version number = 3.1 for TLS1.0
length = 2 bytes = message length which is variable
fragment = variable = actual message
Using MD5, the HMAC is 16 bytes long, and when combined with the 12 byte Client Finished and 4 byte Header, it ends up as 32 bytes before and after encryption. Using SHA1, the HMAC is 20 bytes long, and when combined with the 12 byte Client Finished and 4 byte Header, it ends up as 36 bytes before and after encryption. The whole purpose of the HMAC is to verify that the message has not been tampered with.

*********** SERVER KEY EXCHANGE ***********
16:03:01:01:12: Record Header (len=274)
04:00:01:0E: Message Header (len=270) - New Session Ticket
00:00:02:58:
01:08: Length (len=264)
02:A0:29:F6:F7:7E:51:C4:DB:A7:EA:D7:D6:FF:05:E9:
54:73:E0:5C:11:B9:00:D0:DA:C9:40:8A:83:DF:5C:70:
78:2D:E9:B9:2E:A6:84:F1:FC:B0:BB:29:DB:E8:45:E4:
3B:73:5D:FD:23:4D:83:57:F3:80:E3:EE:24:FF:1B:49:
21:8F:4F:C0:EF:70:55:DA:F3:1C:40:E7:E5:8C:54:B0:
3A:4B:55:6F:AC:1D:7E:F3:EF:FA:78:22:CB:70:E8:9C:
D0:B7:AC:76:E0:D4:57:3F:C2:FC:DB:FF:A7:40:6B:C8:
55:1E:2D:AC:D0:E2:B5:D8:3C:8E:48:DD:82:D2:2B:DD:
0D:BB:FA:CA:C8:DA:5E:15:29:22:FE:2C:BA:7C:38:2A:
3C:FD:3E:23:89:0A:C5:A9:20:5D:31:26:99:52:FD:B4:
C8:CB:F7:4C:41:56:4E:B9:E1:C4:1C:DE:D2:77:A5:A7:
C2:12:3E:C4:61:F7:EA:9A:0F:D1:EE:32:DE:46:BE:D3:
DD:7C:79:B5:42:1D:83:8A:17:51:3E:3C:02:66:81:CD:
DA:38:8C:2B:E4:5E:CA:6C:19:85:83:8C:99:A8:48:D3:
1A:31:72:1C:A8:2E:4F:34:05:FC:20:F0:1E:D4:CF:B1:
B1:0B:67:C0:C3:49:D3:DA:DF:44:E2:0F:11:EA:4D:29:
33:4C:FA:23:EF:19:48:3C:

14:03:01:00:01: Record Header (len=1) - Change Cipher Spec
01:

16:03:01:00:24: Record Header (len=36) - Server Finished
FD:47:E8:95:63:02:EA:FF:A8:EF:61:12:B3:ED:E2:64:
73:C3:CB:55:CA:71:44:58:9A:D4:5E:B5:66:E8:77:BF:
BE:BF:52:35:
*******************************************

Normally, the Server Hello contains a Session ID. In this case however, the server did not provide a Session ID, but instead provided a New Session Ticket in this last part of the handshake. This is a relatively new extension to the TLS protocol, used to re-establish a session. The Server also sends a Change Cipher Spec record, and a Server Finished record. The Server Finished record is basically the same as the Client Finished record with the decrypted Client Finished message added.

Note: Once a session is established, there is a limit to the size of the fragment that can be sent under TLS (2^14 or 16,384 bytes).

For a full packet display, see Here

For a full packet display of TLS 1.2, see Here

Back to Top

Here Home Page


address