How does SSL work? Step 3 - Completing The SSL Handshake

Quick SSL Fact:

There are a number of different encryption methods that can be employed to assure the data is not readable by anyone interecepting the communication. These "Cyphers" include:

DES - Digital Encryption Standard

DSA - Digital Signature Algorithm

KEA - Key Exchange Algorithm

MD5 - Message Digest algorithm

RC2 - Rivest encryption cipher

RC4 - Rivest encryption cipher

SHA-1 - Secure Hash Algorithm

Triple DES - DES used 3 times

Others

RC2 and RC4 support 128bit encryption. 128 bit encryption allows for 3.4 * 10³⁸ (34 with 37 zeros to the left of the decimal place) possible keys. These are extremely hard to crack while 40bit encryption allows for 1.1 * 10¹² possible keys.

SSL Performance Issues:

Bandwidth considerations are not an issue for most small or medium sized businesses. SSL transactions can however increase by about 1k bytes each which would typically only be a concern when large numbers of transactions are ocurring.

Processor Usage is increased with SSL connections but again, this should only be a concern on servers running numerous transactions per minute. Processor usage can also be minimized by using the most processor effeicient encryption methods (RC4 and MD5 are much less processor intensive than DES or Triple DES).

Use our interactive checklist to determine what you need. OurShop Now will step you through the complete process. Use our recommendations or enter your own service providers.

How does ssl work?
Detailed SSL - Step 3 Completing The SSL Hand Shake
( updated 2006-02-16 )

The handshake finally creates the new key that the remainder of the connection will be using. The end product is then a transmission encrypted based on a calculated key that is based on a combination of verified certificates.

The browser now creates a "premaster secret" that will be used to encrypt the rest of the session. This is a random key that it encrypts using the agreed upon encryption method (see left side panel) combined with the server's public key string that it recieved and sends the new encrypted secret string back to the server

If the server requires client authentication, it is done at this point using the same steps as those on the preceding page but looking for a certificate on the client side rather than on the server side. Typically this is done in corporate environments.

With the new "premaster secret" string, both the browser and the web site server create a new "master secret" string and use it to create session keys (long strings of generated characters) that their encryption programs use for the rest of the session to scramble and descramble (or encrypt/decrypt) all transmissions for the rest of the session. With the Master Secret key in place, both sides are also able to verify that the data didn't change in route.

The browser now has the information it needs to establish secure communication and it sends a message to the server saying that it will start using the new session key.

The browser (now talking in the encrypted format) verifies to the web server that it is finished locking / securing it's part of the session.

The web server then sends a message to the browser saying that it too will start using the new session key.

The web server (now talking in the encrypted format) verifies to the browser that it is finished locking / securing it's part of the session.

The remainder of the SSL session gets processed between the browser and the web server using the agreed upon encryption with the master secret phrase as the key.

Back - To SSL Overview >

SSL Certificate Provider Recommendations >

Straightforward Explanation of SSL and HTTPS.

Not finding the secure certificate answer you need?