These days we all know security is of paramount importance. With increasing online data exchange, we should feel secure while logging into a bank’s website or buying products from e-commerce websites, etc., and not fall victim to cybercrime by compromising our passwords and Credit card information. To ensure all the information is exchanged over the internet securely, we use SSL certificates.
SSL Stands for Secure Socket Layer, a global security technology that enables encrypted communication between the web browser (end-user) and a web server. It also guarantees the trust between two parties during a transaction. Before we explain much more about SSL certificates, let’s try to understand a few terminologies.
- Authentication: It is a process of verifying the identity of someone (user, device, or process) who they say they are.
- HTTP (Hyper Text Transfer Protocol): It listens on port 80. It’s when we enter the http:// in the browser address bar in the beginning. It’s using another TCP protocol to send and receive data over the web.
- HTTPS (Hyper Text Transfer Protocol Secure): It listens on port 443. It’s when we enter the https:// in the browser address bar in the beginning. HTTPS method is secured because it uses SSL certificates. Also, the data is transmitted in an encrypted form as compared to the HTTP protocol.
- Encryption: Process of converting plain text to a non-human readable format, called ciphertext.
- Decryption: Process of converting cipher text into plain text. The message is encrypted at the sender’s side and then transmitted to recipients, where its decrypted. The encryption and decryption process ensures to keep username, passwords, credit card details, etc., secure when transmitted over the internet.
- Public Key: As the name suggests public, this key is known to everyone.
- Private Key: Its nature is private and is only known to the owner.
Now we have some basic understanding of the terminologies mentioned above, let’s understand in detail using some scenarios:
Scenario 1: Without secure connectivity – HTTP
If a user were to access his online banking website the credentials, he types in would be sent in a plain text format. The hacker sniffing network traffic could easily retrieve the credentials and use them to hack into the user’s bank account; obviously, it’s not a safe method.
Scenario 2: With secure connectivity – HTTPS
Resuming from the earlier scenario, we must encrypt the data being transferred using encryption keys. The information is encrypted using a single key (which is a set of random numbers and alphabets); we add the random number and alphabets to the data and encrypt into a format (ciphertext) that cannot be recognized; the data is then sent to the server. The hacker sniffing the network gets the information but can’t do anything with it. However, the same is the case with the server receiving the data; it cannot decrypt that data without the key. So, a copy of the key must also be sent to the server to decrypt and read the message since the key is also sent over the same network. The attacker can sniff that as well and decrypt that data with it.
This is known as Symmetric Encryption. It is not a secure way of encryption because it uses the same key to encrypt and decrypt the data. Since the key has to be exchanged between the sender and the receiver via the internet, there is a hacker’s risk of gaining access to the key and decrypt the data, and that’s where asymmetric encryption comes in.
Scenario 3: With secure connectivity – HTTPS (Asymmetric Encryption)
Instead of using a single key to encrypt and decrypt data, Asymmetric encryption uses a pair of keys. A private key and a public key. The idea here is to encrypt the data with one key and decrypt it with another key. Usually, data is encrypted using a public key but decrypted using a private only because it is always with an owner and not shared with anyone else.
We see the problem we had earlier with symmetric encryption was that the key used to encrypt data had to be sent to the server over the network and the encrypted data. And so there is a risk of the hacker getting the key to decrypt the data. What if we could somehow get the key to the server safely? Once the key is safely made available to the server, the server and client can safely communicate. The below steps simplify the communication process.
- Generate a public and private key pair.
- When the user first accesses the web server using https, he receives the public key from the server.
- Since the hacker is sniffing all traffic, he gets a copy of the server’s public key.
- The user’s browser then encrypts the user’s private key using the server’s public key.
- The user’s private key is now secure; the user then sends this to the server.
- The hacker also gets a copy.
- The server uses their private key to decrypt the message and retrieve the user’s private key.
- However, the hacker does not have the server private key to decrypt and cannot retrieve the user’s private key from the message it received.
- The user now uses his public key to encrypts the information and send it to the server.
- The hacker also gets a copy.
- However, the hacker does not have the user’s private key to decrypt the data.
- The server already has the user’s private key to decrypt the data and use the same keys for further communication.
The hacker is left with the encrypted messages and public keys with which he can’t decrypt any data. We have successfully enabled secure communication between a user and the server.
Scenario 4: Phishing Attack
Now Hacker search for new ways to hack the account, and he comes up with a Phishing attack. A cyberattack in which a hacker tries to steal the credentials and other personal secret information by luring the user. One way is when a hacker sends an email that looks like it comes from a trusted sender and fools the user to provide confidential information on a scam website that looks exactly like a bank’s website, which the user is trying to open. As soon as the user enters their personal information, they will realize they have been hacked. What if we could look at the key received from the server and see if it is a legitimate key from the real bank server?
When the server sends the key, it does not send the key alone. It sends a certificate that has the key in it. Let’s take a closer look at the certificate. We will see that it is like an actual certificate but in a digital format with information about whom the certificate is issued to, the public key of that server, the server’s location, etc.
If the bank application is known by many other names and if they like their users to access their application with the different names, then all those names should be specified in the certificate under the subject alternative name section. But the problem is anyone can generate a certificate like this and say they are Barclays, and that’s what the hacker did in this case. He generated a certificate stating the bank’s web site. So how do we look at a certificate and verify if it is legit?
That is where the most crucial part of the certificate comes into play who has signed and issued the certificate.
CA’s and Self-Signed Certificates
If we generate the certificate, then we will have to sign it by ourselves. That is called a self-signed certificate.
Anyone looking at the certificate we generated will immediately know that it is not a real certificate because we have signed it. If we looked at the certificate we received from the hacker closely, we would have noticed that it was a fake certificate that was signed by the hacker. Our browser (Chrome, Safari, Edge, etc.) does that automatically. All of the web browsers are built-in with a Certificate validation mechanism. The browser checks the certificate received from the server and validates it to make sure it is legitimate. If it identifies it to be a fake certificate, then it warns the user.
So then, how do we create a legitimate certificate for our web servers that the web browsers will trust? How do we get our certificates signed by someone with authority? That’s where Certificate Authorities or CAs come in. They are well-known organizations that can sign and validate the certificates for us. Some of the popular CA’s are Symantec, DigiCert, GlobalSign, etc.
This works because we generate a certificate signing request or CSR that should be sent to the CA for signing. The CA verify all details and sign the certificate and send it back. We now have a certificate signed by a CA that the process trust; if a hacker tried to get his certificate signed the same way, he would fail during the validation phase, and the CA would reject his certificate. So the Web site that he’s hosting won’t have a valid certificate. We now have a certificate signed by CA that the browser is trust. But how do the browsers know that the CA’s itself was legitimate?
What if the certificate was signed by a fake CA? In this case, our certificate was signed by, say, Digicert. How would the browser know Digicert is a valid CA and that the certificate was signed by Digicert and not by someone who says they are Digicert. The CA is themselves have a set of public and private key pairs. The CA uses their private keys to sign the certificates; the public keys of all the CAs are built into the browsers. The browser uses the CA’s public key to validate that the certificate was signed by the CA’s themselves.
We can view them in the settings of the web browser under certificates. They are under the trusted root CAs tab.
These are public CAs that help us ensure the public websites we visit, like our banks, email, etc. Are legitimate. However, they don’t help us validate sites hosted privately, say within our organization, for accessing internal payroll or email applications. For that, we can host our own private CAs. Most of these companies listed here have a private offering of their services. A CA server that can be deployed internally within a company. We can then have the internal CA server’s public key installed on all the employee’s browsers and establish secure connectivity within an organization.
The whole infrastructure, including the CA, the servers, the people, and the process of generating, distributing, and maintaining digital certificates, is known as public key infrastructure or PKI.