In this post I want to show what happens at the protocol level when we use SSL/TLS. For the purpose of this analysis I’ll be using a non-blocking implementation of a TCP client and server based on OpenSSL for the Scheme Gambit compiler that I’m currently working on.
Is important to note that SSL/TSL enables applications to be only as secure as the underlying infrastructural components (networks and hosts). SSL/TLS is a separate protocol that inserts itself between the application protocol (generally HTTP, but any other is perfectly possible) and the transport protocol (TCP). By acting as such, TLS requires very few changes to the protocols below and above, so the protocol can operate nearly transparently for users, meaning that users need not be aware of the fact that the protocol is in place. Of course this comes with some drawbacks, as it limits the protocol in some fundamental aspects (such as the inability to use UDP).
SSL/TLS has evolved considerably since its beginnings. Nowadays SSL 2.0 and 3.0 are considered insecure, so they are being replaced by the newer TLS 1.0/1.1/1.2 versions. The history of these protocols is an interesting topic.
Description of the protocolAs mentioned before, the TLS protocol sits between the Application Layer and the Transport Layer. It is divided in two main sublayers. This is the general structure of the protocol, and its place in the network stack:
The lower layer is stacked on top of TCP, as it is a connection-oriented and reliable transport layer protocol. This layer consists basically of the TLS Record Protocol. In a nutshell, the Record Protocol first fragments the higher-layer protocol data into blocks of 214 bytes or less; then optionally compresses the data, adds a Message Authentication Code and finally encrypts the data according to the cipher spec (when negotiated), adding an SSL Record header. One thing to note is that each block is packed into a structure that does not preserve client message boundaries, meaning that multiple messages of the same type may be coalesced into a single structure.
The following diagram depicts the process of building an SSL Record.
-----------+ data --+--------------> 1. Fragment data -----------+ +------------------------+ | | | | +------------------------+ 2. Compress data (generally no compression applied) +------------------------+----+ | |MAC | Add a Message Authentication Code | | | +------------------------+----+ 3. Encrypt data +-----------------------------+ |ciphertext | | | +-----------------------------+ 4. Add header +----+-----------------------------+ TLS Record | |ciphertext | Add a TLS Record header header | | | +----+-----------------------------+
The higher layer is stacked on top of the SSL Record Protocol, and comprises four subprotocols. Each of these protocols has a very specific purpose, and are used at different stages of the communication:
Handshake Protocol: It allows the peers to authenticate each other and to negotiate a cipher suite and other parameters of the connection. The SSL handshake protocol involves four sets of messages (sometimes called flights) that are exchanged between the client and server. Each set is typically transmitted in a separate TCP segment. The following diagram shows a summary of the process, which has several steps and offers optional ones. Please note that ChangeCipherSpec messages don’t belong to this protocol, as they are a protocol by themselves, as seen below.
TLS Handshake +-----+ +-----+ | | | | | | ClientHello | | | o----------------------------> | | | | | | CLIENT | | ServerHello | | SERVER | | [Certificate] | | | | [ServerKeyExchange] | | | | [CertificateRequest] | | | | ServerHelloDone | | | | <----------------------------o | | | | | | | [Certificate] | | | | ClientKeyExchange | | | | [CertificateVerify] | | | | ** ChangeCipherSpec ** | | | | Finished | | | o----------------------------> | | | | | | | | ** ChangeCipherSpec ** | | | | Finished | | | | <----------------------------o | | | | | +-----+ +-----+ Optional messages -------------------------------------------------------------------------------------------- Certificate (server) needed with all key exchange algorithms, except for anonymous ones. ServerKeyExchange needed in some cases, like Diffie-Hellman key exchange algorithm. CertificateRequest needed if Client authentication is required. Certificate (client) needed in response to CertificateRequest by the server. CertificateVerify needed if client Certificate message was sent.
ChangeCipherSpec Protocol: It makes the previously negotiated parameters effective, so communication becomes encrypted.
Alert Protocol: Used for communicating exceptions and indicate potential problems that may compromise security.
Application Data Protocol: It takes arbitrary data (application-layer data generally), and feeds it through the secure channel.
Several messages can be concatenated into a single Record Layer message, but those messages must belong to the same subprotocol. As a consequence of this, each of these four protocols must be self-delimiting (i.e. must include its own length field).
Record Protocol format
The TLS Record header comprises three fields, necessary to allow the higher layer to be built upon it:
Byte 0: TLS record type
Bytes 1-2: TLS version (major/minor)
Bytes 3-4: Length of data in the record (excluding the header itself). The maximum supported is 16384 (16K).
record type (1 byte) / / version (1 byte major, 1 byte minor) / / / / length (2 bytes) / / / +----+----+----+----+----+ | | | | | | | | | | | | TLS Record header +----+----+----+----+----+ Record Type Values dec hex ------------------------------------- CHANGE_CIPHER_SPEC 20 0x14 ALERT 21 0x15 HANDSHAKE 22 0x16 APPLICATION_DATA 23 0x17 Version Values dec hex ------------------------------------- SSL 3.0 3,0 0x0300 TLS 1.0 3,1 0x0301 TLS 1.1 3,2 0x0302 TLS 1.2 3,3 0x0303
Handshake Protocol format
This is the most complex subprotocol within TLS. The specification focuses primarily on this, since it handles all the machinery necessary to establish a secure connection. The diagram below shows the general structure of Handshake Protocol messages. There are 10 handshake message types in the TLS specification (not counting extensions), so the specific format of each one will be described below.
| | | Record Layer | Handshake Layer | | | | ...more messages +----+----+----+----+----+----+----+----+----+------ - - - -+-- | 22 | | | | | | | | | | |0x16| | | | | | | | |message | +----+----+----+----+----+----+----+----+----+------ - - - -+-- / / | \ \----\-----\ | / / | \ \ type: 22 / | \ handshake message length / type / length: arbitrary (up to 16k) Handshake Type Values dec hex ------------------------------------- HELLO_REQUEST 0 0x00 CLIENT_HELLO 1 0x01 SERVER_HELLO 2 0x02 CERTIFICATE 11 0x0b SERVER_KEY_EXCHANGE 12 0x0c CERTIFICATE_REQUEST 13 0x0d SERVER_DONE 14 0x0e CERTIFICATE_VERIFY 15 0x0f CLIENT_KEY_EXCHANGE 16 0x10 FINISHED 20 0x14
HelloRequest: Allows a server to restart the handshake negotiation. Not used very often. If a connection has been up for long enough time that its security is weakened (in the order of hours), the server can use this message to force a client to renegotiate new session keys.
| | | | Handshake Layer | | - ---+----+----+----+----+ | | | | | 4 | 0 | 0 | 0 | 0 | - ---+----+----+----+----+ / | \ \---------\ / \ \ record \ length: 0 length \ type: 0
ClientHello: This message typically begins a TLS handshake negotiation. It is sent with a list of client-supported cipher suites, for the server to pick the best suiting one (preferably the strongest), a list of compression methods, and a list of extensions. It gives also the possibility to the client of restarting a previous session, through the inclusion of a SessionId field.
| | | | Handshake Layer | | - ---+----+----+----+----+----+----+------+----+----------+--------+-----------+----------+ | 1 | | | | | |32-bit| |max 32-bit| Cipher |Compression|Extensions| |0x01| | | | 3 | 1 |random| |session Id| Suites | methods | | - ---+----+----+----+----+----+----+------+----+----------+--------+-----------+----------+ / | \ \---------\ \----\ \ \ / \ \ \ \ SessionId record \ length SSL/TLS \ length \ version SessionId type: 1 (TLS 1.0 here) length CipherSuites +----+----+----+----+----+----+ | | | | | | | | | | | | | | +----+----+----+----+----+----+ \-----\ \-----\ \----\ \ \ \ length cipher Id cipherId Compression methods (no practical implementation uses compression) +----+----+----+ | | | | | 0 | 1 | 0 | +----+----+----+ \-----\ \ \ \ length: 1 cmp Id: 0 Extensions +----+----+----+----+----+----+----- - - | | | | | | | | | | | | | |...extension data +----+----+----+----+----+----+----- - - \-----\ \-----\ \----\ \ \ \ length Extension Extension data Id length
ServerHello: The ServerHello message is very similar to the ClientHello message, with the exception that it only includes one CipherSuite and one Compression method. If it includes a SessionId (i.e. SessionId Length is > 0), it signals the client to attempt to reuse it in the future.
| | | | Handshake Layer | | - ---+----+----+----+----+----+----+----------+----+----------+----+----+----+----------+ | 2 | | | | | | 32byte | |max 32byte| | | |Extensions| |0x02| | | | 3 | 1 | random | |session Id| | | | | - ---+----+----+----+----+----+----+----------+----+----------+--------------+----------+ / | \ \---------\ \----\ \ \ \----\ \ / \ \ \ \ SessionId \ Compression record \ length SSL/TLS \ (if length > 0) \ method length \ version SessionId \ type: 2 (TLS 1.0 here) length CipherSuite
Certificate: The body of this message contains a chain of public key certificates. Certificate chains allows TLS to support certificate hierarchies and PKIs (Public Key Infrastructures).
| | | | Handshake Layer | | - ---+----+----+----+----+----+----+----+----+----+----+-----------+---- - - | 11 | | | | | | | | | | | |0x0b| | | | | | | | | |certificate| ...more certificate - ---+----+----+----+----+----+----+----+----+----+----+-----------+---- - - / | \ \---------\ \---------\ \---------\ / \ \ \ \ record \ length Certificate Certificate length \ chain length type: 11 length
ServerKeyExchange: This message carries the keys exchange algorithm parameters that the client needs from the server in order to get the symmetric encryption working thereafter. It is optional, since not all key exchanges require the server explicitly sending this message. Actually, in most cases, the Certificate message is enough for the client to securely communicate a premaster key with the server. The format of those parameters depends exclusively on the selected CipherSuite, which has been previously set by the server via the ServerHello message.
| | | | Handshake Layer | | - ---+----+----+----+----+----------------+ | 12 | | | | algorithm | |0x0c| | | | parameters | - ---+----+----+----+----+----------------+ / | \ \---------\ / \ \ record \ length length \ type: 12
CertificateRequest: It is used when the server requires client identity authentication. Not commonly used in web servers, but very important in some cases. The message not only asks the client for the certificate, it also tells which certificate types are acceptable. In addition, it also indicates which Certificate Authorities are considered trustworthy.
| | | | Handshake Layer | | - ---+----+----+----+----+----+----+---- - - --+----+----+----+----+-----------+-- - | 13 | | | | | | | | | | | C.A. | |0x0d| | | | | | | | | | |unique name| - ---+----+----+----+----+----+----+---- - - --+----+----+----+----+-----------+-- - / | \ \---------\ \ \ \----\ \-----\ / \ \ \ Certificate \ \ record \ length \ Type 1 Id Certificate \ length \ Certificate Authorities length \ type: 13 Types length Certificate Authority length
ServerHelloDone: This message finishes the server part of the handshake negotiation. It does not carry any additional information.
| | | | Handshake Layer | | - ---+----+----+----+----+ | 14 | | | | 4 |0x0e| 0 | 0 | 0 | - ---+----+----+----+----+ / | \ \---------\ / \ \ record \ length: 0 length \ type: 14
ClientKeyExchange: It provides the server with the necessary data to generate the keys for the symmetric encryption. The message format is very similar to ServerKeyExchange, since it depends mostly on the key exchange algorithm picked by the server.
| | | | Handshake Layer | | - ---+----+----+----+----+----------------+ | 16 | | | | algorithm | |0x10| | | | parameters | - ---+----+----+----+----+----------------+ / | \ \---------\ / \ \ record \ length length \ type: 16
CertificateVerify: This message is used by the client to prove the server that it possesses the private key corresponding to its public key certificate. The message holds hashed information digitally signed by the client. It is required if the server issued a CertificateRequest to the client, so that it had to send a Certificate that needs to be verified. Once again, the exact size and structure of the information depends on the agreed algorithm. In all cases, the information that serves as input to the hash functions is the same.
| | | | Handshake Layer | | - ---+----+----+----+----+----------+ | 15 | | | | signed | |0x0f| | | | hash | - ---+----+----+----+----+----------+ / | \ \---------\ / \ \ record \ length length \ type: 15
Finished: This message signals that the TLS negotiation is complete and the CipherSuite is activated. It should be sent already encrypted, since the negotiation is successfully done, so a ChangeCipherSpec protocol message must be sent before this one to activate the encryption. The Finished message contains a hash of all previous handshake messages combined, followed by a special number identifying server/client role, the master secret and padding. The resulting hash is different from the CertificateVerify hash, since there have been more handshake messages.
| | | | Handshake Layer | | - ---+----+----+----+----+----------+ | 20 | | | | signed | |0x14| | | | hash | - ---+----+----+----+----+----------+ / | \ \---------\ / \ \ record \ length length \ type: 20
ChangeCipherSpec Protocol format
This is the simplest protocol: it has only one message. The reason why this message must be a separate protocol instead of being part of the Handshake Protocol is because of the Record Layer encapsulation. The TLS protocol applies encryption to entire Record Layer messages at once. The ChangeCipherSpec message signals the activation of encryption, and since encryption cannot be applied to parts of a message it is impossible for any other message to follow a ChangeCipherSpec one. The best way to avoid those combinations is by elevating this message to the protocol status.
This is how the only ChangeCipherSpec message is structured:
| | | Record Layer | ChangeCipherSpec Layer | | +----+----+----+----+----+----+ | 20 | | | | | | |0x14| | | 0 | 1 | 1 | +----+----+----+----+----+----+ / / | / / | type: 20 / | / / length: 1
Alert Protocol format
The Alert Protocol is also rather simple. It defines two fields: severity level and alert description. The first field indicates the severity of the alert (1 for warning, 2 for fatal), while the second field encodes the exact condition. The supported alert descriptions depend on the SSL/TLS version.
| | | Record Layer | Alert Layer | | +----+----+----+----+----+----+----+ | 21 | | | | | | | |0x15| | | 0 | 2 | | | +----+----+----+----+----+----+----+ / / | / / | type: 21 / | / / length: 2 Alert severity dec hex ---------------------------------------- WARNING 1 0x01 FATAL 2 0x02 TLS 1.0 Alert descriptions dec hex ---------------------------------------- CLOSE_NOTIFY 0 0x00 UNEXPECTED_MESSAGE 10 0x0A BAD_RECORD_MAC 20 0x14 DECRYPTION_FAILED 21 0x15 RECORD_OVERFLOW 22 0x16 DECOMPRESSION_FAILURE 30 0x1E HANDSHAKE_FAILURE 40 0x28 NO_CERTIFICATE 41 0x29 BAD_CERTIFICATE 42 0x2A UNSUPPORTED_CERTIFICATE 43 0x2B CERTIFICATE_REVOKED 44 0x2C CERTIFICATE_EXPIRED 45 0x2D CERTIFICATE_UNKNOWN 46 0x2E ILLEGAL_PARAMETER 47 0x2F UNKNOWN_CA 48 0x30 ACCESS_DENIED 49 0x31 DECODE_ERROR 50 0x32 DECRYPT_ERROR 51 0x33 EXPORT_RESTRICTION 60 0x3C PROTOCOL_VERSION 70 0x46 INSUFFICIENT_SECURITY 71 0x47 INTERNAL_ERROR 80 0x50 USER_CANCELLED 90 0x5A NO_RENEGOTIATION 100 0x64
ApplicationData Protocol format
The mission of this protocol is to properly encapsulate the data coming from the Application Layer of the network stack, so it can seamlessly be handled by the underlying protocol (TCP) without forcing changes in any of those layers. The format of the messages in this protocols follows the same structure as the previous ones.
| | | Record Layer | ApplicationData Layer (encrypted) | | +----+----+----+----+----+----+----+--- - - - - - - --+---------+ | 23 | | | | length-delimited data | | |0x17| | | | | | | | MAC | +----+----+----+----+----+----+----+--- - - - - - - --+---------+ / / | / / | type: 23 / | / / length: arbitrary (up to 16k)Analyzing SSL/TLS traffic
The main purpose of the traffic analysis will be testing the TLS client implementation I’m currently working on for the Gambit Scheme compiler. I will be using Wireshark for the packet capture, the client will be Scheme-based with the work-in-progress support for SSL/TLS, and the test server (with a certificate) that is part of the OpenSSL distribution. The server is listening on port 443, and all communication will be done through the loopback device. The easiest way to restrict your view to TLS packets in Wireshark is to use the protocol filter ‘ssl’.
First flight (client –> server)
Once the server is running and waiting for connection, the client can initiate it. This is the first packet, sent by the client:
Full contents of the packet 0000 02 00 00 00 45 00 00 98 13 ed 40 00 40 06 00 00 ....E.....@.@... 0010 7f 00 00 01 7f 00 00 01 ec 26 01 bb 43 7c ee 74 .........&..C|.t 0020 60 b5 50 0a 80 18 31 d7 fe 8c 00 00 01 01 08 0a `.P...1......... 0030 21 62 1e 1e 21 62 1e 1e 16 03 01 00 5f 01 00 00 !b..!b......_... 0040 5b 03 01 54 9a ab 72 98 65 11 2f da 9e cf c9 db [..T..r.e./..... 0050 6c bd 4b 4c 56 4b 0c a5 68 2b aa 60 1f 38 66 e7 l.KLVK..h+.`.8f. 0060 87 46 b2 00 00 2e 00 39 00 38 00 35 00 16 00 13 .F.....9.8.5.... 0070 00 0a 00 33 00 32 00 2f 00 9a 00 99 00 96 00 05 ...3.2./........ 0080 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................ 0090 00 03 00 ff 01 00 00 04 00 23 00 00 .........#.. ------------ Family: IP 0000 02 00 00 00 .... IP protocol 0000 45 00 00 98 13 ed 40 00 40 06 00 00 7f 00 00 01 E.....@.@....... 0010 7f 00 00 01 .... TCP protocol 0000 ec 26 01 bb 43 7c ee 74 60 b5 50 0a 80 18 31 d7 .&..C|.t`.P...1. 0010 fe 8c 00 00 01 01 08 0a 21 62 1e 1e 21 62 1e 1e ........!b..!b.. ------------ TLSv1 protocol 0000 16 03 01 00 5f 01 00 00 5b 03 01 54 9a ab 72 98 ...._...[..T..r. 0010 65 11 2f da 9e cf c9 db 6c bd 4b 4c 56 4b 0c a5 e./.....l.KLVK.. 0020 68 2b aa 60 1f 38 66 e7 87 46 b2 00 00 2e 00 39 h+.`.8f..F.....9 0030 00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f .8.5.......3.2./ 0040 00 9a 00 99 00 96 00 05 00 04 00 15 00 12 00 09 ................ 0050 00 14 00 11 00 08 00 06 00 03 00 ff 01 00 00 04 ................ 0060 00 23 00 00 .#.. TLSv1 Record protocol 0000 16 03 01 00 5f ...._ 16 Handshake protocol type 03 01 SSL version (TLS 1.0) 5f Record length (95 bytes) TLSv1 Handshake protocol 0000 01 00 00 5b 03 01 54 9a ab 72 98 65 11 2f da 9e ...[..T..r.e./.. 0010 cf c9 db 6c bd 4b 4c 56 4b 0c a5 68 2b aa 60 1f ...l.KLVK..h+.`. 0020 38 66 e7 87 46 b2 00 00 2e 00 39 00 38 00 35 00 8f..F.....9.8.5. 0030 16 00 13 00 0a 00 33 00 32 00 2f 00 9a 00 99 00 ......3.2./..... 0040 96 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 ................ 0050 08 00 06 00 03 00 ff 01 00 00 04 00 23 00 00 ............#.. 01 ClientHello message type 00 00 5b Message length 03 01 SSL version (TLS 1.0) 54 .. b2 32-bytes random number 00 Session Id length 00 2e Cipher Suites length (46 bytes, 23 suites) 00 39 .. ff 23 2-byte Cipher Suite Id numbers 01 Compression methods length (1 byte) 00 Compression method (null) 00 04 Extensions length (4 bytes) 00 23 SessionTicket TLS extension Id 00 00 Extension data length (0)
Second flight (server –> client)
The first flight comprised only one TLS handshake message (ClientHello), which is sent from the client to the server. However, the next TCP packet, sent by the server to the client in response to ClientHello carries 3 Handshake messages. These messages are ServerHello, Certificate and ServerHelloDone (no ServerKeyExchange or CertificateRequest are sent). In the next packet and thereafter, I will omit the lower stack protocols (TCP/IP).
ServerHello message
0000 16 03 01 00 35 02 00 00 31 03 01 54 9a ab 72 85 ....5...1..T..r.
0010 91 a4 a7 a9 27 fe 3d e4 da f6 38 a5 aa 6e 5a 2f ....'.=...8..nZ/
0020 31 90 5b 41 b0 5d de d8 9d ae f6 00 00 35 00 00 1.[A.].......5..
0030 09 ff 01 00 01 00 00 23 00 00 .......#..
16 Handshake protocol type
03 01 SSL version (TLS 1.0)
35 Record length (53 bytes)
02 ServerHello message type
00 00 31 Message length (49 bytes)
03 01 SSL version (TLS 1.0)
54 9a ab 72 First 4 bytes of random (Unix time)
85 .. f6 Last 28 bytes of the random number
00 Session Id length
00 35 Selected Cipher Suite (RSA with AES-256-CBC SHA)
00 Selected compression method (null)
00 09 Extensions length
ff 01 00 01 00 Extension (Renegotiation Info)
00 23 00 00 Extension (SessionTicket TLS)
Certificate message
0000 16 03 01 01 e4 0b 00 01 e0 00 01 dd 00 01 da 30 ...............0
0010 82 01 d6 30 82 01 3f 02 01 01 30 0d 06 09 2a 86 ...0..?...0...*.
0020 48 86 f7 0d 01 01 04 05 00 30 45 31 0b 30 09 06 H........0E1.0..
0030 03 55 04 06 13 02 41 55 31 13 30 11 06 03 55 04 .U....AU1.0...U.
0040 08 13 0a 53 6f 6d 65 2d 53 74 61 74 65 31 21 30 ...Some-State1!0
0050 1f 06 03 55 04 0a 13 18 49 6e 74 65 72 6e 65 74 ...U....Internet
0060 20 57 69 64 67 69 74 73 20 50 74 79 20 4c 74 64 Widgits Pty Ltd
0070 30 1e 17 0d 39 39 30 35 30 31 30 31 32 36 33 35 0...990501012635
0080 5a 17 0d 39 39 30 35 33 31 30 31 32 36 33 35 5a Z..990531012635Z
0090 30 22 31 0b 30 09 06 03 55 04 06 13 02 44 45 31 0"1.0...U....DE1
00a0 13 30 11 06 03 55 04 03 13 0a 54 65 73 74 73 65 .0...U....Testse
00b0 72 76 65 72 30 81 9f 30 0d 06 09 2a 86 48 86 f7 rver0..0...*.H..
00c0 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 ..........0.....
00d0 00 fa 23 7a 03 2a 27 b1 c3 09 64 ce 36 ab eb d0 ..#z.*'...d.6...
00e0 08 16 75 54 68 6f 39 2e d0 9e 81 ed 91 f8 2b 48 ..uTho9.......+H
00f0 0e 59 10 63 0e bc ff c3 1b 4f 7a 2e d2 97 45 01 .Y.c.....Oz...E.
0100 c2 fd 20 68 98 63 76 34 48 73 3d 3e a1 74 d1 13 .. h.cv4Hs=>.t..
0110 b5 30 2b 4d a6 a4 e7 17 74 9c 2e 96 e6 82 01 a3 .0+M....t.......
0120 2a 29 66 59 89 f6 6a 2e de 99 d8 cc 8d 75 4b b7 *)fY..j......uK.
0130 35 96 db 11 a0 20 60 13 59 03 77 d8 a8 1f 26 78 5.... `.Y.w...&x
0140 38 8d 78 b5 52 31 22 c8 b8 64 c3 46 5f d4 8f e0 8.x.R1"..d.F_...
0150 83 02 03 01 00 01 30 0d 06 09 2a 86 48 86 f7 0d ......0...*.H...
0160 01 01 04 05 00 03 81 81 00 c8 0c fa c6 c0 93 c0 ................
0170 df 8d 27 da f9 17 f6 81 c1 97 99 ba ef 64 0c ca ..'..........d..
0180 cc 2f b9 45 4d e4 6a af cd cb 12 17 00 67 28 f5 ./.EM.j......g(.
0190 d6 63 a3 3c d6 7c df f1 b8 6b a9 e5 ba 05 93 e2 .c.<.|...k......
01a0 ab 3f ec 5d 82 c6 aa 18 7b 32 ce 58 04 a2 ac f8 .?.]....{2.X....
01b0 7a 4a 8b 8d 07 95 6e 7a 23 df 7f 61 54 55 3d 32 zJ....nz#..aTU=2
01c0 13 e2 e8 95 0b 3f 18 d7 2a e9 a3 7d 7d 8b 2c d9 .....?..*..}}.,.
01d0 22 91 6e 69 bb 3f 03 7f 75 22 5f 41 22 68 9b dd ".ni.?..u"_A"h..
01e0 ec 4c 0f f0 9e f9 b6 25 13 .L.....%.
16 Handshake protocol type
03 01 SSL version (TLS 1.0)
01 e4 Record length (443 bytes)
0b Certificate message type
00 01 e0 Message length
00 01 dd Certificates length
00 .. 13 Certificates data
ServerHelloDone message
0000 16 03 01 00 04 0e 00 00 00 .........
16 Handshake protocol type
03 01 SSL version (TLS 1.0)
00 04 Record length (4 bytes)
0e ServerHelloDone message
00 00 00 Message lengthThird flight (client –> server)
This all seems right and is consistent with the protocol outlined above. The client and the server has now agreed on the algorithms to use (RSA for key exchange, AES-256-CBC for symmetric encryption and SHA for message hashing), the compression (no compression) and the TLS extensions in use (SessionTicket TLS, Renegotiation Info). Also, the client is now in possession of the server’s certificates, so it can decide whether it will trust the server or not. The next packet is sent by the client and carries the following messages: ClientKeyExchange, ChangeCipherSpec, Finished (which is already encrypted).
ClientKeyExchange message 0000 16 03 01 00 86 10 00 00 82 00 80 2d 28 e4 30 eb ...........-(.0. 0010 31 35 b0 4b 5e 4c 4d c6 ee 01 f5 33 e7 f8 3f 9b 15.K^LM....3..?. 0020 d7 53 fc 5c e0 2d d6 12 ba 55 f8 46 ab 73 d8 3d .S.\.-...U.F.s.= 0030 b0 0a f7 03 7f 58 e0 32 8f 91 1f b8 cf 56 aa 89 .....X.2.....V.. 0040 9e 27 84 08 ec 78 f8 74 0c d3 80 f2 ec 04 65 e1 .'...x.t......e. 0050 3e 92 91 52 b5 5e aa 67 e9 e6 40 e9 10 67 3c 3f >..R.^.g..@..g<? 0060 73 f7 62 4a 0c 42 30 c1 06 6f 53 2f c2 6b d5 c8 s.bJ.B0..oS/.k.. 0070 67 6f 06 d7 92 86 6e 1d 4d dd 6b 3f b0 26 6c 25 go....n.M.k?.&l% 0080 2c d8 81 5a 80 e0 e2 cc d1 62 9c ,..Z.....b. 16 Handshake protocol type 03 01 SSL version (TLS 1.0) 00 86 Record length (134 bytes) 10 ClientKeyExchange message type 00 00 82 Message length (130 bytes) 00 .. 9c RSA encrypted key data (premaster secret) ChangeCipherSpec message 0000 14 03 01 00 01 01 ...... 14 ChangeCipherSpec protocol type 03 01 SSL version (TLS 1.0) 00 01 Message length (1 byte) 01 ChangeCipherSpec message Finished message (encrypted) 0000 16 03 01 00 30 0c c1 86 73 a4 a3 26 62 30 21 7f ....0...s..&b0!. 0010 c3 2f 1a 83 34 2d 57 f0 e2 0d 37 d4 51 66 08 22 ./..4-W...7.Qf." 0020 b0 ea b4 a4 1e 81 2a fd 5f 07 47 9f b7 2c 0a dc ......*._.G..,.. 0030 65 08 77 40 2a e.w@* 16 Handshake protocol type 03 01 SSL version (TLS 1.0) 00 30 Message length (48 bytes) 0c .. 2a Encrypted Finished message
Fourth flight (server –> client)
After the client sends the ChangeCipherSpec and Finished messages, the server is expected to do the same, in order to bilaterally start encrypted communication with the secret symmetric keys and all the agreed Cipher Suite parameters. The server must send its own ChangeCipherSpec and Finished messages so the handshake process can be considered successful. One very interesting thing that happens in this message is that we see one of the extensions in action. The extension is called Transport Layer Security (TLS) Session Resumption without Server-Side State, which states clearly what it does. You should recall that it was requested as part of our ClientHello, and fulfilled by the server in its ServerHello. For information about messages related to this extension, we need to look for the RFC5077 specification. As described in the document, this extension handshake message has been assigned the number 4.
NewSessionTicket message
0000 16 03 01 00 aa 04 00 00 a6 00 00 00 00 00 a0 f7 ................
0010 2f 0c fd be ce f7 96 86 ca fd da 58 d6 16 b3 3c /..........X...<
0020 89 1a a5 a2 af 3c 80 50 7b 99 71 05 3b 0e d3 27 .....<.P{.q.;..'
0030 75 78 0d 0a 20 6c e7 1c ce 7b 5d 52 ad f1 04 88 ux.. l...{]R....
0040 ec fa 04 c9 6a 74 fc 7b 3d 99 aa 8a ec 7a a3 18 ....jt.{=....z..
0050 81 63 2f db b0 16 5b 49 63 f4 53 bc 57 18 27 37 .c/...[Ic.S.W.'7
0060 f2 7f 66 e6 4d 46 59 2d 17 39 d5 79 a4 49 4d 93 ..f.MFY-.9.y.IM.
0070 d2 80 34 8b 49 f5 31 72 7f 7b 41 46 37 9b ae a9 ..4.I.1r.{AF7...
0080 3c f0 6f 2e 7f 75 e3 bf 2f d8 fc a4 be cb 2c 84 <.o..u../.....,.
0090 01 b2 25 01 23 91 6e c0 c1 09 9d 42 c8 b8 e6 1b ..%.#.n....B....
00a0 fe 1e ed b3 52 7f 25 90 ae fc 34 f5 96 1b f0 ....R.%...4....
16 Handshake protocol type
03 01 SSL version (TLS 1.0)
aa 04 Message length (170 bytes)
04 New Session Ticket message type (extension)
00 00 a6 Message length (166 bytes)
00 .. f0 Session Ticket data
ChangeCipherSpec message
0000 14 03 01 00 01 01 ......
14 ChangeCipherSpec protocol type
03 01 SSL version (TLS 1.0)
00 01 Message length
01 ChangeCipherSpec message
Finished message (encrypted)
0000 16 03 01 00 30 6d 09 0e 9f dd 09 03 2f 84 65 f8 ....0m....../.e.
0010 94 0f d6 7b 4b 54 31 a1 25 a4 27 03 ae c3 4e af ...{KT1.%.'...N.
0020 27 04 32 5a 1f 29 90 fa 0a 4b 89 2f af d8 88 99 '.2Z.)...K./....
0030 41 de dd 89 3f A...?
16 Handshake protocol type
03 01 SSL version (TLS 1.0)
00 30 Message length (48 bytes)
6d .. 3f Encrypted Finished messageApplication data (client <–> server)
At this point, the client and server are done with the handshake. Encrypted communication is on place, and application data can be transmitted securely. This is an example record, of which several can be carried in one single TCP packet:
ApplicationData message 0000 17 03 01 00 30 5d 15 3d a2 40 ef d2 01 25 ca 54 ....0].=.@...%.T 0010 26 5f 5d b0 d2 2f 2f 6d 2d ec 56 85 b0 4c a9 bf &_]..//m-.V..L.. 0020 eb 97 be 31 ad cd de 3a b4 71 1e c8 53 96 0b 2d ...1...:.q..S..- 0030 c3 91 3d a2 15 ..=.. 17 ApplicationData protocol type 03 01 SSL version (TLS 1.0) 00 30 Message length (48 bytes) 5d .. 15 Encrypted application data
Closing connection
Since we are already in an encrypted connection, the only way to really know what is being sent within packets is to make Wireshark or similar tools aware of the keys used in the transmission. Even though this is possible, I think for the purpose of this analysis it is enough to know that the client sends an alert message when the connection is asked to be closed actively by the client or server. The type of this Alert message should be CloseNotify (type 0), but we won’t be able to see it from the raw data. In this case, the client is the sender of the following Alert message:
Alert message 0000 15 03 01 00 20 3e 2e 43 30 49 49 6a f6 37 69 eb .... >.C0IIj.7i. 0010 0d dd c3 e2 d3 e1 5d e3 4e b3 e2 22 9d 85 f9 c4 ......].N..".... 0020 59 b3 41 a9 86 Y.A.. 15 Alert protocol type 03 01 SSL version (TLS 1.0) 00 20 Message length (32 bytes) 3e .. 86 Encrypted alert messageConclusion
As far as I can tell from the traffic analysis, the library and the client implementation is doing as expected from the TLS 1.0 specification. I hope this was useful for you to gain some insight of the inner workings of SSL/TLS protocol. I find inspecting hex raw data (specially with such powerful tools as Wireshark) a very instructive and fun way of working with networks.
