TLS (Transport Layer Security) and SSL (Secure Socket Layer)
Introduction
It should be obvious from this Secure Protocols Portal that HTTP is far from the only Internet application that, at least sometimes, requires security. But as HTTP and the web became popular, it became clear that it was important, particularly for web-based transactions, to verify, for example, who is receiving your credit card information. You also wouldn't want the credit card information to be intercepted by someone who might use it to buy himself (or herself) some lovely, expensive gifts. And, you wouldn't want the information to be modified, for example, in a bank transaction. The need for authentication, privacy, and integrity is clear. As there was not yet a standard for securing HTTP when use of the web for commercial transactions began, SSL was developed by Netscape to prevent eavesdropping, tampering, or message forgery for communicating client/server applications. Yeah, Netscape is history. It was the leading web browser, once upon a time!
But I'm not here to tell you how and why some products fade away, or what has happened to Netscape since AOL acquired it. I just wanted you to understand how the acronym SSL became the acronym that is commonly known when people think of secure web applictions. That, and HTTPS. In fact, when getting a certificate to secure a web server, such a certificate is commonly called an SSL certificate, and the CAs typically still use the term SSL, even though the protocol to be used should be TLS, which replaced SSL. So, in reality, this chapter is about TLS and not really about SSL. But so many people are more familiar with the acronym SSL, that if I didn't use it in the chapter heading, some of you might not know that TLS - and not SSL - is what you really want to know about.
In fact, the first version of TLS is based on the SSL 3.0 protocol specification, as published by Netscape. The differences between TLS v1.0 and SSL 3.0 are not dramatic, but they are significant enough that TLS v1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). The version of TLS that is likely to be used these days is TLS v1.0, rather than SSL 3.0, though by adjusting the security settings in a browser, it is possible to revert to SSL 3.0 (though I don't know why you would want to, other than to see the differences in a packet capture). However, it is still quite difficult to find production (rather than test) servers that are running TLS v1.2, which is the latest version. In fact, only some browsers support that version, and I'll get to that issue, later. But first let's take a look at the TLS architecture and how TLS works.
The TLS Architecture
TLS is not just about web (or HTTP) security. It is a protocol intended to provide privacy and data integrity between any two communicating applications. TLS itself has two layers: the TLS Handshake Protocol and the TLS Record Protocol. Within the TCP/IP protocol stack, the TLS Record Protocol is sandwiched between a reliable Transport layer (that means TCP and not UDP) and the Application layer. Though the TLS Handshake Protocol is not really an application protocol, it sits above the TLS Record Protocol in the stack, as shown in Figure 20, and its messages are encapsulated by the TLS Record Protocol.
Figure 20: TLS Protocol Stack
The TLS Handshake Protocol allows the server and the client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. Thus, when a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public key cryptography techniques to generate shared secrets. The TLS Handshake Protocol provides the negotiated security parameters to the Record Protocol layer.
The TLS Handshake Protocol provides connection security with these basic properties and features:
- Peer authentication using public key cryptography, which can be optional, but is usually required by at least one of the communicating parties. Authentication might involve exchanging digital certificates.
- Secure negotiation of a shared secret, using Diffie-Hellman methods, so that the negotiated secret is unavailable to eavesdroppers, and that for any authenticated connection, the secret cannot be obtained, even by with a "man-in-the-middle" attacker.
- Reliable negotiation, which means that no attacker can modify the negotiation communication without being detected by the communicating parties. This property is provided by the Record Protocol layer, which is used to encapsulate the Handshake Protocol messages. Therefore, I will say more about this feature, shortly, in my discussion of the Record Protocol layer.
The TLS Record Protocol provides connection security with two basic properties: privacy and reliability. Privacy is provided using symmetric cryptography, for data encryption. The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol,such as the TLS Handshake Protocol. The Record Protocol can also be used without encryption.
Typically, when I use the term "reliable" when referring to a protocol, I'm referring to an acknowledgment feature, such as the ACK in TCP. However, in this case, the RFC uses the term "reliable" in reference to the TLS Record Protocol to refer to two data integrity features. One is what I usually call (when teaching networking protocols) "error detection". The error detection provided by TCP, the TCP checksum, is done using a rather weak method. With the TCP checksum, it is possible for the data to become corrupted without the checksum detecting it, particularly if there is malicious intent to tamper with a message, because an attacker can manipulate the message in a way that can't be detected by the checksum.
The TLS Record Protocol uses a keyed-hash MAC (Message Authenticity Code), or HMAC, to protect the message's data integrity. An HMAC algorithm takes a secret key and a message and generates a hash. (There are other types of MAC algorithms.) Calculation of the HMAC with the same hash algorithm at the recipient's end of the communication would detect tampering with the data. And, because the recipient of the message with the MAC also has the secret key, the recipient can verify authenticity of the message, which is the second feature included in the RFC's term "reliable". This means that the message could only have been sent by someone with the same key.
Do not confuse "authenticity" of the message with authentication of the sender, such as that done with a digital signature. Because an HMAC uses a symmetric secret key, anyone who can verify an HMAC can also generate one for other messages. So an HMAC is not adequate for non-repudiation. An HMAC is typically smaller and faster than using a digital signature for authentication, so if the HMAC is adequate for the application, it is preferred. Typically, with TLS, a digital signature or certificate or other public key asymmetric method is used for user authentication for the session, during the TLS Handshake, in which the secret key is also established.
The TLS Record Protocol provides "reliability" separately from providing encryption for several reasons, among which is that sometimes only data integrity and authenticity are required, while confidentiality is not, and encrypting the data would result in unnecessary overhead.
TLS in Action - Hands-On Activities
Now we'll take a look at TLS with some hands-on activities. If you are not familiar with Wireshark, now is as good a time as any to download it and familiarize yourself with this excellent free software, which I've used for hands-on activities in some of my other tutorials. You can follow the installation instructions on their website.
As stated above, TLS can be used with any client-server application, but our most typical use is with HTTP. In fact, what is called HTTPS is simply HTTP over TLS (or SSL). While the TCP well-known port number used for HTTP is 80, to distinguish secured traffic from insecure traffic, HTTPS uses port 443, as shown in the packet capture (from Wireshark) in Figure 21.
Figure 21: Using Port 443 for HTTPS
The packet whose details we see in Figure 21 is the first segment sent in the TCP exchange to open an HTTPS connection. As you can see, the client is initiating the connection (notice the SYN flag is set) and sending this segment to port 443, which Wireshark identifies as HTTPS and which you can see is assigned to HTTPS. Wireshark also identifies the source port number as psmond. That is because the Windows operating system insists on disregarding the definition stated in RFC 4340 to use ports 49152 through 65535 for client-side ports and instead uses client-side ports in the range that is reserved for registered ports. Thus, the port number that my computer happened to choose for the client-side, 1788, is registered, though not to an application that we are likely to come across.
After initiating the TCP connection on TCP port 443, the client sends the TLS ClientHello to begin the TLS Handshake Protocol. In Figure 22, we see the first step in this handshake, in which the client suggests using TLS v1.1 and offers a whole bunch of ciphers with which it is willing to implement the security features in this session. When the TLS handshake has finished, the client may then initiate the first HTTP request, where all HTTP data is sent encapsulated in the TLS Record Protocol.
Figure 22: TLS Client Hello
There are too many steps and options in this process to make it practical for me to show a packet capture of each step or variation that might occur. I recommend that you use Wireshark to generate your own captures and look at the output in as much detail as interests you. When trying such an exercise, you will notice that most of your transactions will be using TLS v1.0 or perhaps TLS v1.1. The main incentive to use the latest version of TLS, v1.2, is support of stronger ciphers. If you actually come across a production server that uses TLS v1.2, drop me a note (using the Contact the Dean form)! I make that request because as of this writing (November, 2009), from what I can tell, there are barely any production servers actually using TLS v1.2.
For that matter, the only browswers that implement this version, as far as I know, are Internet Explorer 8 (on Windows 7) (yeah, I actually provided a link to a Microsoft product, figuring that it would look really bad if I only did for Opera) and Opera 10. At this link, you can find a detailed discussion of how well IE8 and Opera 10 each comply with the TLS 1.2 standards, and you will also find some links to servers with which you can check compliance of your browser. To use Opera 10 with TLS 1.2, you must change the securities setting, but since using this feature is not yet common, you need to use the Opera Preferences Editor, which you can access by entering opera:config as the URL, as shown in Figure 23.
Figure 23: Enabling TLS v1.2 in Opera
At this link, you can find a discussion of Opera's TLS v1.2 implementation and a nice discussion of the benefits of TLS v1.2. There is also an explanation of how to test Opera for TLS v1.2 compliance using this website. However, I found that to get to what appears in Figure 24, I had to enable all the versions of TLS (including SSL 3.0).
Figure 24: Testing Opera with TLS v1.2
At Mike's Toolbox home page, you can see that Mike has two servers - one that requests a client certificate and one that does not.
It becomes quite clear that it will still be some time before TLS v1.2 is ubiquitous, but you now can appreciate the reasons behind some of the updates that you might need to make to your browsers. Of course, until the servers are updated to implement the improved security, an up-to-date browser does not improve the security of our online banking.
SSL Certificates - Revisited
Before ending this chapter, let's revisit a concept that you saw in the previous chapter, in light of our discussion of TLS. In that earlier chapter you read how digital certificates are issued and how your browswer authenticates them through a chain of trust. When connecting to a secure website, i.e., a website that enables TLS, following the Client Hello message, the server sends one or more Server Hello messages - also part of the TLS Handshake Protocol, to complete negotiation of the security parameters for the session and mutual authentication. One such Server Hello message would contain the website's (i.e., the server's) certificate, as shown in Figure 25.
Figure 25: Server Sends its Certificate
Returning to examining communication with Banqe Cantonale de Geneve (whose certificate you saw in the previous chapter), we see in Figure 25 that the bank uses SSL 3.0 (a Swiss bank with an outdated security protocol?!) and that its CA is Verisign. Notice in the upper pane that the client (10.0.0.3) sends an ACK to the server and then sends a DNS query for ocsp.verisign.net, which is followed by a DNS response. That's so that the client can use OCSP (Online Certificate Status Protocol) to check the validity of certificate. We also see that an OCSP request and response follow. There are a lot more details that you could examine in such a packet capture (see all the +'s that could be clicked on? - try it with your favorite bank or other secure site!
