SSL Technology White Paper

Keywords: SSL, PKI, MAC

Abstract: SSL provides secure connection services for TCP-based application layer protocols by using data encryption, identity authentication, and integrity authentication mechanisms. This document presents the background, security mechanism, operation process, and application scenarios of SSL.

Acronyms:

Acronym

Full spelling

AES

Advanced Encryption Standard

CA

Certificate Authority

DES

Data Encryption Standard

HTTPS

Hypertext Transfer Protocol Secure

MAC

Message Authentication Code

MD5

Message Digest 5

PKI

Public Key Infrastructure

RSA

Rivest Shamir and Adleman

SHA

Secure Hash Algorithm

SSL

Secure Sockets Layer

VPN

Virtual Private Network

 



Overview

Background

Web-based applications such as E-business and online banking facilitate people’s daily life greatly. For these applications that need to support online trading, communication security is a key problem. However, the traditional Hypertext Transfer Protocol (HTTP) provides no security mechanism; it transmits data in plain text, does not support identity authentication, and cannot prevent data from being tampered with during transmission. This is where the Secure Sockets Layer (SSL) comes in.

SSL was first proposed by Netscape. Integrated with data encryption, identity authentication, and message integrity authentication mechanisms, it can ensure the security of data transmitted on the network. SSL can provide security connection service for HTTP, improving the security of the World Wide Web (WWW) dramatically.

Benefits

SSL features these benefits:

l          Higher security. Integrated with data encryption, identity authentication, and message integrity authentication mechanisms, it can ensure the security of data transmitted on the network.

l          Support for various application layer protocols. SSL was originally designed to solve the security problem on the Web. However, as it resides between the transport layer and the application layer, it can provide security service for any application layer protocol that employs TCP connections.

l          Simple to deploy. Currently, SSL has become a global standard for identity authentication between the browser and server. It has been integrated into most browsers, such as IE, Netscape, and Firefox. This means that almost every computer with a browser supports SSL connections, without requiring any extra client software.

Security Mechanisms of SSL

SSL provides these security mechanisms:

l          Confidentiality: SSL uses a symmetric encryption algorithm to encrypt data to be transmitted.

l          Identity authentication: SSL supports certificate-based identity authentication of the server and client by using the digital signatures, with the authentication of the client being optional.

l          Message integrity verification: SSL uses Message Authentication Code (MAC) algorithms to verify message integrity.

Confidentiality

Data being transmitted on the network may be intercepted and stolen easily. SSL can ensure the confidentiality of data in transit by establishing an encrypted channel between the communication peers.

With this encrypted channel, the data sender encrypts the data to be transferred by using an encryption algorithm and an encryption key before sending the data, while the receiver uses the corresponding decryption algorithm and decryption key to retrieve the data. No one else can get the key and retrieve the data. This ensures the confidentiality of the data.

Encryption/decryption algorithms fall into two categories:

l          Symmetric algorithm: The encryption and decryption processes use the same key.

l          Asymmetric algorithm: The encryption and decryption processes use different keys of a key pair. A key pair consists of two keys, one is the public key, and the other is the private key, which is kept secret by the user. Data encrypted with the public key or private key of a key pair can only be decrypted by using the private key or public key or the key pair.

Compared with asymmetric algorithms, symmetric algorithms feature high speed and usually apply to scenarios where large amounts of data need to be encrypted, for example, when all packets need to be encrypted. Asymmetric algorithms are usually used for digital signature and encryption of a little information.

An SSL encrypted channel uses a symmetric encryption algorithm to encrypt data. Currently, SSL supports these algorithms: Data Encryption Standard (DES), Triple Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). These algorithms can effectively prevent data from being eavesdropped.

A symmetric algorithm uses the same key for encryption and decryption. Therefore, before data being encrypted by a symmetric algorithm, the communication peers must obtain the same key. For key deployment of a symmetric algorithm, refer to Using an Asymmetric Algorithm to Secure the Key.

Identity Authentication

An application such as E-business or online banking must ensure the authenticity of Web servers, so as to prevent information from being eavesdropped. SSL employs digital signatures to authenticate the identities of communication peers.

An asymmetric encryption algorithm can be used to implement digital signature. As data encrypted with a private key can be decrypted only with the corresponding public key, you can determine the identity of a sender by checking whether the encrypted data of the sender can be decrypted by using the sender’s public key. And the process that a sender encrypts the data with the private key is just like putting a signature to the data. For example, Alice encrypts a fixed piece of information with her private key and then sends the encrypted information to Bob. Bob decrypts the information with Alice’s public key. If Bob obtains the same fixed piece of information, he assumes that the information is from Alice.

The SSL client must authenticate the identity of the SSL server, while whether the SSL server authenticates the identity of the SSL client depends on the SSL server. For the identity authentication process between the SSL client and server, refer to SSL Handshake Process.

When digital signature is used for identity authentication, it is required to make sure that the public key of an entity is really that of the entity. This is to avoid the situation when an illegal user pretends to be a legal user and communicates with the authenticator. As shown in Figure 1, Cindy, pretending to be Bob, sends her public key to Alice and uses her private key to encrypt a fixed piece of information and sends the resulting information to Alice. Alice decrypts the information with the public key of Bob, which is actually that of Cindy, and assumes that she is communicating the Bob. SSL uses the Public Key Infrastructure (PKI) to ensure the authenticity of a public key. For details, refer to Using PKI to Guarantee the Authenticity of Public Keys.

Figure 1 Forged public key

 

Message Integrity Verification

SSL can use MD5- and SHA-based MAC algorithms to verify the integrity of a message.

A MAC algorithm functions with the participation of a key. Using a key, it can transform a piece of data of any length to data of a fixed length. Figure 2 shows the operation process of a MAC algorithm. The sender uses the MAC algorithm and the key to compute the MAC value of a message, suffixes the MAC value to the message and sends the resulting packet to the receiver. The receiver uses the same MAC algorithm and key to compute the MAC value and compares it with the received MAC value. If the two are the same, no change has occurred to the packet. Otherwise, the receiver assumes that the packet has been tampered with and will drop the packet.

Figure 2 MAC algorithm

 

MAC algorithms verify the integrity of a message based on these features:

l          Any change to the message will make the generated message of a fixed length different, and comparing the MAC values will find that the message has been altered.

l          A MAC algorithm needs the participation of a shared key. This is to ensure that illegal users without the key cannot figure out the correct MAC value after changing the message.

As MAC algorithms require that the communication peers have the same key, you need to deploy the same key to the peers in advance. For the way to deploy such a key, refer to Using an Asymmetric Algorithm to Secure the Key.

Using an Asymmetric Algorithm to Secure the Key

Symmetric encryption algorithms and MAC algorithms require that the communication peers have the same key. Therefore, for an encrypted channel to be established between two peers or to verify the message integrity, you need to deploy the same key to the two peers in advance.

SSL employs an asymmetric algorithm to encrypt the key to be exchanged, so as to prevent the key from being obtained by any third party. As shown in Figure 3, the SSL client (for example, the Web browser) uses the public key of the SSL server (for example, the Web server) to encrypt the key and then sends the encrypted key to the SSL server. Only the SSL server that has the corresponding private key can decrypt the information and obtain the key. SSL usually uses the Rivest Shamir and Adleman (RSA) algorithm to encrypt the key to be transmitted.

Figure 3 key exchange

 

l          In fact, the key that the SSL client sends to the SSL server is only the premaster secret, which will not be used to encrypt data or compute the MAC value directly. The SSL client and server will use the premaster secret to compute the master secret, and then use the master secret to generate the keys for the symmetric algorithm and MAC algorithm to use. The previous description simplifies the process for convenience of understanding.

l          An algorithm for key exchange is called a key exchange algorithm. When asymmetric algorithm RSA is used for key exchange, it is also called a key exchange algorithm.

 

Before using an asymmetric algorithm to encrypt the key, a sender needs to obtain the public key of the receiver and ensure the authenticity of the public key. Otherwise, the key may be intercepted by illegal users, as shown in Figure 1. Cindy, pretending to be Bob, sends her public key to Alice. Alice uses the public key of Cindy to encrypt the data to be sent to Bob. As Bob does not have the corresponding private key, he cannot decrypt the data; while Cindy has the corresponding private key and therefore can obtain the data. SSL uses the Public Key Infrastructure (PKI) to ensure the authenticity of a public key. For details, refer to Using PKI to Guarantee the Authenticity of Public Keys.

Using PKI to Guarantee the Authenticity of Public Keys

PKI uses digital certificates to publish the public keys of users and provides a mechanism for verifying the authenticity of the public keys. A digital certificate is a file that contains the public key and identity information of a user. It is used to prove the binding between the user and the public key. A digital certificate is signed and issued by a certificate authority (CA). A CA is responsible for the authenticity of the digital certificates that it issues.

Before the SSL client sends the key to the SSL server, the SSL server needs to obtain a certificate from the CA and send it to the SSL client. The SSL client can verify the authenticity of the certificate through PKI. If the certificate really belongs to the SSL server, the SSL client uses the public key in the certificate to encrypt the key and sends the encrypted key to the SSL server.

Before the SSL client authenticates the identity of the server, the server needs to obtain a certificate from the CA and send it to the SSL client. The client can verify the authenticity of the certificate through PKI. If the certificate really belongs to the SSL server, the client will use the public key in the certificate to authenticate the identity of the server. The similar is true for the scenario where the SSL server needs to authenticate the identity of the client.

Operation of SSL

SSL Protocol Stack

Figure 4 SSL protocol stack

 

As shown in Figure 4, the SSL protocol is between the transport layer and application layer. It can provide security for all application protocols based on TCP connections. The SSL protocol stack consists of two layers of protocols: the SSL record protocol at the lower layer and the SSL handshake protocol, change cipher spec protocol, and alert protocol at the upper layer.

l          SSL handshake protocol: As a very important part of the SSL protocol stack, it is responsible for negotiating the cipher suite to be used during communication (including the encryption algorithm, key exchange algorithm, and MAC algorithm), exchanging the key between the server and client, and implementing identity authentication of the server and client.

l          SSL change cipher spec protocol: Used for notification between a client and the server that the subsequent packets are to be protected and transmitted based on the newly negotiated cipher suite and key.

l          SSL alert protocol: Allowing a client and the server to send alert messages to each other. An alert message contains the alert severity level and a description.

l          SSL record protocol: Fragmenting data to be transmitted, computing and adding MAC value to the data, and encrypting the data before transmitting it to the peer end.

SSL Handshake Process

Through the SSL handshake protocol, an SSL client and server negotiate the parameters to be used and establish a session between them. A session consists of a set of parameters, including the session ID, peer certificate, cipher suite, and master secret. All data of a session will use the master secret and cipher suite of the session for encryption and MAC computing.

The SSL handshake process may vary, depending on the situations. The following gives the SSL handshake processes in three situations:

l          Handshake Process with Identity Authentication of only the Server

l          Handshake Process with Identity Authentication of Both Ends

l          Handshake Process When Reusing a Session

Handshake Process with Identity Authentication of only the Server

Figure 5 Handshake process with identity authentication of only the server

 

As shown in Figure 5, if only identity authentication of the server is required, the SSL handshake process is as follows:

1)        The SSL client sends a Client Hello message to the SSL server, telling the server such information as the SSL version, encryption algorithms, key exchange algorithms, and MAC algorithms that it supports.

2)        The SSL server determines the SSL version and cipher suite to be used for the communication, and notifies the SSL client through a Server Hello message. If the server allows the SSL client to reuse the session for communications that may occur later, the server will assign a session ID to the session and notify the client of the session ID through the same Server Hello message.

3)        The SSL server sends its local certificate to the client through a Certificate message.

4)        The SSL server sends a Server Hello Done message to the client, informing the client that the version and cipher suite negotiation is over and the key exchange process will start.

5)        The SSL client obtains the public key of the SSL server from the received certificate and verifies the authenticity of the SSL server’s certificate. If server’s certificate is OK, the client generates a premaster secret randomly, uses the server’s public key to encrypt the premaster secret, and then sends the premaster secret to the server through a Client Key Exchange message.

6)        The SSL client sends a Change Cipher Spec message to the server, informing the server that the subsequent packets will use the negotiated key and cipher suite for encryption and MAC computing.

7)        The SSL client computes the hash value of the exchanged handshake messages (except for the Change Cipher Spec message), processes the hash value with the negotiated key and cipher suite (that is, computes and suffixes the MAC value and performs encryption), and then sends a Finished message to the SSL server. The SSL server uses the same means to compute the hash value and compares the hash value with that received from the client. If the two matches, the MAC authentication succeeds, which means that the key and cipher suite negotiation succeeds.

8)        Similarly, the SSL server sends a Change Cipher Spec message to the client, informing the client that the subsequent packets will use the negotiated key and cipher suite for encryption and MAC computing.

9)        The SSL server computes the hash value of the exchanged handshake messages, processes the hash value with the negotiated key and cipher suite (that is, computes and suffixes the MAC value and performs encryption), and then sends a Finished message to the SSL client. The SSL client uses the same means to compute the hash value and compares the hash value with that received from the server. If the two matches, the MAC authentication succeeds, which means that the key and cipher suite negotiation succeeds.

Upon receiving the Finished message from the SSL server, the SSL client tries to decrypt the message, and if it can do so successfully, it assumes that the SSL server is really the server that it wants to communicate with, that is, identity authentication of the server succeeds. This is because only the intended SSL server has the private key and can decrypt the Client Key Exchange message and obtain the premaster secret.

 

l          The Change Cipher Spec message belongs to the SSL change cipher spec protocol. All the other messages exchanged during the handshake process belong to the SSL handshake protocol and are referred to as SSL handshake messages.

l          Computing the hash value means using a hash algorithm (MD5 or SHA) to transform data of variable length to data of a fixed length.

 

Handshake Process with Identity Authentication of Both Ends

Figure 6 Handshake process with identity authentication of both ends

 

Identity authentication of the SSL client is optional and depends on the SSL server. As shown in Figure 6, if the SSL server wants to authenticate the identity of the SSL client, the SSL server and client will go through the steps described in Handshake Process with Identity Authentication of only the Server as well as the steps in blue in Figure 6:

1)        The SSL server sends a Certificate Request message to the SSL client to ask for the client’s certificate.

2)        The SSL client sends its certificate to the SSL server through a Certificate message. The SSL server verifies the authenticity of the certificate.

3)        The SSL client computes the hash value of the exchanged handshake messages, uses its private key to encrypt the value, and then sends the value to the SSL server through a Certificate Verify message.

4)        The SSL server computes the hash value of the exchanged handshake messages and master secret, uses the client’s public key to decrypt the hash value received from the client, and compares the two hash values. If the two matches, identity authentication of the SSL client succeeds.

Handshake Process When Reusing a Session

Figure 7 Handshake process when reusing a session

 

During the session parameter negotiation and session establishment process, an asymmetric encryption algorithm is used to encrypt the key and authenticate the identity of the peers. This means a large amount of computation and a lot of system resource consumption. To simplify the SSL handshake process, SSL allows reusing a negotiated session. The details are as follows:

1)        The SSL client sends a Client Hello message to the server, setting the session ID to the ID of the session that it wants to reuse.

2)        If the SSL server allows reuse of the session, it sends a Server Hello message carrying the same session ID to the client. Thus, the SSL client and server can reuse the key and cipher suite of a negotiated session, rather than go through all the trouble to renegotiate one.

3)        The SSL client sends a Change Cipher Spec message to the server, informing the server that the subsequent packets will use the key and cipher suite of the session for encryption and MAC computing.

4)        The SSL client computes the hash value of the exchanged handshake messages, uses the key and cipher suite of the session to process the hash value, and then sends the value to the SSL server through a Finished message. This is for the SSL server to determine whether the key and cipher suite are correct.

5)        Similarly, the SSL server sends a Change Cipher Spec message to the client, informing the client that the subsequent packets will use the key and cipher suite of the session for encryption and MAC computing.

6)        The SSL server computes the hash value of the exchanged handshake messages, uses the key and cipher suite of the session to process the hash value, and then sends the value to the SSL client through a Finished message. This is for the SSL client to determine whether the key and cipher suite are correct.

Application Scenarios

HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is SSL connection-based HTTP. Employing the security mechanisms that SSL provides, namely the confidentiality, identity authentication, and message integrity verification mechanisms, HTTPS can guarantee the security of Web access. Therefore, HTTPS has been widely used in fields such as online banking and E-business.

Figure 8 shows an application of HTTPS in an online bank. For convenience of customers, a bank provides online banking services. Customers can query their accounts and transfer money between accounts through the Web server of the bank. It is required that an SSL connection is established between a customer and the Web server of the bank to prevent the customer’s information from being intercepted.

Figure 8 Network diagram for HTTPS application in a online bank

 

SSL VPN

SSL VPN is another application based on SSL. SSL VPN uses the security mechanisms of SSL to allow remote users of a corporate network to access the network securely. As shown in Figure 9, SSL VPN establishes SSL connections between remote users using various access methods and the SSL VPN gateway, allowing the users to access the corporate network through various Web browsers from any place. At the same time, SSL VPN can ensure the security of the corporate network and protect the information of the corporate from being stolen.

Figure 9 Network diagram for SSL VPN

 

References

l          draft-freier-ssl-version3-02: The SSL Protocol Version 3.0

 

Copyright ©2009 Hangzhou H3C Technologies Co., Ltd. All rights reserved.

No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Hangzhou H3C Technologies Co., Ltd.

The information in this document is subject to change without notice.