Taking a closer look at SSL/TLS Certificates and how SSL/TLS works
You may have heard of SSL, your website may even employ SSL encryption—but do you know how it works? Do you care? Of course you do. You have an inquisitive mind, that’s why you clicked this link!
In this article we’ll take a look at the inner-workings of SSL, including SSL architecture, digital signatures, PKI and SSL’s interactions and processes.
SSL, which is short for Secure Sockets Layer (today, we actually use its successor Transport Layer Security (TLS) but still colloquially refer to it as SSL), is really two things. It’s a certificate and a protocol.
Think of the certificate as a driver’s license of sorts. It both verifies the identity of its holder while also granting certain permissions. The SSL protocol handles the actual encryption and decryption – in this car metaphor, the protocol is like the engine – we’ll talk about how it works later.
SSL Certificates are issued by Certificate Authorities. Certificate Authorities are trusted third parties that authenticate websites and issue SSL certificates. When we say trusted, what we mean is that they are considered trusted by web browsers and operating systems, and are essentially vouching for the authenticity of the websites they’re issuing SSL Certificates to.
As far as a web browser is concerned, there are two tiers of vouching. There’s Domain Validation and Organization Validation, which grant one level of authentication. And then the second tier is Extended Validation, which grants the highest level of authentication.
When a company or person wants an SSL certificate they first fill out a certificate signing request, or CSR. That is then submitted to the CA who goes through the necessary steps to vet the requester. The certificate is then created, signed and delivered for installation.
In order to grant the certificates, the CA’s must digitally sign them. A digital signature is a lot like a traditional signature, but more secure and they offer additional benefits.
When a document is digitally signed it:
- Confirms that the CA signed the document
- Insures the integrity of the document’s contents
- Binds itself to the signing activity, meaning only the CA could have signed the certificate.
In order to sign a certificate, a hash of the data to be signed must be produced. The result is then encrypted with the sender’s public key and appended to the data. This is what protects the integrity of the hash result.
The recipient of the data then uses the corresponding private key (don’t worry, we’ll explain public and private keys in a bit), to decrypt the hash.
A new hash result is then created, it is matched up against the original signed hash result and if the two codes are the same, it indicates that the data hasn’t been altered. This means the recipient can verify the sender, because only the entity with the private key could have signed it.
PKI (public key infrastructure)
You may be wondering what we meant back there when we referred to public and private keys. That all relates to PKI, or Public Key Infrastructure. PKI is the underlying framework for SSL and many other kinds of encryption. Public Key Infrastructure implements encryption using a process called asymmetric cryptography.
Asymmetric cryptography involves two keys, one which performs the encryption and another which performs decryption. The keys are created and used in pairs, there is a private key and a public key. The public key is available to anyone who wants it, but the private key is kept by its owner and should never be handed out.
When someone wants to send information, they use the recipient’s public key to encrypt the information they are sending. The SSL protocol takes care of all of these steps invisibly in the background. The recipient is then the only person (or website) with the private key who can decrypt it.
So how does SSL work? You now understand how a certificate is issued, how it’s signed and what PKI is, but how does it all fit together?
When you visit a site the first thing your computer does is looks for the site’s SSL certificate (well, maybe not the first thing—but one of them). This lets your computer know if the site has been verified and if encryption will be used during communication.
If an SSL certificate is present the computer and the website do something called the SSL handshake, wherein they trade information and capabilities so they can decide exactly how they will be encrypting information.
If the handshake is successful, encrypted communication begins. The “client” – which is the computer connecting to the website – uses the website’s public key to encrypt any information it’s sending – this can be anything from credit card info to computer requests for which page they want to access – while the website uses the private key to decrypt the information once its reached its server.
This keeps the information safe from malicious third parties who may want to steal it.
How SSL/TLS Works
While there’s plenty of much more in-depth topics when it comes to SSL/TLS, that’s a basic overview of how SSL/TLS works.
- The certificate request is made to the CA via a CSR, the CA then vets the requester and issues the certificate.
- During issuance, the certificate is signed by the CA using a complex hashing algorithm to ensure its contents are not altered
- The certificate vouches for the requestor’s identity and allows them use of PKI.
- Once the certificate is installed on the requester’s website, it begins to encrypt the data of the site’s visitors by creating secure and encrypted connections via the SSL handshake.
We could go into more detail about root certificates, cross signing, SHA1 and SHA2, ECC Algorithm, etc. And we will at a later date. But for now, this should serve as a nice entry point into how SSL/TLS works, its architecture, its processes and its interactions.