| A brief introduction to SSL is presented here. Greater detail may be found in the various books on security and RFCs. The SSL Protocol SSL was originally developed by Netscape® and has been widely adopted for use on the Internet. The Internet Engineering Task Force created a new standard called Transport Layer Security (TLS) [RFC2246] based on SSL. TLS is used in HTTPS and WTLS. The SSL protocol runs on top of TCP/IP but below higher-level protocols such as HTTP, Lightweight Directory Access Protocol (LDAP) [RFC2451], or Internet Mail Access Protocol (IMAP). SSL uses TCP/IP on behalf of the higher-level protocols. Some side effects of being between the high and low protocols are that SSL: allows an SSL-enabled server to authenticate itself to a SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection. Some terms need to be clarified before more is discussed about the SSL protocol: SSL Server Authentication Server authentication means a client can confirm a server's identity. SSL-enabled client software can use standard public-key cryptographic methods 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 is useful in cases where financial information or company secrets are to be stored on a server. In such a case, it is critical that an unauthorized machine cannot act as legitimate server and thereby learn sensitive information. SSL Client Authentication Client authentication means a server can confirm a Client's identity. Client authentication uses the same techniques as server authentication. SSL-enabled server software can use the standard public-key cryptographic methods to verify the user's certificates. This sort of confirmation is useful when sending or receiving sensitive data from a user, such as a bank accepting an electronic payment from a user. SSL encrypted connection An SSL encrypted connection requires all information sent between a client and a server to be encrypted. This encryption provides a high level of confidentiality important to any private transaction. In addition to confidentiality, an SSL encrypted connection provides a mechanism to detect tampering whether the data has been altered in transit. SSL Cipher Suites SSL supports a wide variety of standard cipher suites. Note that SSL 2.0 and SSL 3.0 protocols support overlapping sets of ciphers. Here is a list of the more common suites with their owners listed in parenthesis: DES Data Encryption Standard (US Government) DSA Digital Signature Standard (US Government) KEA Key Exchange Algorithm (US Government) MD5 Message Digest Algorithm (Rivest) RC2 and RC4 Rivest encryption Ciphers (RSA Data Security) RSA public key algorithm (Rivest, Shamir, and Adleman) RSA key exchange key exchange algorithm based on RSA SHA-1 Secure Hash Algorithm (US Government) Skipjack classified symmetric-key algorithm implemented in FORTEZZA-compliant hardware (US Government) Triple-DES DES applied three times (US Government)
During initial negotiations, SSL products will select the strongest appropriate cipher for the connection. Decisions about which cipher to use depend on the sensitivity of the data, the speed of the cipher, and the various export laws. The SSL Handshake The first part of an SSL session is the exchange of messages, called the SSL Handshake. This handshake allows the server to authenticate itself to the client (using public key techniques), and the server and client to create the symmetric keys used in the normal course of the session. Note that SSL uses both public-key and symmetric-key techniques. The public key is used for the authentication but not for normal session operations, due to the long execution time of public-key methods. Here is a rough outline of the steps taken during the handshake: Client sends to the server its SSL version, cipher settings, some random data, and any other information the server may need. Server sends to the client its SSL version, cipher settings, some random data, its certificate, and any other information the client may need. If the server needs to authenticate the client, it will request the client's certificate at this time. Client authenticates the server using the information sent in step 2. If the server cannot be authenticated, the session ends. Client creates a Premaster Secret (depends on the cipher being used) using the random data from steps 1 and 2, and encrypts it with the server's public key. Client sends to server the encrypted Premaster Secret and, if requested, the client certificate. If the server receives the client certificate in step 5, it will authenticate the client. If the client cannot be authenticated, the session ends. Both the client and server generate the Master Secret (at the same time), based on the Premaster Secret. The Master Secret is used to generate the session keys the symmetric keys used to encrypt and decrypt the session information (and encrypt/decrypt the payload data). The session keys can also be used to verify the data integrity. Client sends to the server a message indicating future messages will be encrypted with the session key, and a separate encrypted message indicating the client side is done. Server sends to the client a message indicating future messages will be encrypted with the session key, and a separate encrypted message indicating the server side is done.
More Information on SSL and Certificates More in-depth information on SSL can be found in some of the IETF's documents, as well as from the major Internet players, such as Sun, Cisco, Netscape, and even the United States Government. For more details on how HTTP works with SSL and TLS, refer to the IETF Web site (www.ietf.org). The following RFCs provide detailed information on HTTP, HTTPS, SSL (used in HTTPS), and TLS: RFC 2616 (Hypertext Transfer Protocol HTTP 1.1) [RFC2616] RFC 2817 (Upgrading to TSL within HTTP 1.1) [RFC2817] RFC 2818 (HTTP over TLS) [RFC2818]
Information on Server Authentication and Certificates may be found in the various X.509 RFCs: RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL profile) [RFC2459] RFC 2510 (Internet X.509 Public Key Infrastructure Certificate Management Protocols) [RFC2510] RFC 2511 (Internet X.509 Certificate Request Message Format) [RFC2511]
|
