Secure Sockets Layer (SSL)

Introduction

HTTPS is HTTP running over Secure Sockets Layer (SSL) which was developed by Netscape. SSL (now up to version 3.0) is a tunnelling protocol that allows a proxy server to act as a tunnel between the client and the server. SSL runs at the application layer and provides secure transaction of data such as credit card details, between a client and an E-commerce server. SSL uses certificates, private/public key exchange pairs and Diffie-Hellman key agreements to provide privacy (key exchange), authentication and integrity with Message Authentication Code (MAC). This information is know as a Cypher Suite and exists within a Public Key Infrastructure (PKI).

Three Elements of SSL

Confidentiality

Data can only be viewed by the intended user. This is achieved by way of encrypting the data using keys. That is, each of the parties has knowledge of a key to be used. The keys can be known by one of two methods:

Key Exchange - One party generates a symmetric key and then encrypts and transmits it using an asymmetric encryption scheme where each device has a private key and a public key that can be shared to all devices. Data encrypted using the public key can be decrypted using the private key and the reverse is true. A well known asymmetric key encryption scheme is Rivest, Shamir and Adelman (RSA). The private key is never shared and always remains secure.
Key Agreement - both parties generate a shared symmetric key usually using the Diffie-Hellman algorithm in conjunction with DES (40-bit key) or 3-DES (128-bit key). Parameters used to generate the shared key are exchanged between the client and server.

Authentication and the Certification Authority (CA)

Is the other party really who they say they are? This is confirmed by way of Digital Certificates. A Certification Authority (CA) is a trusted authority that issues digital certificates via a PKI so that the certificates are not compromised. A discussion on CAs can be found within the IPsec tutorial here.

Message Integrity

In order to ensure that a message has not been interfered with between the sender and receipient, a Message Digest (or Hash) is applied to the message and attached to it. The message digest is a fixed length value that cannot be easily reversed. The message digest is encrypted to form the Message Authentication Code (MAC), using the sender's private key, and then it is decrypted at the other end by using the sender's public key. The message digest can either be created using Message Digest 5 (MD5) or Secure Hash Algorithm (SHA).

The public/private keys used to form the MAC (sign it with a digital signature) could be from RSA (used also for key exchange as described earlier). There is a new standard for signing which could be used instead of RSA. This is called the Digital Signature Algorithm (DSA is only used for digital signatures. It is considered a good idea to separate key exchange from signing. DSA is standardised in the Digital Signature Standard (DSS) designated FIPS-186. DSS uses Diffie-Hellman type algorithms and uses SHA-1 for the message digest.

Operation of SSL

The client initiates an HTTP request for an SSL tunnel either via a hook in HTTP or by calling HTTPS directly. The cache can then issue a CONNECT method (see earlier) using https:// url to tunnel SSL over HTTP.

By default, SSL uses a number of ports including 443, 643, 1443 and 2443. For encryption SSL uses RC4-128, Diffie-Hellman 1024, MD5 and Null. The encryption is carried out at layer 4 i.e. the socket layer.

SSL handshaking occurs as follows:

The client sends a 'hello' to the server as a request for a secure connection
The server sends a 'hello' to the client.
The server sends its authentication certificate and public key
The server sends a server_key_exchange
The server sends a certificate request
The server indicates that the server hello is complete.
Upon verification of the server certificate, the client sends its certificate
The client sends a client_key_exchange with a randomly generated key derived from the server key
The client sends a certificate verify message
The client sends a change_cipher_spec
The client indicates that it has finished
The server decodes the client key with its own private key
The server sends a change_cipher_spec
The server indicates that it has finished
The client and server exchange encrypted data

The SSL Record Protocol then takes the application data and splits it into fragments. Each fragment has the following operations carried out on it:

Compressed
Message Authentication Code (MAC) added
Encrypted
SSL Record header added to the front of the fragment

SSL provides the following:

Client-to-server, end-to-end encrypted traffic (including basic authentication usernames/passwords, content of submitted forms, etc)
Strongly authenticated server credentials supplied to the browser (including hostname and name of site operator etc.) - Server-side authentication.
Strongly authenticated user credentials supplied to the server (requires user to have a personal certificate) - Client-side authentication.

The problems associated with SSL are:

It prevents caching.
Using SSL imposes greater overheads on the server and the client.
Some firewalls and/or web proxies may not alow SSL traffic.
There is a financial cost associated with gaining a Certificate for the server/subject device.

Home

Disclaimer