TLS Certificates
Why TLS Certificates?
at the very basic level, TLS certificate is a way to
- establish trust and
- enable secure communication between
- client and server or
- user and the application
to get the terms right. In any communication, one party is always initiating the request, so the user or client is the one that initiates the communication. And on the other side there is a server or an application or some kind of service that gets that request and replies to it.
And Internet is used to exchange all kinds of data, like user accessing their banking application and their bank details, or a web application requesting credit card information from a payment service, etc. So anytime personal and sensitive data is exchanged, this communication has to be secure.
Now what does secure communication actually mean? Well, let’s say an example of a user accessing their online banking website. To access their account, the user must first log into the account, Right? Without unencrypted communication, users login credentials will be sent to the server in plaintext. If a hacker intercepts the traffic, they will simply see the credentials in plain text and be able to use it to login to the user’s account.
So first step for securing the communication between client and the server is to encrypt the data so that hackers can’t see that in plain text.
And encryption is a concept that has been around for thousands of years. And at its core, you basically just take a random string and use it to change the plain text into an encrypted non human readable text.
And that random string is called an encryption key. Encryption is its own subject in computer security. So we won’t go into too much detail of how that works exactly,
Symmetric Encryption
but it’s enough to know that a randomly generated encryption key is used to encrypt plaintext data so that hackers cannot read it. And that same key is then used to decrypt the encrypted data as well.
This kind of encryption, when you use the same key to encrypt and decrypt the data, is called symmetric encryption.
Now when a user logs into their account, the credentials
are sent to the server encrypted, so that hacker
that is sniffing the traffic cannot actually read it.
The problem is though, the server cannot read
it either because it can’t decrypt the data without the
key of the client. So the client needs to send the
encryption key to the server as well. The problem is that
the hacker can Also get the copy of that key sent
to the server. And that’s where an asymmetric encryption
comes into play.
Asymmetric encryption
Link to original
Certificate Authority (CA)
Now the hacker is not able to see the data between client and server
and is not able to impersonate the client.
So the only option they have to get your personal data
like login credentials or credit card information is
impersonating the server.
So when you visit your
social media page or your banking account to log
in, the hacker manages to route your request to their
own website or application, which looks exactly the
way as the valid website and has a secure protocol
HTTPs for communication. So just by
looking at the website you don’t know whether it’s a fake or
a real website. And and this way hacker will act as
the real server. It will have its own asymmetric key pair generated.
It will then send client its public key.
Client will encrypt its symmetric key with hacker’s
public key and send it back, establishing a secure connection
with the hacker’s server. And any data user enters
like credentials, personal data will end up on the hacker’s computer.
So what is a way to avoid that? Or how can a
client validate that the public key which
server sent it really belongs to its online
banking website or its social media website and not a fake
hacker website?
That’s where certificates come
in. The admins of the real website can get the public
key signed and certified by
what’s called a certificate authority or also
called CA is an entity that gives website
owners a digital certificate that certifies the
ownership of that specific website and its domain.
So basically the owner of the real website and its domain
asks an authorized party to sign their certificate as
a proof that their public key is really
for the website, mybank.com or facebook.com etc.
And this authorized party or certificate authority will
issue a certificate which has a public key embedded and
includes the name of the real website and its domain and
a signature of the ca. So it has to be
signed by the certificate authority. If the website has
subdomains or any other domains, including the language domains for
their website, all of them should be included in their certificate
for a client to validate them. So when you access the real
website in your browser, the browser which is the client will
check the certificate, make sure the certificate
is valid and issued for this domain name
and that the signature is from a valid
or authorized ca.
Client Certificates
The same way servers need to also protect themselves
from the hackers, just like clients. So the server can also
request a certificate from the client to verify
that it’s talking to the legit client and not a hacker.
These are the client certificates which work pretty much the same
way. They get signed by trusted CA which server
can validate. Now you may be thinking you have never generated
a client certificate for connecting to websites, right?
Well, it actually happens in the background, so you don’t have to do
it yourself. Otherwise it will be very inconvenient for the website
users if they had to somehow do this themselves.
However, we will see how to generate client certificate
to connect to the Kubernetes API server in the following lectures.
Now I mentioned that when a server gets a certificate signed
by CA Client will validate and see that the
signature is valid. But how does the browser
know that the CA that signed the certificate is
a legitimate one? Because the hacker could have created their
own CA and issued the certificate for their
public key. So how is client able to validate that
the signature is valid?
Well, there is actually an official list of all authorized and acknowledged CAs. And these CAs are trusted organizations that issue digital certificates.
And each modern operating system
has a list of such CAs already packaged inside.
That’s where browsers can verify whether the CA is trusted or not. So when you see the hacker’s website, it will have a certificate that certifies the ownership of the website, but it won’t be signed by the trusted ca.
And when the browser sees that, most browsers
will give you a warning saying insecure certificate, meaning it
was not signed by a known or trusted CA.
One of the CAs on that official list, it was signed by an
unknown source, which can be hacker’s own CA that hacker
generated and used to issue the certificate. This is
also called a self signed certificate.
Self Signed Certificates
Now how do we actually create this key for the server for our application and get a certificate from a ca? Well there are actually simple command line tools such as Open SSL that give you commands to do it.
Using this tool we can generate a private key and then using that key we can generate a certificate signing request with a public key
inside which we will then send to the CA for signing.
So we have the private and public key pair, but one, the public key to be certified by a trusted CA so that clients will accept it.
CA will then actually certify
the details of your website, company, domain name ownership,
et cetera, all the data that you entered. And if everything
is fine, they will issue a signed certificate and send it
back to you.
So if the hacker tried to get the certificate signed
by the ca, they will fail in the information validation
stage and won’t get the certificate from the ca.
So that’s how the whole process works. And this whole infrastructure with
the process of issuing, validating, maintaining certificates,
as well as all the CAs involved, servers, keys,
etc. Is called a Public Key Infrsastructure (PKI).
