5.11: Case Study - Transport Layer Security (TLS) for the Web
- Page ID
- 58759
The Transport Layer Security (TLS) protocol\(^*\) is a widely used security protocol to establish a secure channel (confidential and authenticated) over the Internet. The TLS protocol is at the time of this writing a proposed international standard. TLS is a version of the Socket Security Layer (SSL) protocol, defined by Netscape in 1999, so current literature frequently uses the name "SSL/TLS" protocol. The TLS protocol has some improvements over the last version (3) of the SSL protocol, and this case study describes the TLS protocol, version 1.2.
The TLS protocol allows client/service applications to communicate in the face of eavesdroppers and adversaries who would tamper with and forge messages. In the handshake phase, the TLS protocol negotiates, using public-key cryptography, shared-secret keys for message authentication and confidentiality. After the handshake, messages are encrypted and authenticated using the shared-secret keys. This case study describes how TLS sets up a secure channel, its evolution from SSL, and how it authenticates principals.
\(^*\) Tim Dierks and Eric Rescorla. The Transport Layer Security (TLS) protocol Version 1.2. RFC 4346. November 2007.
The TLS Handshake
The TSL protocol consists of several protocols, including the record protocol which specifies the format of messages between clients and services, the alert protocol to communicate errors, the change cipher protocol to apply a cipher suite to messages sent using the record layer protocol, and several handshaking protocols. We describe the handshake protocol for the case where an anonymous user is browsing a Web site and requires service authentication and a secure channel to that service.
Figure \(\PageIndex{1}\) shows the handshake protocol for establishing a connection from a client to a server. The CLIENTHELLO message announces to the service the version of the protocol that the client is running (SSL 2.0, SSL 3.0, TLS 1.0, etc.), a random sequence number, and a prioritized set of ciphers and compression methods that the client is willing to use. The session_id in the CLIENTHELLO message is null if the client hasn't connected to the service before.
Figure \(\PageIndex{1}\): Typical TLS exchange of handshake protocol messages.
The service responds to the CLIENTHELLO message with 3 messages. It first replies with a SERVERHELLO message, announcing the version of the protocol that will be used (the lower of the one suggested by the client and the highest one supported by the service), a random number, a session identifier, and the cipher suite and compression method selected from the ones offered by the client.
To authenticate the service to the client, the service sends a SERVERCERTIFICATE message. This message contains a chain of certificates, ordered with the service's certificate first followed by any certificate authority certificates proceeding sequentially upward. Usually the list contains just two certificates: a certificate for the public key of the service and a certificate for the public key of the certification authority. (We will discuss certificates in more detail in Section 5.11.3 below.)
After the service sends its certificates, it sends a SERVERHELLODONE message to indicate that it is done with the first part of the handshake. After receiving this message and after satisfactorily verifying the authenticity of the service, the client generates a 48-byte pre_master_secret . TLS supports multiple public-key systems, and depending on the choice of the client and service, the pre_master_secret is communicated to the service in slightly different ways.
In practice, TLS typically uses a public-key system, in which the client encrypts the pre_master_secret with the public key of the service found in the certificate, and sends the result to the service in the CLIENTKEYEXCHANGE message. The pre_master_secret thus can be decrypted by any entity that knows the private key that corresponds to the public key in the certificate that the service presented. The security of this scheme therefore depends on the client carefully verifying that the certificate is valid and that it corresponds to the desired service. This point is explored in more detail in Section 5.11.3, below.
The pre_master_secret is used to compute the master_secret using the service and client nonce ("+" denotes concatenation):
master_secret ← PRF (pre_master_secret, “master secret”, randomclient + randomserver)
PRF is a pseudorandom function, which takes as input a secret, a label, and a seed. As output it generates pseudorandom bytes. TLS assigns the first 48 bytes of the PRF output to the master_secret. The TLS version 1.2 uses a PRF function that is based on the HMAC construction and the SHA-256 hash function (see Section 5.9 for the HMAC construction and the SHA family of hash functions).
It is important that the master_secret be dependent both on the pre_master_secret and the random values supplied by the service and client. For example, if the random number of the service were omitted from the protocol, an adversary could replay a recorded conversation without the service being able to tell that the conversation was old.
After the master_secret is computed, the pre_master_secret should be deleted from memory, since it is no longer needed and continuing to store it would just create an unnecessary security risk.
After sending the encrypted pre_master_secret , the client sends a CHANGECIPHERSPEC message. This message\(^*\) specifies that all future message from the client will use the ciphers specified as the encrypting and authentication ciphers.
The keys for message encrypting and authentication ciphers are computed using the master_secret , randomclient, and randomserver (which both the client and the service now have). Using this information a key block is computed:
key_block ← PRF (master_secret, “key expansion”, randomserver + randomclient)
until enough output has been produced to provide the following keys:
client_write_MAC_secret[CipherSpec.hash_size]
server_write_MAC_secret[CipherSpec.hash_size]
client_write_key[CipherSpec.key_material]
server_write_key[CipherSpec.key_material]
client_write_IV[CipherSpec.IV_size]
server_write_IV[CipherSpec.IV_size]
The first 4 variables are the keys for authentication and confidentiality, one for each direction. The last 2 variables are the initialization vectors, one for each direction, for ciphers using CBC mode (see Section 5.9). These variables together are the state necessary for the client and the service to communicate securely.
Now the client sends a FINISHED message to announce that it is done with the handshake. The FINISHED message contains at least 12\(^{**}\) bytes of the following output:
PRF (master_secret, finish_label, HASH (handshake_messages))
The FINISHED message is a verifier of the protocol sequence so far (the value of all messages starting at the CLIENTHELLO message, but not including the FINISHED message). The client use the value "client finished" for finish_label . HASH is the same hash function used for the PRF, SHA-256. If the service verifies the hash, the service and client agree on the protocol sequence and the master_secret . TLS encrypts and authenticated the FINISHED message using the cipher suite that the client and service agreed on in the HELLO messages.
After the service receives the client's FINISHED message, it sends a CHANGECIPHERSPEC message, informing the client that all subsequent messages from service to client will be encrypted and authenticated with the specified ciphers. (The client and service can use different ciphers for their traffic.) Like the client, the service concludes the handshake with a FINISHED message, but uses the value "server finished" for finish_label . After both finish messages have been received and checked out correctly, the client and service have a secure (that is, encrypted and authenticated) channel over which they can carry on the remainder of their conversation.
\(^*\) The TLS standard considers CHANGECIPHERSPEC not part of the handshake protocol, but part of the Change Cipher Spec protocol, even though the handshake protocol uses it.
\(^{**}\) Clients may specify in the HELLO message that they prefer more bytes.
Evolution of TLS
The TLS handshake protocol is more complicated than some of the other protocols that we described in this chapter. In a large part, this complexity is due to all the options TLS supports. It allows a wide range of ciphers and key sizes. Service and client authentication are optional. Also, it supports different versions of the protocol. To support all these options, the TLS protocol needs a number of additional protocol messages. This makes reasoning about TLS difficult, since depending on the client and service constraints, the protocol has a different set of message exchanges, different ciphers, and different key sizes. Partly because of these features the predecessors of TLS 1.2, the earlier SSL protocols, were vulnerable to new attacks, such as cipher suite substitution and version rollback attacks.
In version 2 of SSL, the adversary could edit the CLIENTHELLO message undetected, convincing the service to use a weak cipher, for example one that is vulnerable to brute-force attacks. SSL Version 3 and TLS protect against this attack because the FINISHED message computes a MAC over all message values.
Version 3 of SSL accepts connection requests from version 2 of SSL. This opens a version-rollback attack, in which an adversary convinces the service to use version 2 of the protocol, which has a number of well-documented vulnerabilities, such as the cipher substitution attack. Version 3 appears to be carefully designed to withstand such attacks, but the specification doesn't forbid implementations of version 2 to resume connections that were started with version 3 of the protocol. The security implications of this design are unclear.
One curious aspect of version 3 of the SSL protocol is that the computation for the MAC of the FINISHED messages does not include the CHANGECIPHER messages. As pointed out by Wagner and Schneier, an adversary can intercept the CHANGECIPHER message and delete it, so that the service and client don't update their current cipher suite. Since messages during the handshake are not encrypted and authenticated, this can open a security hole. Wagner and Schneier describe an attack that exploits this observation [Suggestions for Further Reading 5.5.6]. Currently, widely used implementations of SSL 3.0 protect against this attack by accepting a FINISHED message only after receiving a CHANGECIPHER message.
TLS is the international standard version of SSL 3.0, but also improves over SSL 3.0. For example, it mandates that a FINISHED message must follow immediately after a CHANGECIPHER message. It also replaces ad-hoc ways of computing hash functions in various parts of the SSL protocol (e.g., in the FINISHED message and master_secret ) with a single way, using the PRF function. TLS 1.1 has a number of small security improvements over 1.0. TLS 1.2 improves over TLS 1.1 by replacing an MD5/SHA-1 implementation of PRF with one specified in the cipher suite in the HELLO messages, preferable based on SHA-256. This allows TLS to evolve more easily when ciphers are becoming suspect (e.g., SHA-1).
Authenticating Services with TLS
TLS can be used for many client/service applications, but its main use is for secure Web transactions. In this case, a Web browser uses TLS to set up a message-authenticated, confidential communication connection with a Web service. HTTP requests and responses are sent over this secure connection. Since users typically visit Web sites and perform monetary transactions at these sites, it is important for users to authenticate the service. If users don't authenticate the service, the service might be one run by an adversary who can now record private information (e.g., credit card numbers) and supply fake information. Therefore, a key problem TLS addresses is service authentication.
The main challenge for a client is to convince itself that the service's public key is authentic. If a user visits a Web site, say amazon.com, then a user wants to make sure that the Web site the user connects to is indeed owned by Amazon.com, Inc. The basic idea is for Amazon to sign its name with its private key. Then, the client can verify the signed name using Amazon's public key. This approach reduces the problem to securely distributing the public key for Amazon. If it is done insecurely, an adversary can convince the client that the adversary has the public key of Amazon, but substitute the adversary's own public key and sign Amazon's name with the adversary's private key. This problem is an instance of the key-distribution problem, discussed in Section 5.6.
TLS relies on well-known certification authorities for key distribution. An organization owning a Web site buys a certificate from one or more certification authorities. Each authority runs a certification check to validate that the organization is the one it claims to be. For example, a certification authority might ask Amazon, Inc. for articles of incorporation to prove that it is the entity it claims to be. After the certification authority has verified the identity of the organization, it issues a certificate. The certificate contains the public key of the organization and the name of the organization, signed with the private key of the certificate authority. (The service sends the certificates in step 3 of the handshake protocol, described in Section 5.11.1 above.)
The client verifies the certificate as follows. First, it obtains in a secure way the public key of certification authorities that it is willing to trust. Typically a number of public keys come along with the distribution of a Web browser. Second, after receiving the service certificates, it uses the public keys of the authorities to verify one of the certificates. If one of the certificates verifies correctly, the client can be confident about the name of the organization owning the service. Whether a user can trust the organization that goes by that name is a different question and one that the user must resolve using psychological means.
TLS uses certificates that are standardized by the ISO X.509 standard. Some of the fields in Version 3 of X.509 certificates are shown below (the standard specifies them in a different order):
structure certificate
version
serial_number
signature_cipher_identifier
issuer_signature
issuer_name
subject_name
subject_public_key_cipher_identifier
subject_public_key
validity_period
The version field specifies the version of the certificate (it would be 3 in this example). The serial_number field contains a nonce assigned by the issuing certification authority and is different for every certificate. The signature_cipher_identifier field identifies the algorithm used by the authority to sign this certificate. This information allows a client of the certification authority to know which of several standard algorithms to use to verify the issuer_signature field, which contains the value of the certificate's signature. If the signature checks out, the recipient can believe that the information in the certificate is authentic. The issuer_name field specifies the real-world name of the certificate authority. The subject_name field specifies the real-world name for the principal. The two other subject fields specify the public-key cipher the principal wants to use (say RSA), and the principal's public key.
The validity_period field specifies the time for which this signature is valid (the start and expiry dates and times). The validity_period field provides a weak method for key revocation. If Amazon obtains a certificate and the certificate is valid for 12 months (a typical number), and if the next day an adversary compromises the private key of amazon.com, then the adversary can impersonate Amazon for the next 12 months. To counter this problem a certification authority maintains a certification revocation list, which contains compromised certificates (identified by the certificate's serial number). Anyone can download the certificate revocation list to check if a certificate is on this blacklist. Unfortunately, revocation lists are not in widespread use today. Good certificate revocation procedures are an open research problem.
The crucial security step for establishing a principal's identity is the certification process executed by the certification authority. If the authority issues certificates without checking out the identity of the organization owning the service, the certificate doesn't improve security. In that case, Lucifer could ask the certification authority to create a certificate for Amazon.com, Inc. If the authority doesn't check Lucifer's identity, Lucifer will obtain a certificate for Amazon, Inc. that binds the name Amazon, Inc. to Lucifer's public key, allowing Lucifer to impersonate Amazon, Inc. Thus, it is important that the certification authority do a careful job of certifying the principal's identity. A typical certification procedure includes paying money to the authority, and sending by surface mail the articles of incorporation (or equivalent) of the organization. The authority will run a partly manual check to validate the provided information before issuing the certificate.
Certification authorities face an inherent conflict between good security and convenience. The procedure must be thorough enough that the certificate means something. On the other hand, the certification procedure must be convenient enough that organizations are able or willing to obtain a certificate. If it is expensive in time and money to obtain a certificate, organizations might opt to go for an insecure solution (i.e., not authenticating their identity with TLS). In practice, certification authorities have a hard time striking the appropriate balance and therefore specialize for a particular market. For example, Verisign, a well-known certification authority, is mostly used by commercial organizations. Private parties who want to obtain a certificate from Verisign for their personal Web sites are likely to find Verisign's certification procedure impractical.
Ford and Baum provide a nice discussion of the current practice for secure electronic commerce using certificate authorities, certificates, etc., and the legal status of certificates \(^*\).
\(^*\) Warwick Ford and Michael S. Baum. Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption. Prentice Hall, second edition, 2000. ISBN: 978–0–13–027276–8. 640 pages.
Although the title implies more generality, this book is about public key infrastructure: certificate authorities, certificates, and their legal status in practice. The authors are a technologist (Ford) and a lawyer (Baum). The book provides thorough coverage and is a good way to learn a lot about the subject. Because the status of this topic changes rapidly, however, it should be considered a snapshot rather than the latest word.
User Authentication
User authentication can, in principle, be handled in the same way as server authentication. The user could obtain a certificate from an authority testifying to the user's identity. When the server asks for it, the user could provide the certificate and the server could verify the certificate (and thus the user's identity according to a certification authority) by using the public key of the authority that issued the certificate. Extensions of the TLS handshake protocol support this form of user authentication.
In practice, and in particular in the Web, user authentication doesn't rely on user certificates. Some organizations run a certificate authority and use it to authenticate members of their organization. However, often it is too much trouble for a user to obtain a certificate, so few Web users are willing to obtain one. Instead, many servers authenticate users based on the IP address of the client machine or based on a shared passphrase. Both methods are currently implemented insecurely.
Using the IP address for authentication is insecure because it is easy for an adversary to spoof an IP address. Thus, when the server checks whether a user on a machine with a particular IP address has access, the server has no guarantees. Typically, this method is used inside an organization that puts all its machines behind a firewall. The firewall attempts to keep adversaries out of the organization's network by monitoring all network traffic that is coming from the Internet and blocking bad traffic (e.g., a packet that is coming from outside the firewall but an internal IP address).
Passphrase authentication is better. In this case, the user sets up an account on the service and protects it with a passphrase that only the user and the service know. Later when the user visits the service again, the server puts up a login page and asks the user to provide the passphrase. If the passphrase is valid, the server assumes that the user is the principal who created the account.
To avoid having the user to type the password on each request, services can exploit a Web mechanism called cookies. A service sends a cookie, a service-specific piece of information, to the user's Web browser, which stores it for use in later requests to the service. The service sends the cookie by including in a response a SET_COOKIE directive containing data to be stored in the cookie. The browser stores the cookie in memory. (In practice, there may be many cookies, so they are named, but for this description, assume that there is only one and no name is needed.) On subsequent calls (i.e., GET or POST) to the service that installed the cookie, the browser sends the installed cookie along with the other arguments to GET or POST.
Web services can use cookies for user authentication as follows. When the user logs in, the service creates a cookie that contains information to authenticate the user later and sends it to the user's browser, which stores it for use in future requests to this service. Every subsequent request from that browser will include a copy of the cookie, and the service can use the information stored in the cookie to learn which user issued this request. If the cookie is missing (for example, the user is using a different browser), the service will return an error to the browser and ask the user to login again. The security of this scheme depends on how careful the service is in constructing the authenticating cookie. One possibility is to create a nonce for a session and sign the nonce with a MAC. Kevin Fu et al. describe some ways to get it wrong and recommend a secure approach\(^*\). Problem Set 28 explores some of the issues in protecting and authenticating cookies.
Websites use cookies in many ways. For example, many sites use cookies to track the browsing patterns of returning visitors. Users who want to protect their privacy must disable cookie tracking in their browser.
\(^*\) K. Fu, E. Sit, K. Smith, and N. Feamster, Dos and don'ts of client authentication on the Web, Proceedings of the tenth USENIX Security Symposium, Washington, August 2001.