Introduction to SSL
This document introduces the Secure Sockets Layer (SSL) protocol. Originally developed by Netscape, SSL has been universally accepted on the World Wide Web for authenticated and encrypted communication between clients and servers.
The new Internet Engineering Task Force (IETF) standard called Transport Layer Security (TLS) is based on SSL. This was recently published as an IETF Internet-Draft, The TLS Protocol Version 1.0. Netscape products will fully support TLS.
This document is primarily intends for administrators of Netscape server products, but the information it contains may also be useful for developers of applications that support SSL. The document assumes that you are familiar with the basic concepts of public-key cryptography, as summarized in the companion document Introduction to Public-Key Cryptography.
The SSL Protocol
The Transmission Control Protocol/Internet Protocol (TCP/IP) governs the transport and routing of data over the Internet. Other protocols, such as the HyperText Transport Protocol (HTTP), Lightweight Directory Access Protocol (LDAP), or Internet Messaging Access Protocol (IMAP), run “on top of” TCP/IP in the sense that they all use TCP/IP to support typical application tasks such as displaying web pages or running email servers.
Figure 1 SSL runs above TCP/IP and below high-level application protocols
and in the process allows an SSL-enabled server to authenticate itself to an SSL-enabled client,
allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection.
These capabilities address fundamental concerns about communication over the Internet and other TCP/IP networks:
- SSL server authentication allows a user to confirm a server’s identity. SSL-enabled client software can use standard techniques of public-key cryptography to check that a server’s certificate and public ID are valid and have been issued by a certificate authority (CA) listed in the client’s list of trusted CAs. This confirmation might be important if the user, for example, is sending a credit card number over the network and wants to check the receiving server’s identity.
- SSL client authentication allows a server to confirm a user’s identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check that a client’s certificate and public ID are valid and have been issued by a certificate authority (CA) listed in the server’s list of trusted CAs. This confirmation might be important if the server, for example, is a bank sending confidential financial information to a customer and wants to check the recipient’s identity.
- An encrypted SSL connection requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thus providing a high degree of confidentiality. Confidentiality is important for both parties to any private transaction. In addition,
- all data sent over an encrypted SSL connection is protects with a mechanism for detecting tampering-
- -that is, for automatically determining whether the data has been altered in transit.
The SSL protocol includes two sub-protocols:
the SSL record protocol and the SSL handshake protocol.
It record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection. This exchange of messages is design to facilitate the following actions:
- Authenticate the server to the client.
- Allow the client and server to select the cryptographic algorithms, or ciphers, that they both support.
- Optionally authenticate the client to the server.
- Use public-key encryption techniques to generate shared secrets.
- Establish an encrypted SSL connection.