2.0 How SSL works


2.1 - Transmitting Data Privately

SSL uses encryption and decryption to ensure that data is transmitted privately. It works on the public-and-private key encryption system from RSA. The web server contains a private and public key "signed" by a Certificate Authority. The public key is used to encrypt data, but it can only be decrypted using the private key. SSL uses two types of encryption: public key and symmetric key.

Public (Asymmetric) key encryption

Public key encryption uses a key pair made up of a public and a private key. The keys are mathematically linked; that is, data encrypted with one key in the pair can only be decrypted using the other key in the pair. The public key can be distributed and made generally available. The private key is kept private.

A web server and web browser use public key encryption when first establishing communications with each other. Specifically, it is used during the SSL handshake when the web browser authenticates the web server. After the handshake is complete, the web server and web browser switch to the more efficient symmetric key encryption for the remainder of the transaction.

Symmetric key encryption

Symmetric key encryption uses a single key. The web browser and the web server create the key (called a session key) during their initial interaction (the SSL handshake). The same key is used to both encrypt and decrypt the data. This encryption ensures that no one else can read the data being transmitted in either direction. A different session key is used for each server/browser connection, and the session key automatically expires after twenty-four hours.


2.2 - Ensuring the Data Is Not Altered During Transit

SSL uses cryptographic hashing to ensure that no one alters data during transit. Cryptographic hashing creates a unique hash value based on the content of transmitted data. The content of the data cannot be determined from the hash value and it is nearly impossible to compose another message that computes to the same hash value. Both the web server and the web browser compute hash values using the same hashing algorithm. If the hash values are the same, the data was not altered.

When sending data to a web browser, the web server computes a hash value for data then sends the hash value and the data to the web browser. When the web browser receives this information, it computes its own hash value for the data then compares the two hash values. If they match, the web browser is assured that the data was not altered during transit. A similar process occurs when the web browser sends data back to the web server. The web browser computes a hash value then sends it and the data to the web server. The web server computes a hash value for the data and compares it to the hash value computed by the web browser.

This process assures web browser users that information they receive from the web server has not been altered and that information they fill in on an HTML form is not altered before it reaches the web server.


2.3 - Authenticating the Web Server

SSL uses digitally signed certificates to authenticate the web server, that is, to assure the web browser that it is communicating with the organisation it thinks it is.

A certificate is a data structure that contains information about the organisation. It also contains the public key of the organisation’s public/private key pair. Because the certificate contains the public key, it binds a public/private key pair to the organisation. The key pair is used for public key encryption during the SSL handshake.

A server certificate is a certificate that attests to the identity of an organisation that owns a web server. Certificates are issued by certificate authorities such as VeriSign. A certificate authority is a trusted company or organisation that confirms that an organisation is what it claims to be.

To obtain a server certificate, an organisation must send a certificate signing request (CSR) to the certificate authority. After conducting research to ensure the organisation is what it claims to be, the certificate authority digitally signs the certificate and sends it to the organisation that requested it.

To create the digital signature, the certificate authority computes a hash value based on the contents of the certificate.

A hash value is an error-checking value derived from the addition of a set of numbers taken from data (not necessarily numeric data) that is to be processed or manipulated in some way. After processing, the hash total is recalculated and compared with the original total. If the two do not match, the original data has been changed in some way.

The certificate authority then encrypts the hash value with its private key. The digital signature is the encrypted hash value. The digital signature is stored with the certificate.

When the organisation that requested the certificate receives the certificate, it loads it to its web server. When an SSL request is made, the web server sends the certificate to the web browser. When the web browser receives the certificate, it can read the information about the organisation and its public key.

To validate the certificate to ensure it contains the information digitally signed by the certificate authority, the web browser verifies the digital signature. Because the digital signature is an encrypted hash value that was computed based on the contents of the certificate, the web browser needs to compare hash values. The web browser computes a hash value based on the contents of the certificate it received. It then decrypts the digital signature to determine the hash value that the certificate authority computed. If the two hash values match, the web browser is assured that the certificate contains the information that the certificate authority verified and digitally signed.


2.4 - The SSL Record Protocol

An SSL record consists of two parts, the header and the data. The header can either be 3 bytes in length or 2 bytes in length, the latter being employed if there is no padding data. The escape bit is not used in version 2 of the protocol but it is suggested that it is used to designate Out-Of-Band data in future versions. For a 2 byte header, the maximum record length is 32767 bytes whereas a 3 byte header will only allow a record length of up to 16383 bytes.

The data part of the record consists of a Message Authentication Code (MAC), the actual data itself and padding data, if required. It is the data part of the record which is encrypted in its entirety when encryption is necessary. Padding data is only required for use with block ciphers. It is used to pad out the length of the data block to be a multiple of the block size of the cipher. If a stream cipher is used or the data is already a multiple of the block size, then no padding is required and a 2 byte header record can be used. The MAC is a hash or message digest of the secret write key of the sending party, the actual data, the padding data and a sequence number in that order. The sequence number is a 32 bit integer which is incremented after each message is sent.


2.5 - SSL Handshake

The SSL handshake occurs when a web browser user first requests information from a web server that is using SSL.

The following is accomplished during the SSL handshake:

The handshake protocol is composed of two phases.

Phase 1 deals with the selection of a cipher suite, the exchange of a master key and the authentication of the server.

A cipher suite is made up of three techniques:


Phase 2 handles client authentication, if requested and finishes the handshaking. After the handshake stage is complete, the data transfer between client and server begins. All messages during handshaking and after, are sent over the SSL Record Protocol layer.

To allow the web browser to authenticate the web server, the web server sends its server certificate to the web browser. The web browser validates the server certificate.

The web browser selects an appropriate symmetric key for the type of symmetric encryption to be used. It then encrypts the symmetric key using the web server's public key. (The web browser obtained the web server's public key from the server certificate.) The web browser then sends the encrypted key to the web server.

Using its private key, the web server decrypts the symmetric key. Now both the web browser and the web server have a secret key that they will use to send data back and forth. The handshake is complete.


2.6 - SSL and The ISO Reference Model

It is important that any new communications protocol conform to a standard model if it is to easily replace or become part of an existing protocol structure. The ISO Reference Model for Open Systems Interconnection or 7-Layer Model is the most popular abstraction [HAL93].



Figure 2.1




2.7 - Example of an SSL Transaction:

The web browser user enters a URL to access information from a web server that is using SSL, for example:

1. https://www.company.com:443/ 

2.  The web browser and web server perform the SSL handshake, which consists of the following steps:

3. The web server sends the requested data to the web browser by performing these steps:

4. The web browser receives the data and hash value. Then it:

5. The web browser user fills in information on an HTML form and uses the submit button to return the information to the web server.  

6. The web browser sends the HTML form data to the web server by performing these steps:

7. The web server receives the data and hash value. Then it:

The process continues with steps 3-7 until the SSL transaction ends.