SSL stands for Secure Sockets Layer, a protocol developed by Netscape in 1994.
It provides a secure way of communication between computer systems by scrambling
This is also known as Secret Key Cryptography. Both communicating parties uses
same key in decrypting and encrypting data. The cryptographic algorithm to use
in encrypting and decrypting data must be agreed by both ends. Example of
Cipher 2 (RC2), and Rivest Cipher 4 (RC4). Decryption/encryption of data is
This is also known as Public Key Cryptography. This make use of a private and
public key to encrypt/decrypt data. Private key must never be shared to others
while public key can be shared. If a data is encrypted using the private key,
the data can be decrypted using its corresponding public key (and vice-versa).
Some well known public key algorithms are Rivest Shamir Adleman (RSA) and
Diffie-Hellman (DH) algorithm. Using this kind of cryptography requires more
processing power which makes it slow. This is the reason why we only use this
in ecnrypting small pieces of data like the symmetric key.
In the next sections, we will see how these 2 takes place in SSL handshake.
But first, here are some few items that are worth reading.
| Terminology | Definition |
|---------------|---------------------------------------------------------------|
| cipher suite | A set if cryptographic algorithms and key sizes used that a |
| | computer can use to encrypt data. A cipher suite typically |
| | consists of respective algorithms used for key exchange, |
| | authentication, bulk encyrption, and Message Authentication |
| | Code (MAC). For in depth discussion on cipher suites, I will |
| | provide another post right after this. |
|---------------|---------------------------------------------------------------|
| cryptographic | These are math functions that aims to scramble data to hide |
| algorithm | its contents. 2 major types are Symmetric (uses 1 key) and |
| | Asymmetric (uses public and private keys) and different kinds |
| | exists under those categories. E.g Symmetric has RC and DES |
| | while Asymmetric can be RSA or DH. |
|---------------|---------------------------------------------------------------|
| ciphertext | This is another name for encrypted data. The opposite is |
| | the unencrypted data or cleartext. |
|---------------|---------------------------------------------------------------|
The fun part: SSL Protocol in depth
Here is a more detailed explanation on what is happening in the background.
| CLIENT | | SERVER |
|-------------------------------|-----|--------------------------------|
| Client Hello | --> | |
|-------------------------------|-----|--------------------------------|
| | <-- | Server Hello |
|-------------------------------|-----|--------------------------------|
| | <-- | Certificate |
|-------------------------------|-----|--------------------------------|
| | <-- | Server Key Exchange (optional) |
|-------------------------------|-----|--------------------------------|
| | <-- | Server Hello Done |
|-------------------------------|-----|--------------------------------|
| Client Certificate (optional) | --> | |
|-------------------------------|-----|--------------------------------|
| Client Key Exchange | --> | |
|-------------------------------|-----|--------------------------------|
| Change Cipher Spec | --> | |
|-------------------------------|-----|--------------------------------|
| Finished | --> | |
|-------------------------------|-----|--------------------------------|
| | <-- | Change Cipher Spec |
|-------------------------------|-----|--------------------------------|
| | <-- | Finished |
|-------------------------------|-----|--------------------------------|
| encrypted data | <-> | encrypted data |
|-------------------------------|-----|--------------------------------|
Let's focus on the required steps below leaving off the optional ones with some
few details.
Client Hello
Client (in this case a browser like google chrome) initiates the connection by
going to a secure site (URL starting in https://). At this moment, SSL is
triggered automatically. Client sends the server (system on where the site is
hosted) 4 important information - cipher suite it can use for both symmetric
and asymmetric key encryptions, the SSL version it wish to use, session ID,
and compression method.
Protocol Version - Version of SSL the client wants to use
Session ID - Session identifier the client wants to use. The 1st
client hello is always empty for every new sessions.
Cipher Suite - Contains list of cryptographic algorithms supported by
the client (in order of preference). The server selects
from these choices. If nothing is selected, server will
return a handshake failure.
Compression Method - List of compression algorithms supported by the client.
If server doesn't support any method listed, connection
will fail.
Here is an actual packet capture of Client Hello message from wireshark.
Server Hello
The server now responds back to the client with the following information
below.
Protocol Version - Vesion of SSL that is supported by the server and the
client. Server will choose the lowest version that match
e.g client supports 2.0 while server supports up to 3.0,
server will choose 2.0.
Session ID - This is the session identifier. If the session ID sent by
the client is not empty, server will look for it in its
cache then will try to reuse it. That means that the
client wishes to reuse an existing session instead of
opening a new one. Otherwise, this will contain another
value which will identify this new session.
Cipher Suite - This is the chosen cipher suite from the list provided by
the client.
Compression Method - Similar to the previous which is chosen from the list
provided by the client.
Certificate
If the server has a certificate, which is the usual scenario, it will send the
client a list of certificates it has. The certificate must be appropriate for
the selected cipher suite.
Server Key Exchange (optional)
This is only sent if the server has NO certificate which is unusual for an
HTTPS connection.
Server Hello Done
This is pretty much a blank message indicating that the server is done sending
the required information.
Client Certificate (optional)
This is the 1st message sent by the client after it receives the Server Hello
Done. However; this is only sent when the server requests a certificate from
a client which is uncommon on web communications. Some cases where this is
used is when an organization establishes a secure communication to another one
which requires authentication.
Client Key Exchange
This depends on the public key algorithm agreed, which is found inside the
cipher suite, between both parties. If Diffie-Hellman is agreed, the packet
will look like this:
Otherwise, if RSA was chosen, client will generate a PreMaster secret, encrypt
it using the server's public key, and send to the server. The server will
decrypt it using its private key. Both parties now have the PreMaster and will
generate a master key off that. For the purpose of this post, let's say RSA
was chosen as the public key cryptography. The corresponding packet capture
for RSA is:
Change Cipher Spec (client/server)
This message signals the transition from Public (Asymmetric) key to Secret
(Symmetric) Key cryptography. But why are we doing this? We know that
Assymetric is resource intensive compared to Symmetric based from the initial
discussions above. So in order not to degrade performance, we will use
Symmetric Key Cryptography throughout the data exchange. What happens here is
that the client copies the new Cipher Spec (pending) to the current Cipher
Spec (the one to be replaced). This message is encrypted by the current Cipher
Spec. When both parties receives each others Cipher Spec, they will copy the
read pending state into the read current state.
Finished (client/server)
This is sent right after the Client Key Exchange and is the first protected
message by the most recent Cipher Spec chosen. There's no acknowledgement
needed on both parties after they received this message and secure data
exchange can now start.
