How does HTTPS work? What's a CA? What's a self-signed Certificate?

This article aims to demystify HTTPS, a cornerstone of secure internet communication, often perceived as overly complex. It breaks down the fundamental principles of public key cryptography and digital signatures, which are the bedrock of HTTPS. The explanation simplifies how your browser establishes a secure connection with a website like YouTube, involving the exchange and validation of certificates signed by trusted Certificate Authorities (CAs). Furthermore, it delves into the role of CAs in ensuring the authenticity of websites and preventing man-in-the-middle attacks. Finally, the article clarifies the concept of self-signed certificates, highlighting their utility in controlled environments like testing or staging, where the overhead of obtaining a CA-signed certificate might not be necessary. This simplified approach is designed to help developers and anyone interested in web security understand the practical aspects of HTTPS implementation without getting bogged down in intricate mathematical details.

Public Key Cryptography and Signatures

The foundation of HTTPS relies on two core concepts: public key cryptography and digital signatures. While these might sound computationally intensive, their underlying principles are straightforward.

Public Key Cryptography

In public key cryptography, there are two distinct keys: a public key and a private key. The public key, as its name suggests, is openly distributed and accessible to anyone. Conversely, the private key is kept confidential and known only to its owner. The fundamental principle is that any message encrypted with someone's public key can only be decrypted with their corresponding private key. This ensures confidentiality because even if an attacker intercepts the encrypted message, they cannot decrypt it without the private key.

any message that has been encrypted with bob's public key and bob's public key is public it's out there for everyone can only be decrypted with bob's private key so basically that means only bob because he's the only owner of his private key can decrypt this message even though it can be publicly distributed and everyone can listen to it but no one can do anything with it because they just see some random bytes

Digital Signatures

Digital signatures, on the other hand, ensure data authenticity and integrity. Anyone with access to a sender's public key can verify that a message was indeed created by someone with access to the sender's private key. This means that if Alice signs a message with her private key, anyone with Alice's public key can verify that the message originated from Alice and has not been tampered with. This is crucial for establishing trust in online communications.

anyone who has access to alice's public key can verify that a message could only have been created by someone with access to alice's private key so basically this means anyone on the internet even though they don't know alice's private key only alice knows her private key can verify that a message was actually sent by alice

How HTTPS Works

When you connect to a website using HTTPS, a series of steps occur to establish a secure communication channel. Let's take the example of accessing YouTube.com.

First, your browser initiates a request to YouTube.com. In response, the YouTube server sends its certificate, which contains its public key. Crucially, this certificate is signed by a trusted Certificate Authority (CA), in this case, the Google Certificate Authority.

Your browser, which has a pre-installed list of trusted CAs and their public keys, then verifies the digital signature on the certificate. If the signature is valid, your browser trusts that the certificate truly belongs to YouTube and that the public key contained within it is authentic.

Once the certificate is validated, your browser generates a new, random secret key, often called a session key. This session key is then encrypted using YouTube's public key, which was obtained from the validated certificate. Since only YouTube possesses the corresponding private key, only the YouTube server can decrypt this session key.

your browser then says hey youtube.com i trust the google certificate authority and it looks like you are indeed who you say you are because i trust you i have created a new secret key and i have encrypted this key with your public key so remember if you encrypt something with a public key only the owner of a private key can encrypt it so youtube.com then says hey browser smart choice only i have my private key so only i can decrypt this so now i have this new secret that you just randomly created as well so then both parties realize we're the only two machines on the entire internet who know this new secret key so from now on let's encrypt all of our communication with this new key

After YouTube successfully decrypts the session key, both your browser and the YouTube server now possess the same secret key. From this point onward, all communication between your browser and YouTube is encrypted using this shared secret key through symmetric encryption. This ensures that even if an attacker intercepts the ongoing communication, they cannot decipher the content because they do not have access to the shared secret key. This entire process occurs seamlessly in the background, providing a secure browsing experience without any user intervention.

Certificate Authority (CA) and Certificate Signing

A Certificate Authority (CA) plays a pivotal role in the HTTPS security model. Its primary function is to verify the identity of websites and bind that identity to a public key through a digital certificate. This process helps ensure that you are indeed communicating with the legitimate website you intend to, and not an imposter.

To obtain a signed certificate, a web server like YouTube.com first generates its own public and private key pair. Then, it creates a Certificate Signing Request (CSR), which contains its public key and identifying information (like the domain name). This CSR is then sent to a trusted CA, such as the Google Certificate Authority.

The CA, possessing its own unique private and public key pair, verifies the information provided in the CSR. If satisfied with the identity of the requester, the CA signs the certificate using its private key. This signed certificate is then returned to the web server.

the google certificate authority which is considered a trusted certificate authority on the internet as any party involved in public key cryptography the google certificate authority has a private key and a public key now if the web server running youtube.com also wants to take part in https encrypted communication they also have to create such a new key pair and everyone can create a key pair next up a person or a machine running this youtube.com web server creates a so-called certificate signing request so this is a request that the youtube.com web server creates which is made from their key pair and basically it requests the known authority to sign the certificate

Most browsers come pre-loaded with a list of publicly trusted root certificates, which belong to well-known CAs like Google, Let's Encrypt, etc. When your browser receives a certificate from a website, it checks if the certificate was signed by one of these trusted CAs. By verifying the CA's signature using the CA's public key (which is already trusted by your browser), your browser can confirm that the website's public key is legitimate and that the website is indeed who it claims to be. This entire mechanism effectively prevents Man-in-the-Middle (MitM) attacks, where an attacker might try to impersonate a legitimate website.

Self-Signed Certificates

While certificates signed by well-known CAs are essential for public-facing websites, there are scenarios where self-signed certificates are perfectly acceptable and even preferred. These are typically used in controlled environments, such as development, staging, or internal testing.

A self-signed certificate is one that is signed by its own creator rather than a third-party Certificate Authority. This means that instead of sending a Certificate Signing Request to Google CA, you effectively act as your own CA. You generate your web server's public and private key pair, and then you use your own private key (acting as the CA's private key) to sign the certificate.

The process for generating a self-signed certificate is similar to obtaining a CA-signed one: you create a key pair and then a Certificate Signing Request. The key difference is who signs the request.

Sometimes it might not be necessary to have well-known authorities such as the google certificate authority sign your request let's imagine you have your own app and it's currently deployed to your staging environment where you want to do some testing so if you say i now also want to encrypt all the communication with this app you have to create a private key and a public key so the next step would now be to create a signing request but who will sign this if there is no certificate authority so in this case you can create a second pair of keys and basically by having this set of keys you've just created your very own certificate authority

When a browser or client application encounters a self-signed certificate, it will typically issue a warning because the certificate's signer is not in its list of trusted CAs. However, in a controlled environment, you can explicitly configure your applications or systems to trust your self-created CA. This allows you to leverage the benefits of HTTPS encryption for testing purposes without incurring the cost or effort of obtaining a certificate from a commercial CA. This is particularly useful for internal microservices or applications that are not exposed to the public internet, where the primary concern is secure communication within your own infrastructure rather than universal public trust.

Takeaways

HTTPS Fundamentals: HTTPS relies on public key cryptography and digital signatures to establish secure communication. Public key cryptography ensures confidentiality, while digital signatures guarantee authenticity and integrity.
Secure Connection Establishment: When connecting to an HTTPS website, the browser requests a certificate containing the server's public key. This certificate is validated by checking its digital signature against a list of trusted Certificate Authorities (CAs).
Certificate Authority's Role: A CA acts as a trusted third party that verifies the identity of a website and signs its certificate using its private key. This signature allows browsers to trust that the website's public key is legitimate, preventing Man-in-the-Middle attacks.
Self-Signed Certificates: Self-signed certificates are created and signed by their own generator, rather than a well-known CA. They are suitable for controlled environments like testing or staging environments where explicit trust can be configured, avoiding the need for external CA services.