In this article, I am going to tell you everything about SSL: What it is, why we need it, its technical and non-technical aspects, etc. This article covers the introduction, SSL certificate, encryption, the process of encryption, and how your browser interacts with and trusts that certificate provided by the website you are visiting.
Existence of SSL
There are basically two aspects of SSL. One is encryption and the second is identification. Encryption is what you do to hide the content of the data sent from one machine to another machine. It is done by changing the content of the data so it looks like garbage that is human-readable but not human-understandable. It is exactly like speaking in a different language with which one person is not familiar. I am Indian; if someone speaks in the Russian language, it is not understandable by me, so to me the Russian language is like an encrypted language. However, if I get a translator and he/she translates that Russian language into Hindi then I can say that now it is understandable by me. So it is said that message has been decrypted.
Identification is related to trust. In the previous scenario, how can I trust the translator who is converting Russian language to Hindi? Is she/he legitimate? Can I trust him/her? In the digital world, it is something like this. Your machine has to trust the SSL certificate (security mechanism) provided by the website via an SSL certificate issuing vendor.
To understand the scenario, let’s take an example directly. Let’s suppose you are sending credit card details to the company (any company/online purchasing website, etc.)
So here is the scenario: You are on the left and you will be sending your card details to the other machine. Now there can be two scenarios:
Without SSL: In this scenario there can be another machine in your network that can grab the details sent by another machine, as shown in the figure below.
As you know, this scenario is without SSL. In this case, any malicious user lying in the same network can perform an MITM attack or any other attack that contains simple network traffic monitoring and can grab your credit card number or any other personal details. So it is always necessary to use SSL to act as a barrier. It creates a tunneling technique.
With SSL: SSL puts the security mechanism on the network layer before you transfer the data. As the picture below shows, it creates a barrier or tunnel through which the user can transfer any data to the other network. This time the malicious user (lying on the same network) will see the tunnel, so he won’t be able to grab your private data as it passes through the tunnel.
As you can in the picture, a malicious user grabs the data passing through the tunnel, but she/he will get encrypted data, not the real plain text data. So the data can be grabbed but now it has only garbage value for the cracker/hacker, as she/he will never come to know that what exactly the real data was. In order to decrypt the data, the hacker will need an encryption key, which she/he will never get.
Let’s see what HTTPS coding looks like. Here I will give you Twitter ‘s sign-in page source code. As you all know, every sign-in page uses the POST method to pass our data to the server. Every POST method is defined under the form. A form action method is shown in the picture below.
You can see here that the action in the HTML code is embedded with HTTPS, which is a secure HTTP method. It confirms that your log-in credentials are secure once you click on the submit button in order to log in. The actual process of Encryption is enclosed below.
The ‘Actual’ Process of Encryption
Everything we are doing is a digital process that happens in no matter of time but, in reality, it’s really a long process that has many steps. At each step, integrity and authenticity are involved.
As soon as you hit the button to log in, First it says that now your machine (computer) is ready for the encryption process. Second, the server will send one certificate to your machine, which has to be digitally signed by you. If you don’t go through the process of logging in, the server will not send your certificate as it’s not actually needed, because you are not going to give any credentials to the server. Third, your machine digitally signs the certificate in the backend and sends it to the server. Indirectly it tells the server that, “I am ready now, kindly start the encryption process, please.“
Fourth, the server receives the certificate signed by your machine and starts the encryption process at the client’s end. Last, the server actually encrypts all the messages passed by the client and, after successful encryption, all the data is passed through the secure tunnel at the server end.
This whole process is called a “handshake.”
The ‘Actual’ Process of Encryption Unleashed in Detail
How does your machine choose an encryption process? What are the different possibilities/methods involved in this process?
Encryption process basically includes three parts.
Encrypting Message: There are many algorithms for encrypting messages. The most famous are AES, 3-DES, and RC4. People generally use one of these methods to encrypt the message. Each algorithm contains many operations, such as shiftrows, subbytes, mixcolumns, addroundkey etc.. That is the only strength of these algorithms. If the algorithm has more operations, it provides better encryption. It is the way of encrypting data between client and the server.
Hashing—This is known as a message authentication code. This term is used in cryptography. It includes a hash function combined with a secret key and it is used for authentication as well as data integrity. The strength of the hashing depends on the cryptographic function used in that along with the key. Generally HMAC-MD5 and HMAC-SHA1 are used for the hashing.
Choosing a Key for Encryption—It contains a key exchange mechanism such as RSA, DSA, or Diffie-Hellman algorithm. One can get more information on this part by searching “TLS and public key cryptography” on Wikipedia.
Scenario: Let’s suppose the computer on the left side is about to send the “Hello World” message to the server and it chooses the AEC cipher method, HMAC-MD5 hashing technique, and RSA key. Along with all these three data, it also sends the version number of SSL used by your machine for TLS (transport layer security) and random number. A random number is nothing but the master calculation that is used to do all other calculation for the encryption process. All this information is passed to the server.
In the next stage, the server sends a certificate to the client. This certificate contains information such as version number, serial number, signature, issuer, validity, subject, IssuerUniqueIdentifier, SubjectUniqueIdentifier, Signature algorithm, signature value, public key, etc.
In phase 3, your computer tells the server to start encryption. Here both machines have to take part in the conversation. There are three steps to accomplish this process.
1. Key Exchange—Here both the machines calculate the master secret code that will be used for the encryption process.
2. Change Original Text—Your computer tells the server to change the original text written in order to send the server. In our case, it’s “Hello World.” So the server actually receives confirmation of starting an encryption process and it starts the encryption process in order to generate the cipher text for our given text.
3. Finish State—In the last stage of the process, your computer tells the server that all the messages have been encrypted now and ready to go.
After all these three states occur, the message is sent to the server.
In phase 4, the server receives the messages from the client side and it encrypts those messages to make it cipher text. Then the server tells the client that it has finished encrypting the message and a message is sent back to the client is in encrypted form. Both of these scenarios are shown together in the pic below.
So this is the scenario of SSL. If we take the-real life scenario, then SSL works something like this:
Another important thing has to be considered while using SSL. It is all about trust. You have to make sure that the website with which you are corresponding is the real website that you assume it is and that you trust. It doesn’t mean that, if you have an SSL certificate, then you are secure. Having an SSL certificate only is not enough, So that is why identification comes into play. It’s all about who you actually trust.
You might have seen the pic below when you try to access a website on the Internet. It represents SSL. There is a whole big process involved behind this dialogue box. The process behind this is something like this:
First the website that you are going to access through SSL has to go to an organization that provides certificate authority. That organization will look into the details of the company/website and it will verify that the information is true about that company.
To get the certificate, the company has to give certain information about itself. That information may include:
The web server name
Location of company
Then the authority company checks whether this information is correct or incorrect. If it is correct, it goes to step 2.
That company then creates one certificate and digitally signs it with cryptographic methods explained previously in this article.
One certificate looks like this (there are different certificates):
The certificate contains this information :
Identifier for issuer
Identifier for company
Public key Information
Now the signature is generated. A certificate contains all this information and the numbers used in this information are taken by the hashing algorithm, which does the calculations and generates signature. So the only number field that contains all this information is taken by the hashing algorithm in order to generate the signature. Then that number gets encrypted with the private key, so anyone who is holding a public key can verify that number.
Then they send the certificate to the company that you are going to access. The certificate generated in step 2 is given back to the company that asked for that certificate. Let’s suppose it runs an IIS/APACHE/TOMCAT web server. It installs that certificate on the web server. One can configure any of these web servers to use that certificate.
On the other hand, when you are trying to access the website, the certificate comes from the website at your end. Your browser will verify the details of the certificate and check that the information is true, then your browser will also sign that certificate. Make sure your browser won’t sign the incorrect certificate. At the client side, the certificate looks as shown below. This will be used in the handshake.
When your browser gets certificate, it verifies it via the signature and then it encrypts the data.
So I have simplified and unleashed SSL in front of you. Now I will give you a practical demonstration of how you can generate your own SSL certificate and how to use it.
How to Generate SSL Certificate
We will download and install the required package to install an SSL certificate. Then we will sign the certificate manually by giving a personal information to the certificate. After this has been completed, we will restart the HTTPD service in order to run our SSL certificate successfully.
Step 1: Downloading and Installing Required Software
To generate an SSL certificate, OpenSSL and mod_ssl must be installed on the system. This tool may have already been installed in Apache, however this varies from system to system. So we will install these tools by using the following command:
# yum install mod_ssl openssl
Figure 1 : mod_ssl Installation process
Step 2: Sign Our SSL Certificate Manually
We will now use OpenSSL to sign our certificate. It is important to have this SSL certificate from a valid and trusted certificate providing authority if the use is for any company or organization. However, if it’s for personal use then one can do it at home and there will be no need for a trusted company to provide a signed certificate.
We will have to follow the steps below to create a self-signed certificate:
Create A Private Key
Figure 2 : Generate Private Key
Figure 3 : Certificate Generation
Key Generation (Self-Signed)
Figure 4 : Key Generation
Put Files In Proper Location
Now that we have configured our task and put files into the right folder, we will update the Apache server by updating the SSL configuration file, which is ssl.conf. We will use the nano editor to update our ssl.conf file and change the path of the key file, where we have stored our files, such as the certificate and key.
Figure 5 : Changing key path in ssl.conf file to make it work properly.
The next step is to save and exit this file, after which we will start HTTPD service by typing the following command in the terminal:
# /etc/init.d/httpd restart
Now that we have set up our secure socket layer, if we attempt to log in to our the server machine through the client machine or attacking machine via the https protocol, it will ask for the authentication. Before the authentication, a dialogue box is shown that warns the “connection is not trusted” and asks if they want to see the certificate that is going to be downloaded to the machine or if they want to stay in offline mode.
Once the user clicks on the view certificate, it will display the certificate that was created earlier. This screenshot below illustrates this step:
Figure 6 : Showing our self generated certificate digitally signed by us
It shows the issuer’s name, organization name, and validity of the certificate. With this secure connection, if one logs in into the website or network, it will encrypt the plain text data and an attacker won’t be able to capture it straight away with the Wireshark option.
Experiment: I have set up the Apache server and I have performed an MITM attack in which I pass log-in credentials without SSL and with SSL. For both ways I captured Wireshark screenshots. Those screenshots are as follows:
Figure 7: Authentication Credentials have been captured in plaintext – WITHOUT SSL
As you can see, one can capture your log-in credentials if you are not using SSL and not encrypting your data.
Figure 8 : SSL Handshake is Being Done
The SSL handshake is being done now in the next picture; you will see the cipher text being generated and passing through the network.
As you can see here, the credentials are encrypted now. No one can see the real credentials of the client passing through the network. Thus we see how SSL is useful to encrypt the data.
SSL can give protection against man-in-the-middle attacks. It can protect sensitive data such as log-in credentials, credit card details, home address, phone number, etc.