Two Parties in Communication

The process begins with two entities: a browser and a server. Let's imagine we're using HTTP to log into GitHub with a username and password. To verify these credentials, the server needs to receive this information over the network. Initially, this data is converted into a binary format for transmission.

However, this presents a significant risk; anyone intercepting the network can easily read this binary data and revert it back to its original form, compromising your username and password. This is why relying on HTTP is risky—it's not secure!

Let's explore how to safeguard our data effectively.

Securing Our Data

To protect our information from being intercepted, we need to make it unreadable. This is achieved through a symmetric-key algorithm, where a cryptographic private key is used for both encrypting and decrypting the data.

Initially, we encrypt the data with this key and send it in binary form. Even if a malicious actor accesses this data, it would be unreadable. However, this straightforward method has a flaw: the server cannot decrypt the data because it lacks the private key. Sharing this key over the network is also not viable, as an eavesdropper could read it and decrypt the information.

So, how do we securely share our private key with the server?

The Role of Public-Private Key Cryptography

To solve this issue, we employ asymmetric cryptography. In this model, there are two keys:

• Private Key: Kept secret and known only to the owner; it's used to decrypt messages encrypted with the corresponding public key.
• Public Key: Shared openly; anyone can use this key to encrypt data, which can only be decrypted by the owner’s private key.

These keys are mathematically linked but serve different functions. Importantly, a public key cannot decrypt messages encrypted with itself.

To recap, we need to share our encrypted private key with the server. The process unfolds as follows:

1. The server sends its public key to the client upon a website request.
2. The browser uses this public key to encrypt its private key.
3. This encrypted key is sent back to the server. Even if intercepted, it remains secure due to encryption.
4. The server uses its private key to decrypt the received encrypted key.

Now both the server and the browser possess the browser's private key, allowing secure data transmission.

However, a new threat arises: if an attacker intercepts the initial exchange, they could impersonate the server and provide their public key. The browser, unaware of the deception, would encrypt its private key with the hacker's public key, allowing the hacker to decrypt it later.

So, how can we verify that the public key is legitimate and not from a rogue actor?

Introducing Certificate Authorities

Certificate Authorities (CAs) are trusted third-party entities that validate the authenticity of a server's public key. Some well-known CAs include DigiCert, Comodo SSL Store, SSL.com, and Sectigo.

CAs issue digital certificates, which contain a public key along with additional information such as:

• Issued By: The authority that issued the certificate.
• Issued To: The certificate owner (e.g., GitHub.com).
• Validity: The dates of issuance and expiration.
• Signature: The CA's private key encrypts the public key of the certificate owner.

Websites must undergo a verification process to obtain these certificates.

CAs also possess their own public and private keys. Most browsers are pre-installed with the public keys of several popular CAs. When a server sends its public key to a CA for signing, it receives a digital certificate in return. This certificate contains the server's public key, its signature, and other details.

When a browser requests a connection, it checks the certificate to identify the CA. If the CA's public key is not already installed, the browser requests it. The browser decrypts the signature using the CA's public key to extract the server's public key. If the decrypted key matches the one provided by the server, the connection can proceed securely.

This entire process showcases how various components work together to enable safe online communication.

Understanding HTTPS

Before diving into HTTPS, it's essential to clarify two key terms:

• SSL/TLS (Secure Sockets Layer/Transport Layer Security): Cryptographic protocols that establish secure communication between a client and a server.
• SSL/TLS Certificates: Digital certificates that verify the identity of a website or server and facilitate secure connections.

In essence, SSL/TLS forms the backbone of secure communication, while SSL/TLS certificates authenticate websites and enable encryption.

Thus, HTTPS represents a secure version of HTTP, utilizing SSL/TLS for communication. When a website's URL begins with HTTPS, it indicates that all data exchanged between the browser and server is encrypted via SSL/TLS certificates.

The Importance of the Chain of Trust

In practice, a web server usually has a certificate issued by a chain of certificate authorities rather than a single CA. This approach mitigates risks associated with compromised CA private keys.

The server certificate is generally signed by an intermediate CA, which may also be signed by another intermediate authority or the root certificate. The verification process occurs in reverse.

• Root Certificate: A foundational digital certificate preloaded in most browsers, closely guarded by CAs.
• Intermediate Certificate: Acts as a mediator between root and server certificates.
• Server Certificate: Issued to a specific website.

For instance, if you inspect GitHub's certificate in a browser, you'll find that Sectigo is the intermediate authority, while UserTrust ECC serves as the root authority.

In conclusion, we've delved into the intricate workings of HTTPS. Understanding these concepts is vital for developers aiming to create secure applications. Thank you for taking the time to read this article; I hope you gained valuable insights.

Want to Connect? LinkedIn

P.S.: If you enjoyed this reading experience, consider supporting writers on Medium.com by signing up for a membership. Your support makes a difference!

A clap would be greatly appreciated if you found this article helpful. If you didn’t, feel free to share your thoughts!

The first video explores how HTTPS functions, covering topics like Certificate Authorities and self-signed certificates.

The second video compares HTTP and HTTPS, detailing how SSL/TLS encryption operates.