Chapter 2: SSL VPN Technology

Cisco Press

1 2 3 4 5 6 7 Page 2
Page 2 of 7

Well-known uses of DH algorithms are key exchange and perfect forward secrecy in the Internet Key Exchange (IKE) Protocol, the key exchange protocol for IPsec VPN and the key exchange in the TLS protocol.


RSA and DSA are the two most common public key algorithms used in digital signature applications. RSA was designed by Ron Rivest, Adi Shamir, and Len Adelman (hence RSA) in 1977. Different from the Diffie-Hellman algorithm, the RSA algorithm is based on the fact that no efficient way exists to factor very large numbers. The common key size is 512-bit, 1024-bit, and 2048-bit. The performance of RSA is much slower than secret key algorithms such as DES. So RSA is normally not used for bulk data encryption. It is used mainly in digital signatures to "sign" the digital signature or in digital enveloping to encrypt a secret key that is used to encrypt the data.

In 1991, NIST proposed that the Digital Signature Algorithm (DSA) be used for applications that require digital signatures. It was standardized as the Digital Signature Standard (DSS) by the United States federal government standard for digital signatures.

Digital Signatures and Digital Certification

Authentication and integrity are important properties for secure VPNs. These include entity authentication, data origin authentication, integrity, and nonrepudiation. Digital signatures and certificates provide a scalable trust system. The following sections describe the digital signatures that provide the security properties and digital certification described in the preceding section.

Digital Signatures

In a secure communication, you must often ensure that a message comes from an authentic sender, not from malicious parties who spoof and claim that they are the intended sender. On the flip side, you might also require that the sender of the message cannot later deny being the source of the message (this is known as nonrepudiation). People sign paper documents and use the signatures as proof of authenticity and nonrepudiation. In the digital world, digital signatures (through digital signing) are designed for exactly the same purpose.

Digital signing refers to the action of encrypting the hash of the message by using the sender's own private keys. The output is called a digital signature. From the knowledge you have gained in the previous sections, it is not hard to see why the term digital signature is used: The hash of the message generates an easy-to-calculate, one-way digital fingerprint of the message. Signing using a private key guarantees the authenticity of the source of the message, because only the person who signs the message has the private key. The signature can be easily verified by using the corresponding public key that is posted in the public domain.

Figure 2-3 illustrates the signature verification process. Essentially, the recipient of the message with the corresponding signature performs two calculations: decryption of the received signatures using the sender's public key to get the hash and calculation of the hash using the received message. After these two actions are completed, the recipient compares the two outputs. If they are the same, the recipient verifies the signatures to be authentic.

Figure 2-3

Digital Signature Verification

The common digital signature algorithms are RSA with MD5 or SHA-1 and DSS with SHA-1.

Public Key Infrastructure, Digital Certificates, and Certification

The preceding section showed how you can use digital signatures to achieve important security requirements, such as entity authentication, nonrepudiation, and data origin authentication. You might have noticed that one piece is still missing in the picture. To verify the digital signature, you need to have the sender's public key. This public key should be distributed not only to the public in a scalable way but also be trusted as the true public key of the sender. (For example, Bob can post his public key and claim it is Alice's public key.) In essence, you need to establish a trust system that provides a third-party vetting of, and vouching for, user identities. A public-key infrastructure (PKI) consists of protocols, standards, and services that establish and support the applications of such a trust system.

PKI allows users to authenticate each other use digital certificates that are issued by certificate authorities. The following are the building blocks of a PKI system:

  • X.509: An ITU-T standard for PKI that defines the standard formats for public key certificates.

  • Public-Key Infrastructure X.509 (PKIX): An IETF workgroup that defines the use of digital certificates.

  • Public key cryptography standards (PKCS): Refers to a group of public key cryptography standards devised and published by RSA laboratories. PKCS is the cryptographic foundation of the PKI. Well known standards include the following:

    — PKCS 1 defines the RSA cryptography standard.

    — PKCS 7 defines the Cryptographic Message Syntax Standard, which specifies the signing and encrypting of a message under a PKI.

    — PKCS 10 defines the Certification Request Standard, which specifies the format of messages sent to a certification authority to request certification of a key pair.

The sections that follow examine digital certificates and certification, which are key components of a PKI system.

Digital Certificates

A digital certificate is essentially a binding between a user's identity and its public key. The digital certificates are issued by a third-party entity called a certification authority (CA) to ensure trust in and authenticity of the certificate. The section that follows discusses CAs in the context of the certification process.

Figure 2-4 shows the contents of a digital certificate.

Figure 2-4

X.509 Digital Certificates

The VPN deployment fields shown in Figure 2-4 are as follows:

  • Signature algorithm ID: Specifies the signing algorithm (for example, RSA with SHA-1 or DSS with SHA-1).

  • Issuer (CA) X.500 name: The CA server's identity. Basically, this field specifies who issued this certificate.

  • Validity period: Specifies the lifetime of this certificate. It is a good security practice to set a reasonable lifetime for a certificate. During the certification validation process, the VPN gateway will check the validity period to make sure that the received certificate is still valid.

  • Subject name: Contains the user's identity with the X.500 directory format. For example, cn=vpnuser1, ou=Marketing department, and o=Cisco Systems, Inc.

  • Subject public key: Contains the public key of the user, which is bound to the user's identity.

  • Extension: A placeholder for useful options.

    SubAltName: This is used when the X.500 format is not a good way to represent the user's identity. The SubAltName can be used to represent a user's identity. The SubAltName can be a user's e-mail address or FQDN (fully qualified domain name, often used by networking devices).

    Certificate revocation list (CRL) distribution point (CDP): The CDP is an essential component of a PKI system because it makes the CRL scalable. The CRL contains a list of the serial numbers of revoked certificates. A certificate can be revoked for various reasons, such as ceasing operation and a compromise of private keys. The CA is responsible for revoking certificates and maintaining the CRL. CDP specifies the location (normally a Lightweight Directory Access Protocol [LDAP] search string) where the CRL is stored. During the certificate validation process, VPN devices retrieve CRLs from the CDP and check whether the received certificate has been revoked.

    In a large-scale PKI deployment, the CRL can become large. The Online Certificate Status Protocol (OCSP) is a new Internet protocol designed to provide a more scalable solution to manage the certification revocation status of the X.509 digital certificates. OCSP does not require VPN devices to retrieve the CRL and store and parse it locally.

    With OCSP, the VPN device queries the CA about the certificate revocation status of a digital certificate under its validation. The CA server processes the query and replies with the certificate revocation status. The communication between the VPN devices and the CA server are digitally signed and cryptographically verifiable between the two parties.

  • CA digital signature: This field is the hash of the content of the digital certificate that is signed by the CA server.


Certification is the process of the certification authority (CA) issuing digital certificates. CA is the basis of trust for the entire PKI system and is responsible for verifying users' identity, issuing certificates, revoking certificates, and publishing CRLs. Figure 2-5 illustrates the digital certification and basic certificate validation process.

Figure 2-5

Digital Certification

Alice wants to convey trust to Bob using a digital certificate. First she needs to enroll to the CA server to get her identity certificate. Alice follows these steps:

  1. Alice first requests the root certificate, that is, the certificate of the CA server.

  2. The CA server replies with its root certificate to Alice. Because this is the first communication between Alice and the CA server, no mechanism is predefined to protect this communication. So an out-of-band authentication is required after Alice gets the CA certificate to ensure that no man-in-the-middle attack occurs.

  3. Alice generates a certificate request that has Alice's identity information and her public key. Alice signs the certificate request using the CA's public key that is inside the CA root certificate.

  4. The CA server gets the certificate request, verifies Alice's identity, and generates a digital certificate for Alice, binding her identity and her public key. This identity certificate is signed by the CA, which provides another binding between Alice's identity and the CA's identity.

  5. The CA server issues the certificate to Alice.

  6. Upon receiving her identity certificate, Alice presents it to Bob to convey trust.

  7. Bob follows the digital signature verification process just described to validate Alice's certificate and subsequently establishes trust to Alice's public key.

As you can see, by trusting the CA (its public and private keys), people exchanging information demonstrate trust in the authenticity of the other party using the digital certification process described previously.

Sometimes, the CA delegates some of the tasks previously described to an entity known as a registration authority (RA). The RA provides an interface between the user and the CA server. For example, the interface could be a CGI script on the web server that receives the user's certificate request.

Large scalable PKI systems can have a hierarchical structure that consists of multiple layers of CAs, a root CA, and many subordinate CAs that form certification chaining. During the certification validation process, an end user might want to go up the certification chain to validate the user certificate and all the subordinate certificates up to the root CA.


The following sections provide a brief overview of the SSL and TLS protocols. First, the evolution of these protocols is discussed. This is followed by protocol details to show how SSL and TLS employ the cryptographic building blocks that have just been described to provide secure communication. A short case study follows to show the protocol in action.

SSL and TLS History

The Secure Socket Layer (SSL) was originally developed in the 1990s by Netscape Communications to allow communications to occur securely in the World Wide Web (WWW) environment, which accommodates e-commerce applications such as online shopping. Such applications required secure communications. The design goal was to provide confidentiality, message integrity, identity authentication (server authentication and optional client authentication), and application transparency (to allow SSL to be used to secure other communication protocols such as mail and news).

After the initial publicly released version of SSL v2 in 1994, SSL became popular and a de facto standard. Over the years, the protocol has undergone several improvements and standardizations and is still evolving support for newer technologies and applications.

SSL v2 was released by Netscape Communications in 1994 and deployed on Netscape Navigator browsers. In 1995, Netscape strengthened the cryptographic algorithms of SSL with the release of SSL v3. It addressed several security problems in SSL v2 such as

  • Downgrade attacks: SSL v2 allows attackers to force the selections of weaker ciphers. The release of SSL v3 authenticated the handshake messages, thereby solving this issue.v

  • Truncation attacks: SSL v2 depends on the TCP connection closing to signal the end of transmission. This allows attackers to launch a denial of service attack by forging TCP connection closure. Adding the finished message in SSL v3 solved this problem.

  • Weak MACs: In SSL v2, MAC relies on MD5 only.

Note - SSL v3 also added several new ciphers, such as DSS, DH, and FORTEZZA.

In 1996, the Internet Engineering Task Force (IETF) established the Transport Layer Security (TLS) working group in an effort to standardize SSL protocols from different vendors, mainly Netscape and Microsoft, which developed Private Communication Technology (PCT) and Secure Transport Layer Protocol (STLP). Finally, the standard protocol TLS was published as RFC 2246 in 1999. Overall, TLS is similar to SSL v3 with a few changes and additions.

Two new variants of TLS exist: Wireless TLS (WTLS) and Datagram TLS (DTLS). WTLS is designed to support wireless applications, and DTLS is designed to work over datagram transports such as UDP.

SSL Protocols Overview

1 2 3 4 5 6 7 Page 2
Page 2 of 7