Do I need ssl on my website? Do I need to share my house keys with trusted members only? Do I need to secure my luggage in public transport, Dude!! Do I need to wear a parachute before I skydive?
As far as the first three questions are concerned, the answer is a big ‘YES’! The same answer goes with the fourth one unless you’re like Tom Cruise or Bada$$ Guy.
Okay so let’s not go deep in fourth. Just focus on SSL!!!
SSL means Secure Socket Layer. However that protocol has been deprecated and replaced by Transport Layer Security (TLS). Because so many got used to using the SSL acronym we still use it, the two are interchangeable today, but the actual encryption is TLS, not SSL today.
Http (Hyper Text Transfer Protocol) uses TCP (Transmission Control Protocol) for communication between client and server on the internet. It generally uses port 80 to send and receive data packets on the web. where data packets are nothing but chunks of plain text.
Https makes use of http along with tls encryption to send and receive data packets on port 443 via the internet.
Here are few points which gives us enough justification on why we do need install ssl on our websites
- There have been cases in which people have lost their money on fake websites, one of the important functions performed by an SSL certificate is to provide identity authentication to a website. Such verification makes sure that no other party creates a fake website pretending to be yours. In technical terms, this is called Phishing. Thus, SSL helps users drive to your real website, saves users from frauds and enhances your reputation.
- Encryption used in ssl helps us in protecting sensitive data such as IDs, passwords, credit card numbers etc.
- When an ssl certificate is installed on your webserver, all famous browsers like google chrome, safari , mozilla firefox shows padlock in front of the url which gives attractive indications of secured web connections to the end user, Hence increases trust relationship with them.
- Https enabled websites have higher priority in rankings when they are searched through google search engine. Who doesn’t want to be on Google’s first page, right?
- For accepting payments online, your website must be PCI compliant. Having ssl certificate on your website is one of the prerequisite declared by the payment card industry (PCI)
How come ssl is able to manage all that ?
Before we dive deep into ssl handshake we must be aware of 2 types of encryption which are used in conjunction when handshake take place.
Symmetric Encryption : In this, a single identical key is used to encrypt and decrypt the data between remote and client server. Along with authenticating the remote server with the client, this encryption is also used in the entire ssl connection to transfer the data in encrypted format.
Asymmetric Encryption : This encryption makes use of two keys. One referred to as a public key used for encryption and the other as the private key which is used for decryption.
Step 1. Request secure site
A client sends a ClientHello message to the server. The hello message contains the following information
- the highest TLS protocol version it supports,
- a random number,
- list of supported cipher suites (group of cryptographic algorithms)
- List of supported compression methods (used for compressing data to reduce bytes).
- If the client is attempting to perform a resumed handshake, it may send a session ID. If the client can use Application-Layer Protocol Negotiation, it may include a list of supported application protocols,such as HTTP/2.
Step 2. Secure web server sends certificate
The server responds with a ServerHello message which will contain the following information
- Server Public key,
- chosen protocol version,
- a random number,
- cipher suite
- and compression method from the choices offered by the client.
- To confirm or allow resumed handshakes the server may send a session ID.
The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.2 should not be selected.
Step 3. Browser validates the certificate
Before the browser will accept the certificate and use it to establish the session keys, it validates that the certificate is valid and trusted. To do this:
- It compares the name to which the certificate was issued and checks that it matches the Request and Response header.
- Checks the current date against the certificate validity period dates.
- It uses the Certificate Revocation List (CRL) points to see if the certificate’s thumbprint has been revoked or if it is still valid.
- It also checks the local system to see if it trusts the Certificate Authority that issued the certificate.
If any of these validations fail the browser will alert you to it and provide the option to accept the invalid certificate and proceed to the following step. If the certificate is trusted and no alerts appear, a secure padlock indicator appears in the address bar.
There is another category of certificates that are “extra trusted”. These certificates require additional validation steps between the Certificate Authority and the client.
Step 4. Browser creates the symmetric key
The browser uses the web server certificate’s public key and creates a unique session key. The session key will only be valid for the duration of the session and is therefore referred to as a session key. The browser sends the session key to the server by encrypting it with the public key. Session key at this point is referred to as the pre-master key.
Step 5. Web server decrypts the session key
The web server is in possession of its own private key that can be used to decrypt any message encrypted using its public key. It uses its private key to decrypt the pre-master secret.
At this point both server and client contain the per-master key, Now they individually create another key using the pre-master key and the encryption algorithm called the master key.
Note : The algorithm used in master key computation works in such a way that both parties come up with the identical masterkey.
The same key will now be used at both client and server side as it is a symmetric key pair and will be used for all further encryption for the duration of the session.
The process up to now is known as the SSL handshake.
Step 6. Data is encrypted before sending to the client
The web server now uses the symmetric key to encrypt the data portion of all packets being sent back to the client.
Note : The HTTP header information is not encrypted, allowing for correct routing and reporting of the encrypted traffic.
Step 7. The client browser decrypts the response from the web server
The client browser receives the encrypted data from the web server. It uses its session key to decrypt the data and render the content.
Note : The ssl/tls tunnel is between the client browser and the web server, not the entire client computer. Even if data packets are intercepted on the client with a packet sniffer such as Wire Shark it cannot be decrypted.