SSL encryption applies two keys named Public key and Private Key to encrypt connection. Both keys are similar in nature but their usage is different. Even these keys length may vary in terms of bits. The more the key is lengthy; it is hard to break it. The receiver uses public key to encode the message or data while a private key is used to decrypt the data. It assures that the message is original and encrypted by your private key.
The SSL certificate is issued for a specific server and the domain name. SSL certificates are delivers by SSL Certificate Authorities.
When a person uses any browser to navigate the website having SSL certificate than SSL handshake takes place between browser and server.
- First, the browser requests that the web server identify it, the server sends a copy of its SSL certificate. Then the browser will check whether it is valid or not if yes then sends a message to the server.
- After that, the server sends back a digital certificate to start the SSL encrypted session. Only encrypted data is shared between the server and a browser.
How SSL encryption Works
All digital certificates are examples of Public Key Interchange, or PKI. At its most basic, PKI depends on a pair of interdependent keys, a public key and a private key. The public key is used to encrypt information, and the private key is used to decipher it.
SSL works by making the public key available through the publicly accessible website. In contrast, the private key remains secured on the web server so that any data submitted from the website where the public key is located can only be deciphered by the site owner, creating a secure 1:1 communication.
When a person visits a site with an SSL certificate, a “handshake” occurs to create a secure channel between the user and the organization and protect any data submitted on the website from being compromised. Here’s how the handshake process works in real-time:
- A client system such as a popular web browser connects to a server secured with an SSL/TLS certificate.
- The browser sends a request to the server to identify itself.
- The server sends back a copy of its SSL certificate, including type, validity period, and organizational details.
- The browser checks whether it trusts the certificate and sends an approval back to the server. If the certificate is not installed, not up-to-date with the proper security protocols, or not issued by a CA trusted by the browser, the user will see a warning message in the browser’s address bar.
- The server sends back a digitally signed acknowledgment to start an SSL encrypted session.
- Any data shared between the browser and the server is now secure. If a hacker intercepts the communication, it will remain encrypted with a cryptographic code that cannot be decrypted.
How to check the connection is encrypted?
When SSL is installed on a web server, it enables the padlock to appear in the web browser. It activates the HTTPS protocol and creates a secure connection between the server and a browser. It enables use of encryption algorithms to scramble the data in transit into an indecipherable format that can only be read with the proper decryption key.
When we’re accessing sensitive information, such as an online bank account or a payment transfer service like PayPal or Google Checkout, chances are we’ll see this type of format change and know our information will most likely pass along securely.
Check a SSL encryption Connection With OpenSSL in Linux
We will use the openssl s_client command for testing secure connections . The basic command outline is as follows:
[root@host ~]# openssl s_client -connect <domain name or IP>:<port>
In order to test a connection, we are going to need a domain name and a port. For the purpose of this test, we will be using the sslhow.com domain. Since we are trying to confirm if our connection is secure, we will use port 443, which is the standard port for all secured HTTP (Hypertext Transfer Protocol over TLS/SSL) traffic.
The command we are going to use will open a connection to the www.sslhow.com domain on port 443 and show us the SSL certificate used on it. It will provide us with a fair amount of other relevant output, such as the certificate chain, the ciphers that are in use, and other characteristics of the SSL/TLS session.
However, once connected, we will be able to type whatever we want, and that will provide us with the opportunity to send HTTP requests manually. For those who previously used the telnet command, this will feel familiar as the tool itself is similar to it. To test the connection to sslhow.com domain on port 443, we are going to use the following command:
% openssl s_client -connect sslhow.com:443 CONNECTED(00000005) depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root verify return:1 depth=1 C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3 verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = elementor.cloud verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=elementor.cloud i:/C=US/O=Cloudflare, Inc./CN=Cloudflare Inc ECC CA-3 1 s:/C=US/O=Cloudflare, Inc./CN=Cloudflare Inc ECC CA-3 i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root