Table Of Contents
SSL Public Key Infrastructure Overview
Overview of the ACE SSL Functions
ACE SSL Configuration Prerequisites
Overview of SSL and the ACE
Secure Sockets Layer (SSL) is an application-level protocol that provides encryption technology for the Internet, ensuring secure transactions such as the transmission of credit card numbers for e-commerce websites. SSL provides the secure transaction of data between a client and a server through a combination of privacy, authentication, and data integrity. SSL relies upon certificates and private-public key exchange pairs for this level of security.
This chapter contains the following major sections:
•
Overview of the ACE SSL Functions
•
SSL Cryptography Overview
The Cisco Application Control Engine (ACE) module uses a special set of SSL commands to perform the SSL cryptographic functions between a client and a server. The SSL functions include server authentication, private-key and public-key generation, certificate management, and data packet encryption and decryption.
The ACE supports SSL version 3.0 and Transport Layer Security (TLS) version 1.0. The ACE understands and accepts an SSL version 2.0 ClientHello message, known as a hybrid 2/3 hello message, allowing dual version clients to communicate with the ACE. When the client indicates SSL version 3.0 in the version 2.0 ClientHello, the ACE understands that the client can support SSL version 3.0 and returns a version 3.0 ServerHello message.
Note
A typical SSL session with the ACE requires encryption ciphers to establish and maintain the secure connection. Cipher suites provide the cryptographic algorithms required by the ACE to perform key exchange, authentication, and Message Authentication Code (MAC). See the "Adding a Cipher Suite" section in Chapter 3, Configuring SSL Termination for details about the supported cipher suites.
This section provides an overview of SSL cryptography as implemented in the ACE. It covers:
•
SSL Public Key Infrastructure Overview
SSL provides authentication, encryption, and data integrity in a Public Key Infrastructure (PKI). PKI is a set of policies and procedures to establish a secure information exchange between devices. Three fundamental elements characterize the PKIs used in asymmetric cryptography.
These elements include:
•
•
•
These three elements provide a secure system for deploying e-commerce and a reliable environment for building virtually any type of electronic transactions, from corporate intranets to Internet-based e-business applications.
Confidentiality
Confidentiality ensures that unintended users cannot view the data. In PKIs, confidentiality is achieved by encrypting the data through a variety of methods. In SSL, specifically, large amounts of data are encrypted using one or more symmetric keys that are known only by the two endpoints. Because the symmetric key is usually generated by one of the endpoints, it must be transmitted securely to the other endpoint. The ACE supports the use of the key exchange mechanism for the secure transmission of a symmetric key between the ACE and its peer.
In key exchange, one device generates the symmetric key and then encrypts it using an asymmetric encryption scheme before transmitting the key to its peer. Asymmetric encryption requires each device to have a unique key pair consisting of a public key and a private key. The two keys are mathematically related; data that is encrypted using the public key can only be decrypted using the corresponding private key, and vice versa. A device shares its public key with its peer but must keep its private key a secret. The security of asymmetric encryption depends entirely on the fact that the private key is known only by the owner and not by any other party. If this key were compromised for any reason, a fraudulent web user (or website) could decrypt the stream containing the symmetric key and the entire data transfer. The most commonly used key exchange algorithm is the Rivest Shamir Adelman (RSA) algorithm.
For SSL, the sender encrypts the symmetric keys with the public key of the receiver. This ensures that the private key of the receiver is the only key that can decrypt the transmission.
Authentication
Authentication is necessary for one or more devices in the exchange to verify the identity of the other device. For example, assume a client is connecting to an e-commerce website. Before sending sensitive information such as a credit card number, the client verifies that the server is indeed a legitimate e-commerce website. In certain instances, it may be necessary for both the client and the server to authenticate themselves to each other before beginning the transaction. In a financial transaction between two banks, both the client and the server need to be confident of each other's identity. SSL facilitates this authentication through the use of digital certificates.
Digital certificates are a form of digital identification to prove the identity of the server to the client, or optionally, the client to the server. A certificate ensures that the identification information is correct, and that the public key embedded in the certificate actually belongs to that client or server.
A Certificate Authority (CA) issues digital certificates in the context of a PKI, which uses public-key and private-key encryption to ensure security. CAs are trusted authorities who sign certificates to verify their authenticity. Digital certificates contain the following information:
•
•
•
•
•
As the certificate issuer, the CA uses their private key to sign the certificate. Upon receiving a certificate, a client uses the issuer's public key to decrypt and verify the certificate signature. This ensures that the certificate was actually issued and signed by an authorized entity.
Public key certificates support the concept of certificate hierarchies. This allows a CA to create a hierarchy of subsidiary authorities that share in the responsibility of issuing signed certificates. The CA that sits at the head of the hierarchy is known as the root authority. Each level in the hierarchy certifies the level below it, creating a hierarchy of trusted relationships known as certificate chaining. This process enables an entity verifying a certificate to trace the CA certificates back to the root authority, if needed, to find a CA in the hierarchy it trusts.
A certificate remains valid until it expires or is revoked by the CA. When a CA revokes a certificate, it adds the certificate to a certificate revocation list (CRL) that lists any certificates it previously issued but no longer considers valid.
Clients or servers connected to the ACE must have trusted certificates from the same CA, or from different CAs in a hierarchy of trusted relationships (for example, A trusts B, and B trusts C, therefore A trusts C).
Message Integrity
Message integrity is a means of assuring the recipient of a message that the contents of the message have not been tampered with during transit. SSL achieves this by applying a message digest to the data before transmitting it. A message digest is a function that takes an arbitrary-length message and outputs a fixed-length string that is characteristic of the message.
An important property of the message digest is that it is extremely difficult to reverse. Simply appending a digest of the message to itself before sending it is not enough to guarantee integrity. An attacker can change the message and then change the digest accordingly. Each message exchanged between peers is protected by a MAC, which can be calculated by using a hash algorithm such as SHA or MD5. The MAC is a hash value of several pieces of data, which include a secret value, the actual data being sent, and a sequence number. The secret value is the write session key. The sequence number is a 32-bit counter value. This data is processed by the hash algorithm to derive the MAC. Upon receipt of a message, the receiver verifies the MAC by using the read session key and the predicted sequence number, and calculates the hash over the received data. If the two hash values do not match, the data stream has been modified in some way.
SSL Handshake
The client and server use the SSL handshake protocol to establish an SSL session between the two devices. During the handshake process, the client and server negotiate the SSL parameters that they will use during the secure session. Figure 1-1 illustrates the client/server actions that occur during the SSL handshake.
Figure 1-1 SSL Handshake
Table 1-1 describes the actions that take place between the client and server during the SSL handshake:
ACE SSL Capabilities
Table 1-2 provides information on the SSL capabilities of the ACE.
Overview of the ACE SSL Functions
The ACE is responsible for all user authentication, public/private key generation, certificate management, and packet encryption and decryption functions between the client and the server.
You can partition the ACE into multiple contexts (virtual ACE devices) in which you configure each context with the certificate and key files the context needs to establish an SSL session with its peer. The ACE creates a secure storage area in flash memory for storing the certificates and keys associated with each context you create.
To establish and maintain an SSL session between the ACE and its peer, the ACE uses a system of policy maps that it applies to the traffic it receives. When the characteristics of the traffic match the attributes of a specific policy map, the ACE executes the actions associated with the policy map. Table 1-3 describes the different ACE operational attributes that you define when configuring a policy map for an SSL application.
Depending on how you define the operational attributes listed in Table 1-3, you can configure the ACE to act as a client or a server during an SSL session. Figure 1-2 illustrates the three basic SSL configurations of the ACE, in which the ACE is used to encrypt and decrypt data between the client and server.
Figure 1-2 ACE SSL Applications
The following sections provide an overview of the three ACE SSL applications:
SSL Termination
SSL termination refers to configuring an ACE context for a front-end application in which the ACE operates as an SSL server communicating with a client. When you create a Layer 3 and Layer 4 policy map to define the flow between an ACE and a client, the ACE operates as a virtual SSL server by adding security services between a web browser (the client) and the HTTP connection (the server). All inbound SSL flows from a client terminate at the ACE.
Once the connection is terminated, the ACE decrypts the ciphertext from the client and sends the data as clear text to an HTTP server. For information about configuring the ACE for SSL termination, see Chapter 3, Configuring SSL Termination.
SSL Initiation
SSL initiation refers to configuring an ACE context for a back-end application in which the ACE operates as a client communicating with an SSL server. When you create a Layer 7 policy map to define the flow between an ACE and an SSL server, the ACE operates as a client and initiates the SSL session between the ACE and the server. SSL initiation enables the ACE to receive clear text from a client and then to establish an SSL session with an SSL server and join the client connection with the SSL server connection. The ACE encrypts the clear text it receives from the client and sends the data as ciphertext to an SSL server. The SSL server can either be an ACE configured for SSL termination (virtual SSL server) or a real SSL server (web server).
On the outbound flow from the SSL server, the ACE decrypts the ciphertext from the server and sends clear text back to the client.
For more information on configuring the ACE for SSL initiation, see Chapter 4, Configuring SSL Initiation.
End-to-End SSL
End-to-end SSL refers to configuring an ACE context for both SSL termination and SSL initiation. Configure the ACE for end-to-end SSL when you have an application that requires establishing a secure SSL channel between the client, the ACE, and the SSL server. For example, a transaction between banks requires end-to-end SSL to protect the financial information exchanged between the client and the server.
End-to-end SSL also allows the ACE to insert load balancing and security information into the data. To do this, the ACE decrypts the ciphertext it receives and inserts the load balancing and firewall information into the clear text. The ACE then re-encrypts the data and passes the ciphertext to its intended destination.
For more information on configuring the ACE for end-to-end SSL initiation, see Chapter 5, Configuring End-to-End SSL.
ACE SSL Configuration Prerequisites
Before configuring your ACE for SSL operation, you must first configure it for server load balancing (SLB). During the SLB configuration process, you create the following configuration objects:
•
•
•
•
After configuring SLB, modify the existing SLB class maps and policy maps with the SSL configuration requirements described in this guide for SSL termination, SSL initiation, or end-to end SSL.
To configure your ACE for SLB, refer to the Cisco Application Control Engine Module Server Load-Balancing Configuration Guide.
