Skip to main content

What does having an S in httpS provide us?

· 9 min read
Aqueeb
Aqueeb
Enterprise Architect, Technology Enthusiast, & an Avid Motorcyclist

But first, what does the S stand for?​

The S stands for Secure in HTTPS. The full acronym decoded is a mouthful (though nothing like SHIELD 🤣). HTTPS stands for Hyper Text Transfer Protocol Secure.

Why do we need SSL Certificates?​

An SSL certificate, from here on referred to as TLS certificates, allow us to provide the following.

Confidentiality​

All communications are encrypted between the website and the user's browser.

Authentication​

The certificate assures users that they are connecting to the intended server and not an imposter.

Integrity​

It ensures that the data exchanged has not been altered during transmission.

Okay, but how does this work in practice?​

Now that we know what the S provides to an HTTP connection let's discuss a few concepts around how trust is established (the website IS indeed who they say they are).

Certificate validation​

Note: Most of the images are clickable to activate animations.

When you visit aqueeb.com, the first thing your browser does, is check to see if the certificate that aqueeb.com is presenting to your browser, is valid or not. One of the ways that this validation happens is by checking:

GIF Preview

Important to note is that *.google.com will NOT be valid for nested subdomains. By that I mean nested.accounts.google.com is NOT a valid FQDN for a wildcard Common Name of *.google.com while accounts.google.com is perfectly fine.

This is all well and good, we have established that the certificate we are looking at contains the correct attributes, but how do we trust the certificate? The process used to create a certificate with all these attributes is well documented and anyone can go ahead and create certificates with the attributes that we just discussed (CN, SANs, Wildcard CNs) so then what is the point of all of this 🤷???

Enter Chain of Trust​

There is a concept in cryptography called asymmetric cryptography. Asymmetric cryptography uses pairs of Public and Private Keys to facilitate secure communication. For simplicity, let's understand that these key pairs are long strings of characters mathematically linked. The tools that generate these keys, always generate a pair of a Private Key and a Public Key and then the Public Key is shared with the world (in our case, our browsers).

I highly recommend reading the ISC2 CISSP Certified Information Systems Security Professional Official Study Guide Chapter 7 which dives deep into Public Key Infrastructure and all the concepts that underpin it.

I've deliberately simplified the sequence diagram just to illustrate my point around what a very simple chain of trust is and then I'll elaborate later with intermediaries ⬅️ I'll explain this later.

What is important to note here is the concept of mathematically confirming that the certificate that was issued to the Certificate Requestor was indeed generated using the Private Key.

In simple terms, the chain of trust ensures that when you connect to a website, there's a trusted entity (GoDaddy Certificate Issuer in the example above) vouching for the certificate that the website presents. The GoDaddy Certificate Issuer entity, for which the industry term is a Certificate Authority (CA), is the SOLE owner of the Private Key (going forward, we'll just say GoDaddy (CA)). If this Private Key is ever to be made known outside of the Certificate Authority, the entire chain of trust would be compromised.

This is because this private key is used to sign certificates, ensuring that they are authentic and issued by the trusted authority. If the private key were leaked or exposed, malicious actors could use it to issue fraudulent certificates, impersonate legitimate websites, and deceive users into thinking they are connecting to a secure site. This breach would undermine the integrity of the entire system, as the Certificate Authority (CA) would no longer be able to guarantee the authenticity of the certificates it issues.

So if these keys are so important, how do we:

  1. Make sure that these keys are secure over their entire lifecycle (creation, usage, destruction)?
  2. Reduce the blast radius if the private key ever DOES get compromised?

Securing Private Keys​

Certificate Authorities need to know that the Private Keys stored in their infrastructure cannot be seen by anybody. HSMs are usually used. The initialization phase of this specialized infrastructure and its private keys is critical to the overall trust a Certificate Authority sells, and therefore they usually follow a strict protocol called a "key ceremony". ICANN (Internet Corporation for Assigned Names and Numbers) has a fairly well documented key ceremony, if you're interested in the details.

Reducing the blast radius of compromised Private Keys​

Imagine that we use the GoDaddy (CA) to issue certificates to all our 999999999 websites (figure below). What happens if the GoDaddy's Private Key gets compromised? All of those 999999999 websites will be vulnerable to impersonation, eavesdropping, and malicious manipulation of the data exchanged between the website and it's users.

So what the Certificate Authorities do today is to create one Root Key (just another Private Key) and then use the Root Key to generate certificates (Intermediary Certificates) that can then be used to generate the certificates that websites/website owners request. And, it can be mathematically proven, that the Website Certificate, was created by the Intermediary Certificate, which was created by the Root Certificate, hence building a Chain of Trust.

And as you can see below, if the private key of the Intermediate CA 3 is compromised, only the websites that used that Intermediary to get their certificates are affected (Website 6 & Website 7). Hence the blast radius is reduced.

But how does our browser know who to trust?​

Now that we have established that certificates can be validated and a Chain of Trust can be established, the last piece of the puzzle is to make sure our browsers trust these Root CAs.

Every user agent (Chrome, Internet Explorer, Safari etc.) regardless of which device (mobile, tablets, laptops etc etc) they run on, have access to a certificate store where the Root CA and Intermediary CA Certificates are stored. On Windows, the certificates are generally stored under the Certificates - Local computer store that can be accessed by the Certificates MMC and choosing the Local Computer store. alt text

The browsers (some browsers like Firefox, use their own certificate store rather than the one provided by the operating system) access these certificate stores that contain the Root Certificate Authority (CA) certificates and their respective Intermediary CA certificates. The browsers use these CA certificates to validate and trust the websites they visit.

As you can see from the screen recording below (click to activate the recording), aqueeb.com is issued by GeoTrust Global TLS RSA4096 SHA256 2022 CA1 which in turn is issued by DigiCert Global Root CA.

GIF Preview

And if I check the Local Computer Certificate store on my Windows machine, I see that the DigiCert Global Root CA exists in my Trust Root Certification Authorities.alt text

And there you have it folks, all the pieces needed to understand

  • Why TLS Certificates are important
  • How trust is established between the browser and the website

If this helped you out, I'd love to hear about it. Drop me a message on LinkedIn. Thx!

Disclaimer: This is by no means a comprehensive overview of Public Key Infrastructure. This is a simplistic view of how trust, confidentiality and integrity is achieved for data exchanged between a website and a user. I have deliberately avoided terms like Registration Authority, Validation Authority, etc to keep this blog post as simple as possible. Again, I highly recommend reading the ISC2 CISSP Certified Information Systems Security Professional Official Study Guide Chapter 7 which dives deep into Public Key Infrastructure and all the concepts that underpin it.