Overview of SSL/TLS Encryption
Updated: July 31, 2003
Applies To: Windows Server 2003 with SP1
SSL/TLS is primarily used to encrypt confidential data sent over an insecure network such as the Internet. In the HTTPS protocol, the types of data encrypted include the URL, the HTTP header, cookies, and data submitted through forms. A Web page secured with SSL/TLS has a URL that begins with “https://”.
The SSL/TLS security protocol is layered between the application protocol layer and TCP/IP layer, where it can secure and then send application data to the transport layer. Because it works between the application layer and the TCP/IP layer, SSL/TLS can support multiple application layer protocols.
The SSL/TLS protocol can be divided into two layers. The first layer is the Handshake Protocol Layer, which consists of three sub-protocols: the Handshake Protocol, the Change Cipher Spec Protocol, and the Alert protocol. The second layer is the Record Protocol Layer. Figure 1 illustrates the various layers and their components.
Figure 1. SSL/TLS Protocol Layers
The Handshake Layer
The Handshake Layer consists of three sub-protocols:
Handshake. This sub-protocol is used to negotiate session information between the client and the server. The session information consists of a session ID, peer certificates, the cipher spec to be used, the compression algorithm to be used, and a shared secret that is used to generate keys.
Change Cipher Spec. The Change Cipher Spec sub-protocol is used to change the keying material used for encryption between the client and server. Keying material is raw data that is used to create keys for cryptographic use. The Change Cipher Spec sub-protocol consists of a single message to tell other party in the SSL/TLS session, who is also known is the peer, that the sender wants to change to a new set of keys. The key is computed from the information exchanged by the Handshake sub-protocol.
Alert. Alert messages are used to indicate a change in status or an error condition to the peer. There are a wide variety of alerts to notify the peer of both normal and error conditions. A full list can be found in RFC 2246, “The TLS Protocol Version 1.0.”. Alerts are commonly sent when the connection is closed, an invalid message is received, a message cannot be decrypted, or the user cancels the operation.
Handshake Sub-Protocol Functions
The Handshake sub-protocol provides a number of very important security functions. It performs a set of exchanges that starts authentication and negotiates the encryption, hash, and compression algorithms.
For authentication purposes, the Handshake Protocol uses an X.509 certificate to provide strong evidence to a second party that helps prove the identity of the party that holds the certificate and the corresponding private key. A certificate is a digital form of identification that is usually issued by a certification authority (CA) and contains identification information, a validity period, a public key, a serial number, and the digital signature of the issuer.
A CA is a mutually trusted third party that confirms the identity of a certificate requester (usually a user or computer), and then issues the requester a certificate. The certificate binds the requester’s identity to a public key. CAs also renew and revoke certificates as necessary. For example, if a client is presented with a server’s certificate, the client computer might try to match the server’s CA against the client’s list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. Finally, the client will accept the certificate as proof of identity of the server.
For more information about certificates and how they are used, see http://go.microsoft.com/fwlink/?LinkId=18015.
|Windows Server 2003 includes software that allows it to function as a certification authority. For more information, see Help and Support Center in Windows Server 2003.|
There are two main types of encryption: symmetric key (also known as shared secret key) and asymmetric key (also known as public key or public-private key). SSL/TLS uses both symmetric key and asymmetric key encryption.
Symmetric Key. In symmetric key encryption, the same key is used to encrypt and decrypt the message. If two parties want to exchange encrypted messages securely, they must both possess a copy of the same symmetric key. Symmetric key cryptography is often used for encrypting large amounts of data because it is computationally faster than asymmetric cryptography. Typical algorithms include DES (Data Encryption Standard), 3-DES (Triple DES), RC2, RC4, and AES (Advanced Encryption Standard).
Asymmetric Key. Asymmetric or public key encryption uses a pair of keys that have been derived together through a complex mathematical process. One of the keys is made public, typically by asking a CA to publish the public key in a certificate for the certificate-holder (also called the subject). The private key is kept secret by the subject and never revealed to anyone. The keys work together, with one being used to perform the inverse operation of the other: If the public key is used to encrypt data, only the private key of the pair can decrypt it; if the private key is used to encrypt, the public key must be used to decrypt. This relationship allows a public key encryption scheme to do two important things. First, anyone can obtain the public key for a subject and use it to encrypt data that only the user with the private key can decrypt. Second, if a subject encrypts data using its private key, anyone can decrypt the data by using the corresponding public key. This is the foundation for digital signatures. The most common algorithm is RSA (Rivest, Shamir & Adleman).
SSL/TLS uses public key encryption to authenticate the server to the client, and optionally the client to the server. Public key cryptography is also used to establish a session key. The session key is used in symmetric algorithms to encrypt the bulk of the data. This combines the benefit of asymmetric encryption for authentication with the faster, less processor-intensive symmetric key encryption for the bulk data.
During the Handshake process the hash algorithm is also agreed upon. A hash is a one-way mapping of values to a smaller set of representative values, so that the size of the resulting hash is smaller than the original message and the hash is unique to the original data. A hash is similar to a fingerprint: a fingerprint is unique to the individual and is much smaller than the original person. Hashing is used to establish data integrity during transport. Two common hash algorithms are Message Digest 5 (MD5) and Standard Hash Algorithm 1 (SHA-1). MD5 produces a 128 bit hash value and SHA-1 produces a 160 bit value.
The hash algorithm includes a value used to check the integrity of the transmitted data. This value is established using either a MAC or an HMAC. The MAC uses a mapping function to represent the message data as a fixed-length, preferably smaller, value and then hashes the message. The MAC ensures that the data has not been modified during transmission. The difference between a MAC and a digital signature is that a digital signature is also an authentication method. SSL uses a MAC.
The HMAC is similar to the MAC but uses a hash algorithm in combination with a shared secret key. The shared secret key is appended to the data to be hashed. This makes the hash more secure because both parties must have the same shared secret key to prove the data is authentic. TLS uses an HMAC. For more information about HMAC see RFC 1024, “Keyed-Hashing for Message Authentication.”
For more information about public key cryptography, see “Designing a Public Key Infrastructure” in Designing and Deploying Directory and Security Services of the Microsoft® Windows® Server 2003 Deployment Kit, (or see “Designing a Public Key Infrastructure” on the Web at http://go.microsoft.com/fwlink/?LinkID=4735).
The Record Layer
The protocol at the record layer receives and encrypts data from the application layer and delivers it to the Transport Layer. The Record Protocol takes the data, fragments it to a size appropriate to the cryptographic algorithm, optionally compresses it (or, for data received, decompresses it), applies a MAC or HMAC (HMAC is supported only by TLS) and then encrypts (or decrypts) the data using the information negotiated during the Handshake Protocol.