4.4 Secure sockets layer

4.4 Secure sockets layer

In Chapter 3, we introduced you to the term SSL. SSL (Secure Sockets Layer) is a protocol designed by Netscape Communications. SSL provides for the encryption of a session or authentication of a server. It is a network protocol layer, located directly under the application layer with responsibility for the management of a secure, encrypted, communication channel between a server and client. SSL is implemented in major web browsers such as Netscape and Internet Explorer. The address keyword https:// is used to designate a secure, or SSL enabled, connection.

One of the most basic functions of SSL is message privacy. SSL can encrypt a session between a client and a server so that applications can exchange and authenticate user names and passwords without exposing them to eavesdroppers. Hackers can use IP sniffers and scanners to capture copies of all packets that pass between a client and server during a session. This information is then available in an unencrypted, cleartext format. One example could be a basic authentication between a browser and a server. The browser attempts to access a page that requires authentication, a user name, and a password. The server will return a status code back to the browser (for example, 401). This status code tells the browser to generate a prompt for the user name and password. The user then enters the user name and password, and this data is sent back to the server. In this example of basic HTTP authentication, the password is passed over the network, not encrypted, but not as plaintext either; it is "unencoded." Anyone watching packet traffic on the network will not see the password in the clear, but the password will be easily decoded by anyone who happens to catch the right network packet, and this is very easy to do. With SSL, however, all transmissions following the initial handshake are encrypted to prevent transmissions from being captured. The client and server prove their identities by exchanging certificates. All traffic between the SSL server and the SSL client is encrypted using a key and an encryption algorithm negotiated during the SSL handshake, which occurs at session initialization. Next, the SSL protocol ensures that messages between the sender system and receiving system have not been tampered with during the transmission. This ensures a secure channel between the client and server. SSL uses a combination of mathematical functions known as hash functions. (Hashing was discussed in Chapter 3.) Also, a shared secret is used to encrypt the data with a strong cipher. If, during a session, a packet is damaged or indecipherable, we must assume that tampering has occurred. An ongoing process of verifying and checking the packets will preserve the integrity of the messages. In SSL v3.0, initiation of the handshake can even be carried out by the client or in the middle of an open session, thus allowing the systems to change the algorithms and keys used whenever they want. Included in this process is server authentication (with X.509v3, clients can also be authenticated). This is the process of determining the server identity via the exchange of X.509 certificates. A server's identity is coded into a public-key certificate that is exchanged during the SSL handshake.

SSL was designed to make its security and services transparent to the end user. Normally a user would follow a URL (see RFC 1738) to a page that connects to an SSL-enabled server. The SSL-enabled server would accept connect requests on 443 (default). The default port for non-SSL access is port 80. When it connects to port 443, the handshake process will establish the SSL session. Now, all traffic between the server and client will be encrypted. The handshake is composed of three basic steps:

1. The client and server (or server and server) exchange X.509 certificates to prove their identity. As part of the process, the certificates are checked against expiration dates and for evidence of tampering.

2. Next, the client generates a set of keys to be used for encrypting the data. The client encrypts a cipher key with the public key that it received from the server. The client then sends the encrypted key to the server. The server now decrypts that key with its private key.

3. Finally, the client and server select the hash function and the message encryption cipher algorithm. The server will ask the browser to provide a list of all possible ciphers that it holds. The server then selects a cipher to encrypt the data, using the strongest allowable cipher that it holds in common with the client.

Figures 4.4 and 4.5 show examples of the ciphers that can be used with other servers, in these cases SSL v2 and SSL v3.

Figure 4.4

Figure 4.5