Introducing SSL and Certificates

1. Introduction
2. Cryptographic Techniques
3. Certificates
4. SSL
5. Implementing SSL
6. Further Reading

1. Introduction

The Secure Sockets Layer protocol [SSL3] provides one means for achieving authentication, integrity, and privacy on the Web.

This document provides an introduction to SSL concepts for someone who is familiar with the Web, HTTP, and Web servers but is not a security expert. It is not intended to be a definitive guide to the SSL protocol, nor does it discuss specific servers or techniques for managing certificates in an organization. It also ignores the important legal issues of patents and import and export restrictions [1]. The goal of this and its companion document, OpenSSL Certificate Cookbook, is to provide a starting point for further exploration, for those who want to understand what is involved with providing SSL support in a server, with examples.

2. Cryptographic Techniques

Understanding SSL requires an understanding of cryptographic algorithms, message digest functions, and digital signatures. These techniques are the subject of entire books [Schneier], and provide the basis for privacy, integrity, and authentication.

Cryptographic Algorithms

Suppose Alice wants to send a message to her bank to transfer some money, including some information she would not want others to see, such as the account number or transfer amount. Alice would like the message to be private. A cryptographic algorithm could be used to transform her message into an encrypted form. Once the message has been made unreadable it may only become understandable through the use of a secret key. Without the secret key the message is useless because it would take too much time and work to decode. There are two categories of cryptographic algorithms: conventional and public key.

Conventional cryptography, also known as symmetric cryptography, requires the sender and receiver to share a key, a secret piece of information which may be used to encrypt or decrypt a message. Only those who have the key (the sender and receiver) may read the message. If Alice and the bank know a secret key then they may send each other private messages. A problem is that Alice and the bank must choose a key before communicating in private.

Another approach is to use public key cryptography. Public key cryptography (also known as asymmetric cryptography) solves the key exchange problem by defining an algorithm which uses two keys, each of which may be used to encrypt a message. If one key is used to encrypt a message then the other must be used to decrypt it. This makes it possible to securely receive messages without determining how to share a secret key: simply publish one key (the public key) and keep the other secret (the private key). Anyone may encrypt a message using the public key, but only the owner of the private key will be able to read the message. Thus, everyone may send private messages to anyone who has a key-pair and has made the public key known (and has kept the private key to themselves). If Alice is given the public key of the bank she may send her message to the bank by encrypting it using the bank's public key. Only the bank will be able to decrypt it.

Message Digests

Although Alice may encrypt her message to make it private, she might also worry that someone might modify the message or substitute a different one, such as transferring money to themselves. Alice wants to guarantee the integrity of her message. One way to do this is to create a concise summary of the message and send this to the bank as well. When the bank receives the message it also creates the summary and compares it with the summary which Alice sent. If they agree then the message was received intact.

Such a summary is called a message digest, or one-way hash. Message digests are used to create short, fixed-length representations of longer, variable-length messages. Digest algorithms are designed to produce unique digests for different messages, and to make it too difficult to determine the message from the digest. They are also designed to make it impossible to find two different messages which create the same digest (to eliminate the possibility of substituting one message for another while still having the same digest).

As long as Alice is able to send the digest to the bank securely, then the integrity of the associated message is assured. One way to to this is to include the digest in a digital signature.

Digital Signatures

When Alice sends a message to the bank, the bank wants to know that the message is really from her, so someone else does not request a transaction involving her account. If she is able to create a digital signature which nobody but her can create, and includes it with the message, then the bank may believe that the message is from her.

A digital signature is created by encrypting a digest of the message, along with other information such as a sequence number, with the sender's private key. Anyone may decrypt the signature using the public key, but since only the signer knows the private key, only they may have signed it. Including the digest in the signature means the signature is only good for that message, and also ensures the integrity of the message since no one can change the digest and still sign it. To ensure that somebody cannot intercept the signature and reuse it later, the signature contains a unique sequence number. The bank is assured that Alice cannot claim she did not send the message, since only she could have signed it (non-repudiation).

3. Certificates

Although Alice may send a private message to the bank, sign it, and be sure the message isn't changed, she needs to be sure that the public key of the bank is really for the bank. The bank also needs to be sure that the message signature really corresponds to Alice. If each has a certificate which says who the other is, confirms the public key, and is signed by a trusted agency, then they both will be assured that they are communicating with whom they think they are. Such a trusted agency is called a Certificate Authority, and certificates are used for authentication.

Certificate Contents

A certificate associates a public key with the real identity of an individual, server, or other entity, known as the subject. Information about the subject includes identifying information (the distinguished name), and the public key. It has the identification and signature of the Certificate Authority which issued the certificate, and the period of time during which the certificate is valid. It may have additional information (or extensions) as well as administrative information for the Certificate Authority's use, such as a serial number.

A distinguished name is used to provide an identity in a specific context (e.g. an individual might have a personal certificate as well as one for their identity as an employee). Distinguished names are defined by the X.509 standard [Kaufman], which defines the fields as well as the field names and abbreviations used to refer to the fields. A Certificate Authority may define a policy which specifies which distinguished field names are optional, and which are required. It may also place requirements upon the field contents, as may users of certificates. As an example, a Netscape browser requires that the Common Name for a certificate representing a server have a name which matches a regular expression for the domain name of that server (e.g. *.opengroup.org).

The binary format of a certificate is defined using the ASN.1 notation [ ASN.1]. This notation defines how to specify the contents; encoding rules define how this information is translated into binary form. The binary encoding of the certificate is defined using Distinguished Encoding Rules (DER), which are based on the more general Basic Encoding Rules (BER). The binary form may be translated into an ASCII form for transmissions which cannot handle binary by using base64 encoding. This encoded version is called PEM encoded, when placed between the lines:

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

Certificate Authorities

A Certificate Authority certificate provides assurance that the identity of the holder of the private key of a key-pair is really who the certificate says it is. The Certificate Authority does this by verifying the information in a certificate request before granting the certificate. If Alice requests a personal certificate, the Certificate Authority must first make sure that Alice really is the person the certificate says she is.

Certificate Chains

A Certificate Authority may also issue a certificate for another Certificate Authority. When examining a certificate, Alice may need to examine the certificate of the issuer, for each parent Certificate Authority until reaching one which she has confidence in. She may decide to only trust certificates with a limited chain of issuers, to reduce her risk that one certificate in the chain is bad.

Creating a Root Level Certificate Authority

One problem with certificates is that each requires an issuer to assert the validity of the identity of the certificate subject, yet there must be a top-level Certificate Authority. Since this is the top-level authority, there is no issuer for its certificate, so who vouches for its certificate? In this case, the certificate is "self-signed", so the issuer of the certificate is the same as the subject. As a result, extra care must be taken in trusting a self-signed certificate. Trust is usually established because the root authority publishes its public key widely. Clients and Servers are configured to trust certain certificate authorities by default.

There are a number of companies, such as VeriSign [VeriSign] which have established themselves as certificate authorities. They provide techniques for requesting certificates, have procedures for verifying information, and issuing and managing certificates. It is also possible to create ones own Certificate Authority. Although risky in the Internet, within an Intranet this may be useful, where the organization is easily able to verify the identities of individuals and servers.

Certificate Management

Establishing a Certificate Authority is a responsibility which requires a solid administrative, technical, and management framework. Certificate Authorities not only issue certificates, but also manage them. This means that they determine how long certificates are valid, renew them, and keep lists of certificates which have been issued but are no longer valid (certificate revocation lists, or CRLs). If Alice works for a company, and has a certificate as an employee, when she leaves the company the certificate will need to be revoked. Certificates are objects which are passed around, and it is impossible to tell from the certificate alone that it has been revoked. When examining certificates for validity it is necessary to contact the issuing Certificate Authority to determine if the certificate has been revoked, but this is usually not an automated part of the process. In a system where revocation matters, it is necessary to ensure that certificate revocation lists are checked.

When using a Certificate Authority which is not configured into browsers by default, it is necessary to load the Certificate Authority certificate into the browser, so that it may validate server certificates signed by that Certificate Authority. Doing so may be dangerous since once loaded the browser will accept all certificates signed by that Certificate Authority. A certificate chain allows one to provide a certificate along with the certificates of the issuers so that that the certificate may be validated even if the CA certificates of the intermediate CAs have not been installed in the browser (or server).

4. SSL

The Secure Sockets Layer protocol (SSL) is a protocol layer which may be placed between a reliable connection-oriented network layer protocol (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). It provides for secure communication between client and server by allowing mutual authentication, the use of digital signatures on messages for integrity, and encryption for privacy.

The protocol is designed to support a range of choices for specific algorithms used for cryptography, digests, and signatures. This allows algorithm selection for specific servers to be made based on legal, export or other concerns, and also allows the protocol to take advantage of new algorithms. Choices are negotiated between client and server at the start of establishing a protocol session.

There are a number of versions of the SSL protocol.

The Internet Engineering Task Force (IETF) is working on the Transaction Layer Security (TLS) protocol standard.

Protocol Overview

Once an SSL session has been established it may be reused, which avoids the performance penalty of many of the steps of establishing a session.

Session Establishment

The SSL session is established by following a handshake sequence between client and server. This sequence may vary, depending on whether the server is configured to provide a server certificate or request a client certificate. There are also cases where additional handshake steps are required for management of cipher information. This document summarizes one common scenario, leaving other possibilities to the SSL specification.

The handshake sequence is used by the client and server to:

1. Negotiate the Cipher Suite to be used during data transfer.
2. Establish and share a session key between client and server.
3. Optionally authenticate the server to the client.
4. Optionally authenticate the client to the server.

Figure 3: Simplified Handshake Sequence

The Cipher Suite negotiation step allows the client and server to choose a Cipher Suite which both of them can support. The SSL 3.0 protocol specification defines 31 Cipher Suites. A Cipher Suite consists of:

1. Key Exchange Method
2. Cipher for Data Transfer
3. Message Digest for creating the Message Authentication Code (MAC)

The key exchange method defines how the shared secret symmetric cryptography key used for application data transfer will be agreed upon by client and server. SSL 2.0 uses RSA key exchange, and SSL 3.0 supports a choice of key exchange algorithms, including the RSA key exchange when certificates are used, and Diffie-Hellman key exchange for exchanging keys without certificates and without prior communication between client and server [Kaufman].

The choice of key exchange method includes whether or not to use digital signatures with the key exchange, and what kind of signatures to use. Signing with a private key provides assurance against a man-in-the-middle-attack during the exchange of information used in generating the shared key [Schneier, p516].

SSL uses a conventional cryptography algorithm (symmetric cryptography) for encrypting messages in a session. There are 9 choices, including the choice to perform no encryption:

1. No encryption
2. Stream Ciphers
   1. RC4 with 40-bit keys
   2. RC4 with 128-bit keys
3. CBC Block Ciphers
   1. RC2 with 40 bit key
   2. DES40, DES, 3DES_EDE.
   3. Idea
   4. Fortezza

CBC refers to Cipher Block Chaining, which means that a portion of the previously encrypted cipher text is used in the encryption of the current block. DES refers to the Data Encryption Standard [Schneier, ch12], which has a number of variants (including DES40 and 3DES_EDE). Idea is one of the best and cryptographically strongest available algorithms, and RC2 is a proprietary algorithm from RSA [Schneier, ch13].

The choice in digest function determines how a digest is created from a record unit. SSL supports

1. No digest (Null choice)
2. MD5, a 128-bit hash
3. Secure Hash Algorithm (SHA), a 160-bit hash

SHA was designed for use with the Digital Signature Standard (DSS).

The handshake protocol provides for a number of possibilities, but the most common sequence includes the exchange of certificates and the use of Diffie-Hellman key exchange algorithm. If this is not the case, then the handshake sequence will differ as noted in the SSL Specification.

The handshake sequence uses three protocols, the "SSL Handshake Protocol" for performing the Client and Server SSL session establishment, the "SSL Change Cipher Spec protocol" for actually establishing agreement on the Cipher suite for the session, and the "SSL Alert Protocol" for conveying SSL error messages between Client and Server. These protocols are encapsulated in the "SSL Record Protocol", as is application protocol data. An encapsulated protocol is transferred as data by the lower layer protocol which does not examine the data. The encapsulated protocol has no knowledge of the underlying protocol.

The encapsulation of SSL control protocols by the record protocol means that if an active session is renegotiated the control protocols will be transmitted securely. If there were no session before, then the NULL cipher suite is used, which means there is no encryption and messages have no integrity digests until the session has been established.

Figure 4: SSL Protocol Stack

Data Transfer

The SSL Record Protocol is used to transfer application and SSL Control data between the client and server, possibly fragmenting this data into smaller units, or combining multiple higher level protocol data messages into single units. It may compress, attach digest signatures, and encrypt these units before transmitting them using the underlying reliable transport protocol.

Figure 5: SSL Record Protocol

SSL uses a message digest of the message and a sequence number to create a Message Authentication Code (or MAC), which is encrypted with the message to avoid replay attacks. The record protocol units, compressed units, and encrypted units all contain an identification of the original protocol, and a byte length, as well as data.

Use of SSL

One common use of SSL is for securing web HTTP communication between a browser client and a web server. This case does not preclude the use of non-secured HTTP. The secure version uses URLs that begin with "https" instead of "http", and a different server port (by default 443). The browser will maintain client certificate private keys when they are generated, and display an indicator if a secure connection is being used.

5. Implementing SSL

Although one might write an SSL implementation from scratch following the specification, it is much easier to use one of the existing SSL toolkit libraries. In addition, because of patents, it is usually necessary to license some of the cryptography libraries, at least in the United States. SSL toolkits include encryption, message digest, and certificate management routines. Each also requires the use of a licensed public key package in the United States, since Public Key Partners holds public key patents.

There are two prominent RSA public key packages available:

• RSARef

  The RSA Reference implementation, an unsupported source code toolkit from RSA, may be used for freeware and non-commercial applications. Consensus Development Corp. used to market a license for commercial use but will no longer do so. (Consensus maintains the SSL_FAQ)

• BSAFE3.0

  Commercial implementation of RSARef.

These public key implementations include a complete toolkit of public key algorithms (including RSA encryption and Diffie-Hellman key exchange), symmetric encryption algorithms, and digest functions. They may be used with SSL Toolkits. The most prominent SSL Toolkits include:

• SSLRef

  Sample SSL 3.0 implementation from Netscape Communications Corp.

• SSLPlus

  Commercial source code toolkit available from Consensus Development Corp., an enhancement of SSLRef 3.0. It requires BSAFE 3.0 (from RSA) for use.

• SSLava

  SSL 3.0 compliant toolkit written in Java from Phaos Technology.

• OpenSSL

  OpenSSL-0.9.4 (OpenSSL-0.9.4.tar.gz) is a free non-commercial implementation of SSL 2.0 and SSL 3.0 and TLS 2.0 . It includes a public key implementation which may be used outside the United States. In the United States, RSARef or BSAFE3.0 must be used due to patent requirements. SSLeay offers an inexpensive way to get started with SSL. [OpenSSL FAQ]

Further Reading

[1] Our investigations make use of the fact that patent issues may be avoided in non-commercial experimentation, and export issues may be avoided by using weaker cryptography. The SSL 3.0 specification provides some information on U.S. export regulations. We do not address patent or export regulations here, other than to say you should be aware of them, observe them, and consult an attorney. There are a number of surveys of the issues available [Koops].