Wednesday, 4 January 2017

Secure Socket Layer (SSL) Introduction

Although its modern name is actually Transport Layer Security (TLS), it is more commonly known as Secure Socket Layer (SSL).

SSL is a cryptographic protocol that is widely used to secure communications on the Internet. It has 2 functions:
  1. Identification: making sure the computer you are talking to is the one you trust.
  2. Encryption: preventing eavesdropping of the information sent from one computer to another.

Identification

In today's Internet era, identification is crucial.

Why?

The nature of the Internet means that your information hops through several computers before it reaches the intended destination. Any of these computers could pretend to be your destination and trick you into sending them sensitive information.

The solution is to use a proper Public Key Infrastructure (PKI), which means that the destination computer has a SSL Certificate from a trusted SSL Certificate Authority (CA).

The SSL Certificate authenticates the identity of the destination computer. This is a prerequisite before encryption of information can take place.

Encryption

SSL provides data encryption.  Many network protocols were designed in the early days of Internet where there was no data encryption. Nowadays, data encryption is crucial and SSL is used to secure these protocols (e.g. HTTP -> HTTPS, SMTP -> SMTPS). 

If you see an URL starting with http, you know that your data is sent unencrypted. But if you see that it starts with https, you know that your data is encrypted using SSL.

There are 2 types of encryption: 

  1. Symmetric: when you and the destination computer use a common secret key for encryption/decryption.
  2. Asymmetric: when the key used to decrypt is different from the key used to encrypt. This is used in situations when there is no common secret key, e.g. Internet transaction with Amazon.
Asymmetric encryption is used by PKI because it allows complete strangers to start a secret communications channel. But since it is computationally slower than symmetric encryption, a switch to symmetric encryption will take place as soon as the communications channel is secured. In SSL, this happens after the SSL handshake, which we will discuss next.  

SSL Handshake

When an URL starts with https, your browser will ask the URL's server for its SSL certificate through a "Client Hello"(CH) message. This is the start of the SSL handshake. 

In the CH message, your browser provides a list of cryptographic algorithms that it supports. 

For example, 


The server will choose 1 algorithm inside each of the 3 categories and inform the client through a "Server Hello" (SH) message. This is the Key Method Exchange phase, where the objective is to agree on a set of cryptographic algorithms to use for this secured communication channel/session. 

Let's assume the server chooses the RSA-AES256-SHA512 combination. 

In addition, the SH message contains the server's SSL certificate, which allow contains the server's public key. Your browser then uses the SSL certificate to verify the server's identify. 

Once the server's identity is ascertained, your browser will use the server's public key to encrypt a common secret (called the "pre-master secret") and send it to the server. The server uses its private key to decrypt and obtain the "pre-master secret". This message is called the "Client Key Exchange" (CKE). (The "pre-master secret" is actually a random value generated by your browser and is used to derive symmetric encryption keys that will be faster than the asymmetric encryption that is presently used).  

Following the CKE message, your browser sends out a message called a “Change Cipher Spec” (CCS). The CCS informs the server that it is entering the phase of "Symmetric Cryptography". The server will prepare for this by using the "pre-master secret" to generate the "master secret", which both sides know. The "master secret"is used to compute the keys for encryption and hashing.

Your browser goes through the same process of computing the keys for encryption and hashing. Once the keys are ready, it sends the "Finished message" (FM), whose integrity is protected by using the newly computed hash key. This is a clever message that proves that no one tampered with the handshake and it proves that we know the key. The FM is the last message your browser sends in the SSL Handshake.


Side note: There is also a option for the server to ask the client for its SSL certificate if it so desires. This option is found inside the SH message.

Reference: 

The First Few Milliseconds of an HTTPS Connection
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

No comments:

Post a Comment