SSL
SSL Certificates Explained
Client server connection basics
SSL stands for Secure Sockets Layer. It is a protocol and its primary goal is to provide privacy and reliability between two communicating applications. The internet is all about inter-connected systems, and data flowing over the network between those systems. In the world of exploding internet users, the hacker community is always in a lookout for vulnerabilities in sub systems to hijack this data over network. That is called man in the middle attack. Hence, it is extremely important to encrypt the data over network, which can only be decrypted by the destination server where the data is meant to be sent. This encryption and decryption framework along with the guiding rules are provided by SSL.
The Internet is a packet-switching network. This means that, for two hosts to communicate, they must packetize their data and submit it to a router with the destination address prepended to each packet. The router then analyzes the destination address and routes the packet either to the target host, or to a router that it believes is closer to the target host. The Internet Protocol (IP), outlined in RFC 971, describes the standard for how this packetization is performed and how addresses are attached to packets in headers.
Such a network packet passes over the network through several routers. You can easily identify the routers with traceroute command in windows or tracert in Linux. Below is an example which shows all the routes to https://middlewareworld.org from my PC.
Each router along the way is supposed to respond with a special packet called an ICMP timeout packet, as described in RFC 793, with its own address. The routers that cannot or will not do so are represented with * in the preceding code. Typically, the routers don’t respond because they’re behind a firewall that’s configured not to forward ICMP diagnostic packets. As you can see, there are quite a few hops between my home router and the main webserver of middlewareworld.org.
In network parlance, the connection between sender and receiver is called a socket. Another important terminology is Client and Server. The system from which a connection is initiated is Client, and the destination to which the data is targeted is Server. It is a basic model in all network communications. Creation of a socket stats with a SYN packet being sent from client to server. The server responds with a SYN/ACK. The client acknowledges with an ACK. This is called a 3-way TCP handshake, as shown below:
After the 3-way TCP handshake completes, data starts flowing between client and server. However, note that it is still a non-secure connection without any encryption. To make it secure, we need to implement SSL using a SSL Certificate which is signed by a Certificate Authority (CA).
How to generate SSL Certificate for free?
Before going in detail about encryption, let’s look at how to generate a certificate. Follow the below steps to get a free SSL certificate.
Step1. Go to https://freesslcert.org/
Populate the below fields in the form:
Common Name (CN)*
This is the domain name, using which the client trusts the server. For example, https://middlewareworld.org will have the common name or one of the SAN as middlewareworld.org. Click here to know more about SAN.
For this particular website, the common name is different from the domain, however the list of SAN in the certificate contains the domain. Look at the 2 figures below. Organization (O)*
This is the Organization or Owner of the domain.
Organization Unit (OU)
This is the department under the Organization where the SSL Certificate will be used.
State
The State where the Organization is located.
Country (C)*
Country where the Organization is located.Accept Privacy Policy and Click on “Get Certificate”
Step2. Accept Privacy Policy and Click on “Get Certificate”
Step3. Download the Private Key, Signed Cert, Intermediate and Root certificates
Install the certificate in a webserver e.g. Apache, Tomcat or Node JS
Apache : https://www.digicert.com/kb/csr-ssl-installation/apache-openssl.htm#ssl_certificate_install
Tomcat : http://middlewareworld.org/2020/06/22/configure-ssl-in-tomcat/
Node JS : https://nodejs.org/en/knowledge/HTTP/servers/how-to-create-a-HTTPS-server/
Validate whether SSL encrypt data over https?
To have a deep understanding of SSL, let’s validate whether the above steps really work, and whether data gets really encrypted over the network. Download Wireshark from https://www.wireshark.org/download.html to capture network packets, and install.
Start capturing packet on your local network interface. Looks at the below screenshots for exact steps.
Step1. Just after opening Wireshark, you can see the interfaces mounted on your laptop, and the network traffic graph.
Step2. Double click on the interface which is in use. Next screen shows the continuous flow of network packets to and from your device/laptop.
Step3. Since there are a lot of traffic flowing through a device, at any point in time, it is important to classify the intended traffic, for easy identification. Pick 2 websites, one with SSL and the other without SSL, and get their IP addresses using ping command.
Step4. For below website, both SSL and NON-SSL are enabled, and the IP is 74.220.219.192
C:\Users\anbanerj>ping middlewareworld.org
Pinging middlewareworld.org [74.220.219.192] with 32 bytes of data:
Reply from 74.220.219.192: bytes=32 time=253ms TTL=48
Reply from 74.220.219.192: bytes=32 time=268ms TTL=48
Reply from 74.220.219.192: bytes=32 time=285ms TTL=48
Step5. Use ip.addr == 74.220.219.192 as filter to log on the packets, to and from middlewareworld.org
Step6. Let’s capture the traffic over HTTP (Not Encrypted) first. Access the URL http://middlewareworld.org only once.
Step 6a. Look at the below packet, that has (text/html) in the info. It denotes that this is the consolidated response from that single request. Don’t get deceived by the 404 Not Found message. It indicates that one resource in the complete webpage returned with 404, but not the whole page.
Step 6b. Double Click on the packet to see the details. Expand the HyperText Transfer Protocol.
Check the Content-Length above (7243). This is the response html.
Upon expanding the Line-based text data, you see the exact html that is returned.
Hence, we see that the data is not encrypted over HTTP.
Step7. Now, let’s verify the data over HTTPS.
Step8. Repeat step 6 by accessing the same URL over SSL ( https://middlewareworld.org )
Now, let’s look at the packet capture.
Client (Source) => 192.168.1.123
Server (Destination) => 74.220.219.192
The first 3 packets clearly show the 3-way TCP handshake that happens before the connection socket is created.
SYN Packet sent from Client to Server
Server responds with SYN/ACK
Client Acknowledges with ACK
At this point, the 3-way TCP handshake has been completed successfully.
Client sends Client Hello to Server
Server acknowledge the Client Hello with an ACK
Then, Server sends a set of information to client:
b) Cipher Suites supported by the Server
Then, the server sends the certificate along with the public key, which client uses to encrypt the data over network before sending to server.
Here we can see clearly that the data exchange has stated via TLS.
If you expand any packet, marked as “Application Data”, it shows that the data transferred over network is completely encrypted, thus secure from eavesdropping. It cannot be decrypted without the Private Key of the Server.
