[Show/Hide Left Column]

3. SSL and TLS

3.1 History

SSL is probably the most well known secure internet protocol. SSL was introduced by Netscape to secure the connections between servers and browsers. It gained rapidly popularity in the end 90-ties as a tool to build secure client-server solutions for e-commerce. Banks picked it up for the home-banking solutions. SSL was freely available in the clients (browser). Most often SSL is used in setups where the client easily can check that it is communicating with the right(claimed) server. SSL does support mechanisms that allow a server to authenticate the client this is called client authentication. We return later to these aspects. Although the name SSL is still in use the trend is that SSL is gradually being replaced by TLS. When an application uses SSL it is version 3.0. SSL version 3.0 was Netscape’s final draft and it was published an IETF draft (http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt). TLS sprung out of IETF’s work and was released as Transport Layer Secure (TLS) protocol Version 1.0. IETF used SSL as a model for designing TLS. This explains why TLS Version 1.0 and SSL Version 3.0 are very much alike. Many systems support still SSL 3.0 and even some support the older SSL 0.2 (also called SSL V2) although the latter has several short comings. Many browsers still use handshake implementations that try to be backwards compatible with older servers. This is not trivial and leads to several complications. Yet also browsers tend to abandon SSL V2 support. For example the Opera browser has no longer support for SSL V2. TLS is actively maintained by the IETF but not SSL which, for example, results in that newer encryption algorithms appear in the TLS protocol but not in the SSL protocol, e.g. AES was added to TLS 1.0 in http://tools.ietf.org/html/rfc3268. (external link) Since its introduction TLS underwent several changes and the current version is 1.2. Since in this book we are not interested with the details of the protocols themselves we refer the reader to the standards for more information on how the newer TLS version differ from the original TLS 1.0. For most users the choice of which protocol to use is actually done by the browser and server. Owners of server may decide to increase the strength of protection by adopting the newer versions and disable support in their servers for older protocol versions and or algorithms. Users, however, seldom make active choices here but most browser have configuration options that disable/enable support of specific SSL/TLS versions.

SSL was developed to run on top of TCP. As a consequence the applications that want to use SSL (and TLS) must be adopted for this purpose. Furthermore, if the application uses UDP then the user cannot use SSL or TLS. Instead the user should use DTLS which also runs on top of UDP. DTLS will be discussed in Chapterxxx. There have been other attempts to augment SSL to make it run on UDP but since IETF has standardized DTLS such solutions will likely not be put into general use and we will only treat TLS/SSL to run on TCP.

3.2 TLS revisited

It is good to recall some facts about TLS. We use TLS version 1.2 to describe coarsely the working of TLS. Mutatis mutandis the same applies to SSL. The TLS protocol has itself a two layered architecture; the TLS Record layer protocol and the TLS Handshaking protocols. The latter has thee sub-protocols; the Handshake protocol, the Alert protocol and the Change Cipher Spec protocol, see Figure 3.1

Figure 3.1: The sub protocols of TLS.

The TLS Record Protocol is a layered protocol which processes the data to be transmitted, fragments the data into manageable blocks of at most 2^14 bytes, optionally compresses the data, applies a MAC for integrity protection, encrypts, and transmits the result. Received data is handled in the reversed order: its is decrypted, verified, decompressed, reassembled, and then delivered to higher-level clients.

Four protocols that use the record protocol are described in this document: the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol. In order to allow extension of the TLS protocol, additional record content types can be supported by the record protocol.

The four protocol types, ChangeCipherSpec, Alert, Handshake and Application, are identified by the value 20, 21, 22, 23 respectively in the “Content type” field of SSL/TLS Record Layer.

Handshake Protocol

It’s with value 22 in Content type field, including the “Client Hello”, “Server Hello”, “Certificate” and “Server Hello Done”, four message identifiers in it.

Change Cipher Spec Protocol

With a “Content Type” value 20, it notifies the receiving peer that the subsequent records coming from it will be encrypted.

The Alert Protocol

It has a value of 21 in Content type field. There are two levels of alert: fatal, where the sender will close the session immediately after sending it, and warning, where both sides exchange some warning information, such as subtype “Close Notify” which should be sent by SSL/TLS Protocol before the end of a normal SSL/TLS session.

Application Protocol

With a “Content Type” value 23, different from other threes which are to establish or maintain the SSL/TLS channel, it's to transfer the data payload.

3.3 Examples

SSL/TLS is an application protocol generally run over TCP. In priciple, it is just an infrastructure which could be used in any more higher applications. However, traditionally derived from the web security needs where “https” is devoted to present, SSL/TLS is still the major security protocol applied in “http” application even today.
In the following example where a client use the browser to get access a web server supporting only the server certification authentication mode, the simplest and most typical scenario in practice, we try to present the SSL protocol clear.


OS: Windows XP
Browser: Firefox 3.0 / IE 6.0 (SSL v2 is disable in the IE6.0 of this example)
OS: Fedroal
Web Daemon: Apache httpd

Test steps

  1. open (external link) with Firefox browser and start capturing the traffic flows between the client and SSL Web Server simultaneously.
  2. when Firefox alerts a warning message of “Error code: sec_error_untrusted_ issuer” notifying the unknown certification authority, or IE warns some problems with server’s certification, you can still keep going on just by adding a security exception at the risk of the false certification. Of course, you can instead import your trusted root certification in advance to secure from hasty neglects.
  3. the texts from Web Server is showing up now.
  4. Reload the webpage in order to inspect the TLS/SSL resumption mechanism.
  5. Stop the Wireshark capture process and inspect the captured packets to check what’s happened inside.

Example Demo

Generally speaking, you always have no any certificates of server you will access first. We found that different browsers, even different versions of the same browser, behave differently, especially in the proceedings of certificate authenticated. So the demos in FireFox and IE are to discuss below. For a better interpretation, the packets flow inside them is to cut two parts logically, "before certification accepted" and "certification accepted".

3.3.1 Demo in Firefox

Before Certification Accepted

1. first three packets
The TCP handshake session have to be first established before SSL/TLS protocol could start due to the traditional TCP-based SSL/TLS here.

The SSL session snapshot of traffic flows before certificate accepted.

2. 4th packet
ClientHello (client to server)

(1) Record Layer Protocol Type and Version
Here the value 22 represents Handshake protocol contained in this Record Layer and the client uses TLS version1.0.
(2) Handshake Message type
Here the code 1 identifies the ClientHello message
(3) client side Random
The Random number generated by Client here is a parameter for the key calculation between client and server.
(4) Cipher suites
Here is 34 suites in Firefox and how many different suites available is up to the ability of the browser of the client. The detail of this field extends below.

(5) SessionTicket
SessionTicket is a TLS extension included in the ClientHello message, which define a way to resume a TLS session without requiring session-specfic state at the TLS server. Here the extension is empty thanks to its first connection with server and the client does not already possess a ticket for the server.
As you willl see in next part of demo in IE, IE still don’t support this session resume mechanism.

3. 6th packet
ServerHello (server to client)

(1) Record Layer Protocol Type and Version
The server indicate its use of TLS version 1.0. The protocol here is Handshake.
(2) Handshake Message type
Here the ServerHello is the respond to the client request message “ClientHello”.
(3) server side Random
The random number generated by the server also participates in the key calculation as that of client side does.
(4) selected Cipher Suite
The server checks its support Cipher Suites and select one matched to the Cipher Suites brought up by client in the ClientHello message. Here the TLS_RSA_WITH_AES_256_CBC_SHA is the option, which presents the key exchange use RSA and the encrypted and MAC algorithm are AES and SHA respectively.
(5) SessionTicket
The server here sends an empty SessionTicket extension to indicate that it will send a new session ticket later of NewSessionTicket handshake message before ChangeCipherSpec message finished. However in this case, something is wrong before the proceeding to “ChangeCipherSpec”, that led SessionTicket to never be sent out in the following steps.

4. 7th packet
(Server to client)

(1) Certificate
After sending the ServerHello, the server will continue to forward its certificate to the client.
(2) Server Hello Done
After transferring certificate, the Server Hello Done should be given out to the client according to the TLS negotiation protocol.
As you see in the figure(“Reassembled TCP Segments #6, #7”) , this slice of SSL Layer, including ServerHello, Certificate, Server Hello Done, is bigger and have to be cut into 6th and 7th packets for link carrier limit.

5. 9th packet
(client to server)

Here is Alert protocol with fatal level of “Unknown CA”. Due to its “fatal” level, client should close the SSL/TLS session after sending this notify messages.

6. 10th packet
TCP Reset packet(client to server)

As you see in the 9th packet, sending the “fatal” Alert actually means the end of SSL/TLS session both for sender and recipient, here the client need to send a tcp packet with RST field set to end the TCP-based session.

The client issued Alert Protocol with a fatal level of unknown CA to the server, just because the Firefox browser in the client can’t verify that certificate sent by the server so far and have to hand the errors up to the user making decision on whether to accept the certificate or not. Because the process of user interventions consume rather a long time compared to computer electronic ticks, the lower TCP-based connection should be closed to release the occupied resources in TCP stacks and reconnected again while the certificate decision is ready. However, IE browser does behave differently as you will see later in the part of “demo in the IE”.

Certificate Accepted

All the above is the process of "Test Step1" in protocol layer, If users finish "Test Step2", that means Certification has been accepted from now.

1. 40th - 42nd packets
A new TCP-based connection is brought up and then comes the new SSL/TLS session. Here are the first three TCP handshake packets to set up new TCP session.

2. 43rd packet
ClientHello (client to server)

This packet is similar to the “ClientHello” packet in “Before Certification Accepted” part. However, here we should give more focus on the “SessionTicket” Extention as indexed by number 5 of the figure. Thanks to the prior SSL/TLS negotiation failure with a “fatal” level in handshake, all assigned resources over the previous SSL/TLS session should have been forgotten and the session couldn’t be resumed in next SSL/TLS negotiation. So here the client set “ClientHello” with “SessionTicket ” Extention empty to initiate a new SSL/TLS request.

3. 45th packet
ServerHello (server to client)

This “ServerHello” packet has fully the same view compared with that in “Before Certification Accepted” part. Be attention, here the session ID length is still zero, so it does mean the server support TLS session resumption mechanism by the RFC 5077 as exactly showed in the following.

4. 46th packet (server to client)
Certificate and ServerHello Done

It behaves similarly to the 7th packet in “Certificate unauthorized” part. Actually, TCP payloads of this packet(46th) plus last packet(45th) belong to one SSL/TLS slice as interpreted by Wireshark with “ Reassembled TCP Segments (1841 bytes) :#45(1407), #46(434)” showed in Fig.

5. 48th packet
(Client to server)
ClientKeyExchange message, ChangeCipherSpec and Finished message

Here it is becoming different from the example in “Certificate unauthorized”. Thanks to the acceptance of server’s certificate now, the client can keep going on due sequence of “Client Key Exchange”, “Change Cipher Spec” and “Encrypted Handshake Message” instead of stops as described before.
(1) Client Key Change
Another message type among Handshake Protocol, Client here sends PreMasterSecret to server.
(2) Change Cipher Spec protocol
Sending Change Cipher Spec is just aimed to notify the Server that its data within record layer will be encrypted from now on.
(3) Finished message
While encrypted subjected to (2), here it should be the due sequence of Finished message of HandShake protocol in clear text, indicating the negotiation finished in Client side according to the context of SSL/TLS protocol.

6. 49th packet
(Server to Client)

In response, if all things go well in server side, Web server replys with a Change Cipher Spec Record Layer Protocol, telling the client the later messages coming from server also will be encrypted, and a Handshake Record Layer Protocol presented by Wireshark with “Encrypted Handshake Message” in the Fig. meaning the Finished Handshake message in clear text. At this point, after the client and server exchange the “Finished” message, the SSL/TLS handshake is completed and the Application can be going now.
(1) NewSessionTicket Handshake Message
Encrypted Handshake Message, here it should be NewSessionTicket message type among Handshake protocols according to RFC5077, ruling that NewSessionTicket handshake message should be present before ChangeCipherSpec message finished. With the support of a new SSL/TLS resume mechanism called “SessionTicket” in server side implementation, this part presents here to tell Client that there is an ID in server side that could be used to quickly recovery the underway SSL/TLS session.
(2) Change Cipher Spec protocol
Sending Change Cipher Spec is just to notify the Client that its data within record layer will be encrypted from now on.
(3) Finished message
While encrypted subjected to (2) as well, it is the due sequence of Finished message of HandShake protocol in clear text, meaning the negotiation finished in Server side according to the context of SSL/TLS protocol.

7. 50th-51st packets (Application Data Exchange)
Untill now, the ssl/tls session has been set up, the following is the data exchange above the ssl/tls tunnel. As you see below, here http-based application is inside the tunnel.

50th packet(client to server)
This packet is something like "Get" method of http protocol such as: http://www.google.com (external link)

51st packet
This packet is the response from the peer, just like results got from the web server.

8. 52nd packet (Close notify of Alert protocol from server side)

This is a close notify from the server claimming that the ssl/tls session should be closed because data transfers are finished.

9. 54th packet (close notify in TCP layer from server side)
Thanks to the tcp-based SSL/TLS session, TCP session should be closed accordingly with the shutdown of SSL/TLS session.

10. 56th packet (close notify of Alert protocol in client side)
It serve the same with 52nd packet, but it come from client to response the server. Although the server has already closed, it is a good manner to send such a close notify from the view of developing a program.

11. 57th packet (close in TCP layer in client side)
It is the same with the 54th packet, however here the client use Reset field to close the tcp session.

Reload Test (SSL/TLS session resumed scenario)

1. 62nd -64th packets
The first three packets is to establish TCP connection.

2. 64th packet(client to server)
Client Hello

(1) It does mean that is a message type of client Hello in Handshake protocol
(2) The client generate a session ID included in Client Hello
(3) The ticket content stored in client side

3. 67th packet (server to client)
Server Hello, Change Cipher Spec, Finished

(1) message type: Server Hello in Handshake Protocol
(2) the server must respond with the same session ID in the Client Hello if it is ready to use the ticket stored in the field of SessionTicket TLS in Client Hello
(3) Change Cipher Spec: notify the client that its following data within record layer will be encrypted.
(4) while encrypted, it should be “finished”, a message type of ShakeHand Protocol according to the TLS/SSL context of negotiation.

4. 68th packet (client to server)
Change Cipher Spec, Finished, Application data

(1) Change Cipher Spec: notify the server that its following data within record layer will be encrypted.
(2) whiled encrypted, it should be the “finished” message type of ShakeHand Protocol
(3) it is application data in the SSL/TLS encrypted tunnel. Actually, this part is already not the part of SSL/TLS negotiation, but here we analyse by TCP packet, so this application part is encapsulated into one TCP packet size with the last few parts of negotiation.

5. 69th packet (server to client)
Application data

You can check here the application data is obviously little compared to its first retrievement, because there is no any changed in webpage.

6. 70th packet (server to client)
While encrypted, it should be close notify of Alert protocol in server side.

7. 72nd packet (server to client)
The TCP-layer disconnected notify from server side

8. 74th packet (client to server)
While encrypted, it should be close notify of Alert protocol in client side according the context.

9. 75th packet (client to server)
The TCP-layer disconnected notify in client side

3.3.2 Demo in IE

Before Certification Accepted

1. 3rd-5th packets
The first three are to establish TCP connection.

2. 6th packet (client to server)
Client Hello

(1) ClientHello message type in HandShake Protocol
(2) client side Random
The Random number generated by Client here is a parameter for the key calculation between client and server.
(3) Cipher suites
There is just 11 suites supported in IE6 compared to 34 in FireFox.

3. 8th packet (server to client)
Server Hello

(1)ServerHello message type in HandShake protocol
(2)Server side Random
a parameter generated in server side is also a factor for the shared key calculation.
(3)Session ID
Server generates a ID for the SSL/TLS session resumption later.
(4)The selected cipher suite
The cipher suite picked up by the server, here is TLS_RSA_WITH_RC4_128_MD5

4. 9th packet (server to client)
Certificate, Server Hello Done

(1)certificate message type of Handshake protocol, including the contents of server’s certificate.
(2)Server Hello Done message type of Handshake protocol

5. 11st packet (client to server)
ClientKeyExchange, ChangeCipherSpec protocol, Finished

(1)ClientKeyExchange message type of Handshake protocol, carrying the client side’s material for key generated.
(2)ChangeCipherSpec protocol, telling the server that the data will be encrypted from now on.
(3)Finished message type of Handshake protocol, exactly the same as we have disscussed above, this part should be the notify message type of Handshake protocol according to the context.

6. 12nd packet (server to client)
ChangeCipherSpec protocol, Finished

(1)ChangeCipherSpec protocol, telling the client the following data will be encrypted as well.
(2)It should be Finished message type of Handshake protocol according to the context.

7. 17th packet (client to server)
TCP closed notify to server

Comments: Due to a long time consumption while needing user to get in to authenticate the certificate, client will always cut down SSL/TLS connection to save resources. However, when and where it should cut in SSL/TLS negotiation step is totally different between firefox and IE browser. For firefox as we check in its section, it cut SSL/TLS negotiation immediately after server push down its certificate, as seemed pretty much logically. IE, just as we stop here, instead cut SSL/TLS connection untill SSL/TLS negotiation completed, much late than Firefox did, in a arbitrary way by sending out a FIN flag TCP packet to server.

8. 18th packet(server to client)

Due to the accidental end of TCP connection from the client, here server responds with an Alert message. although the encrypted Alert message, here should be the code with description “close notify” according to the context.

9. 19th-21st packets
These three packets are processing to disconnect the TCP.

Certificate Accepted

Now user has accepted the server side’s certificate or ignored the unknown CA risk and is ready to go on the SSL/TLS session.

1. 22nd-24th packets
Restart TCP connection

2. 25th packet (client to server)

Almost similar to the packet of ClientHello before certificate accepted, the big difference lies at the field of Session ID. Here isn’t empty but a real number which comes from ServerHello in certificate unaccepted section.

3. 27th packet (server to client)

The server responde with the same session ID, which means prior SSL/TLS session will be resumed in this case. Due to the use of resumption, there is no needs to regenerate the time-consumed shared key and the following SSL/TLS handshake become simple.
You also can see here that there is no step to retransmit the server side’s certificate as firefox did. IE just go forward to ChangeCipherSpec and Finished steps.

4. 28th packet(client to server)
ChangeCipherSpec, Finished

Now client knows the resumption of prior SSL/TLS session and skip ClientKeyExchange to ChangeCipherSpec and Finished steps.

5. 30th and 32nd packets
Application Data

Now that the SSL/TLS session has been resumed, the communication data is under protection in secure tunnel.
The 31st packet is encrypted http command like (external link) from IE and the 32nd packet, the encrypted results back to IE in client from Web server.

6. 33rd packets (server to client)
Shutdown TCP session

When server finish the job, it sends a TCP packet with FIN flag notifying client its disconnection of TCP, so the SSL/TLS session based on it has to be gone as well.

7. 35th packet (client to server)
Notifying its close of TCP session, a respond to the 33rd packet.

As checked above, A few difference exist in concrete SSL/TLS implementation related to the certificate issue between IE and Firefox. Firefox refuses to complete SSL/TLS handshake before certicate accepted and restart SSL/TLS handshake negotiation after certificate got accepted, so you can see there are a lot of works to be done again. IE seems more efficient by completing the SSL/TLS handshake first for a ready SSL/TLS session and then resuming that session once the certificate is accepted by user. Clear and simple.

Reload Test (SSL/TLS session resumed scenario)

In fact, the continued SSL/TLS handshake when certificate has got approval, is exactly the process SSL/TLS resumption mechanism used by IE. And so we don’t discuss it any more.

Menu [toggle]