TLS Certificates
In this tutorial we will discuss about TLS certificates. Securing the Kubernetes cluster with TLS and troubleshooting TLS related issues can be especially difficult if you are not familiar with the basics of TLS certificates.
In this tutorial we will look at the absolute basics of what TLS certificates are? Why you need them and how you can configure certificates to secure SSH or web servers.
A certificate is used to guarantee trust between two parties during a transaction.
For example, when a user tries to access a web server, TLS certificates ensure that the communication between the user and the server is encrypted and the server is who it says it is.
Let’s take a look at a scenario. Without secure connectivity, If a user were to access his online banking application 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 it to hack into the user’s bank account. Well that’s obviously not safe.
So you must encrypt the data being transferred using encryption keys. The data is encrypted using a key which is basically a set of random numbers and alphabets.
You add the random number to your data and you encrypted into a format that cannot be recognized.
Now the data is then sent to the server. The hacker sniffing the network gets the data 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. So that the server can 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.
Symmetric Encryption
It is a secure way of encryption but since it uses the same key to encrypt and decrypt the data.
Since the key has to be exchanged between the sender and the receiver there is a risk of a hacker gaining access to the key and decrypting the data and that’s where asymmetric encryption comes in.
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 well they are private and public keys.
But for the sake of this example we will call it a private key and a public lock we will get back to that at the end. But for now think of it as a key and a lock pair a key which is only with me. So it’s private. A lock that anyone can access. So it’s public.
The trick here is if you encrypt or lock the data with your lock you can only open it with the associated key. So your key must always be secure with you and not be shared with anyone else. It’s private.
But the lock is public and may be shared with others. But they can only lock something with it. No matter what is locked Using the public lock it can only be unlocked by your private key.
Before we go back to our Web server example, let’s look at an even simpler use case of securing SSH access to servers through key pairs.
You have a server in your environment that you need access to. You don’t want to use passwords as they’re too risky.
So you decide to use key pairs you generate a public and private key pair. You can do this by running the ssh_keygen command. It creates two files. Id_rsa is the private key and id_rsa.pub is the public key.
You then secure your server by locking down all access to it. Except through a door that is locked using your public lock. It’s usually done by adding an entry with your public key into the servers
$ vi ~/.ssh/authorized_keys
So you see the look is public and anyone can attempt to break through. But as long as no one gets their hands on your private key which is safe with you on your laptop no one can gain access to the server.
When you try to SSH you specify the location of your private key in your SSH command.
$ ssh -i id_rsa ashok@10.58.47.65
What if you have other servers in your environment. How do you secure more than one server with your key pair?
Well you can create copies of your public lock and place them on as many servers as you want. You can use the same private key to SSH into all of your servers securely.
What if other users need access to your servers well they can do the same thing. They can generate their own public and private key pairs as the only person who has access to those servers.
You can create an additional door for them and lock it with their public locks copy their public locks to all the servers. And now other users can access the servers using their private keys.
Web server example
Now Let’s go back to our Web server example.
You 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 along with 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 continue communication with each other using symmetric encryption.
To securely transfer the symmetric key from the client to the server, we use Asymmetric Encryption. So, we generate a public and private key pair on the server.
We’re going to refer to the public lock as public key going forward now that you have got the idea that The ssh-keygen command we used earlier creates a pair of keys for SSH purposes. So the format is a bit different.
Here we use the openssl command to generate a private and public key pair.
When the user first accesses the web server using https, he gets the public key from the server. Since the hacker is sniffing all traffic that is assumed he too gets a copy of the public key.
The user, In fact the user’s browser then encrypts the symmetric key using the public key provided by the server. The symmetric key is now secure the user then sends this to the server.
The hacker also gets a copy the server uses the private key to decrypt the message and retrieve the symmetric key from it.
However the hacker does not have the private key to decrypt and retrieve the symmetric key from the message it received. The hacker only has the public key with which he can only lock or encrypt a message and not decrypt the message.
The symmetric key is now safely available only to the user and the server. They can now use the symmetric key to encrypt data and sent to each other. The receiver can use the same symmetric key to decrypt data and retrieve information.
The hacker is left with the encrypted messages and public keys with which he can decrypt any data.
With asymmetric encryption, we have successfully transferred the symmetric keys from the user to the server and with the symmetric encryption, we have secured all future communication between them.
The hacker now looks for new ways to hack into our account and so he realizes that the only way he can get your credential is by getting you to type it into a form he presents.
So he creates a Web site that looks exactly like your bank’s web site. The design is the same. The graphics are the same. The Web site is a replica of the actual bank’s Web site. He hosts the website on his own server. He wants you to think it’s secure too.
So he generates his own set of public and private key pairs and configure them on his web server. And finally he somehow manages to tweak your environment or your network to route your requests going to your bank’s web site to his servers.
When you open up your browser and type the website address in you see a very familiar page the same login page of your bank that you’re used to seeing.
So you go ahead and type in the username and password. You made sure you typed in HTTPS in the URL to make sure that communication is secure encrypted.
Now your browser receives the key you send encrypted symmetric key and then you send your credentials encrypted with the key and the receiver decrypt the credentials with the same symmetric key.
You’ve been communicating securely in an encrypted manner but with the hackers server. As soon as you send in your credentials, you see a dashboard that doesn’t look very much like your bank’s dashboard.
What if you could look at the key you received from the server and see if it is a legitimate key from the real bank server.
When the server since the key it does not send the key alone. It sends a certificate that has the key in it.
If you take a closer look at the certificate you will see that it is like an actual certificate, but in a digital format. It has information about who the certificate is issued to, the public key of that server the location of that server etc.
Every certificate has a name on it the person or subject to whom the certificate is issued to. That is very important as that is the field that helps you validate their identity.
If this is for a web server this must match what the user types in the you are on his browser. If the bank is known by any other names and if they like their users to access their application with the other names as well then all those names should be specified in the certificate under the subject alternative name section.
But you see anyone can generate a certificate like this. You could generate one for yourself saying you’re Google and that’s what the hacker did in this case. He generated a certificate saying he is your bank’s web site.
So how do you look at a certificate and verify if it is legit? That is where the most important part of the certificate comes into play. Who’s signed and issued the certificate.
If you generate the certificate then you will have to sign it by yourself. That is known as a self signed certificate.
Anyone looking at the certificate you generated, will immediately know that it is not a safe certificate because you have signed.
If you looked at the certificate you received from the hacker closely you would have noticed that it was a fake certificate that was signed by the hacker himself. As a matter of fact your browser does that for you.
All of the web browsers are built in with a Certificate validation mechanism, wherein 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 actually warns you.
So then how do you create a legitimate certificate for your web servers that the web browsers will trust. How do you get your certificates signed by someone with authority. That’s where Certificate Authorities or CAs comes in.
Certificate Authority (CA)
Certificate Authorities are well known organizations that can sign and validate your certificates for you. Some of the popular ones are Symantec, Digicert, Comodo, GlobalSign etc.
The way this works is you generate a certificate signing a request or CSR using the key you generated earlier and the domain name of your Web site.
You can do this again using the openssl command. This generates a my-bank.csr file which is the certificate signing request that should be sent to the CA for signing.
The certificate authorities verify your details and once it checks out they sign the certificate and send it back to you.
You now have a certificate signed by a CA that the process trust. If hacker tried to get his certificate signed the same way he would fail during the validation phase and his certificate would be rejected by the CA.
So the Web site that he’s hosting won’t have a valid certificate. The CAs use different techniques to make sure that you are the actual owner of that domain.
You now have a certificate signed by CA that the browser is trust. But how do the browsers know that the CA itself was legitimate? For example what if the certificate was signed by a fake CA.
In this case our certificate was signed by Symantec. How would the browser know Symantec is a valid CA and that the certificate was in fact signed by Symantec and not by someone who says they are semantec.
The CA is themselves have a set of public and private key pairs. The CA is use their private keys to sign the certificates. The public keys of all the CAs are built in to the browsers.
The browser uses the public key of the CA to validate that the certificate was actually signed by the CA themselves.
You can actually see them in the settings of your web browser, under certificates. They are under trusted CAs tab.
Now 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 you validate sites hosted privately say within your organization. For example, for accessing your payroll or internal email applications. For that you can host your own private CAs. Most of these companies listed here have a private offering of their services.
A CA server that you can deploy internally within your company. You can then have the public key of your internal CA server installed on all your employees browsers and establish secure connectivity within your organization.
Summarization
We have discussed why you may want to encrypt messages being sent over a network to encrypt messages.
We use asymmetric encryption with a pair of public and private keys and admin uses a pair of keys to secure SSH connectivity to the servers.
The server uses a pair of keys to secure HTTPS traffic. For this the server first sends a certificate signing request to a CA. The CA uses its private key to sign the CSR. Remember all users have a copy of the CAs public key.The signed certificate is then sent back to the server the server configure is the web application with the signed certificate.
Whenever a user accesses the web application the server first sends the certificate with its public key. The user or rather the user’s browser reads the certificate and uses the CA’s public key to validate and retrieve the servers Public key. It then generates a symmetric key that it wishes to use going forward for all communication.
The symmetric key is encrypted using the server as public key and sent back to the server. The server uses its private key to decrypt the message and retrieve the symmetric key. The symmetric key is used for communication going forward.
So the administrator generates a key pair for securing SSH. The web server generates a key pair for securing the web site with HTTPS, the Certificate Authority generates its own set of key pair to sign certificates.
The end user though only generates a single symmetric key. Once he establishes trust with the Website he uses his username and password to authenticate the Web server.
With the servers key pairs, The client was able to validate that the server is who they say they are but the server does not for sure know if the client is who they say they are. It could be a hacker impersonating a user by somehow gaining access to his credentials not over the network for sure as we have secured it already with TLS.
So what can the server do to validate that the client is who they say they are? For this as part of the initial trust building exercise, The server can request a certificate from the client and so the client must generate a pair of keys and a signed certificate from a valid CA the client then sends the certificate to the server for it to verify that the client is who they say they are.
Now you must be thinking you have never generated a client’s certificate to access a Web site. Well that’s because, TLS client certificates are not generally implemented on web servers. Even if they are it’s all implemented under the hood.
So in normal user don’t have to generate and manage certificates manually. So that was the final piece about client certificates.
This 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.