How does the HTTPS protocol work?

Hi! In this article, we will explore how the HTTPS protocol works, why the HTTP protocol is considered insecure, and how HTTPS addresses the security flaws of HTTP.

Understanding the HTTP protocol

HTTP (HyperText Transfer Protocol) is the foundation of communication on the web. It allows the exchange of data between a client and a server. It enables users to fetch web pages, submit forms, or interact with online content smoothly.

By itself, HTTP is “plain text” (if someone intercepted the data, they could read everything inside it).

Understanding the HTTPS protocol

HTTPS (Hypertext Transfer Protocol Secure) provides the security layer that wraps around the HTTP data. It ensures that even if someone intercepts the data, they cannot see or change what is inside.

HTTPS is used for :

• Encryption: HTTPS encrypts the data exchanged between the client and server, keeping it private and secure from eavesdroppers.
• Authentication: it verifies the identity of the website, ensuring users are connecting to the legitimate site and not an imposter (as in the case of a man-in-the-middle attack, for example)
• Data integrity: HTTPS protects data from being tampered with during transfer, ensuring the information sent and received is not altered.

Understanding SSL and TLS protocol

To encrypt connections via the HTTPS protocol, we use the TLS protocol (Transport Layer Security), which is the direct successor to the SSL protocol (Secure Sockets Layer). Today, all versions of SSL are obsolete. However, it is common to encounter the term SSL in the description of a TLS connection. In most cases, the terms SSL and SSL/TLS both refer to the TLS protocol and TLS certificates.

Understanding what is “Encryption”

Encryption transforms data using an encryption key (like a password) and an encryption algorithm (a method for encryption). To decrypt, you need both the algorithm and the decryption key.

Symmetric encryption

Symmetric encryption uses a single secret key shared between the communicating parties.

Example

Imagine two friends, Alice and Bob, want to exchange secret messages. They decide on a single secret key, let’s say the number “1234.” Alice uses this key to encrypt her message, such as “Hello,” into something unreadable like “A7J9R”. When Bob receives the encrypted message “A7J9R”, he uses the same key, “1234”, to decrypt it back into “Hello”.

This method is fast and efficient.

However, it is essential that the two parties have previously agreed upon and exchanged the key and the used algorithm confidentially before starting the communication.

Asymmetric encryption

Principle

Asymmetric encryption relies on two keys: a private key and a public key.

1. If we encrypt a message with one key, we can decrypt the message with the other key.
2. Conversely, we can encrypt the message with the second key and decrypt it with the first key.

These two keys are mathematically linked.

Example

Imagine Alice wants to send Bob a secure message. Bob has two keys: a private key (which he keeps secret) and a public key (which he shares with everyone). Alice uses Bob’s public key to encrypt her message, turning “Hello” into an unreadable format, like “X9Z3J.” When Bob receives the encrypted message “X9Z3J,” he uses his private key to decrypt it back into “Hello.”

The public key is used for encryption, and the private key is used for decryption. Since only Bob has access to his private key, no one else can decrypt the message, even if they have Bob’s public key.

Naive example

With all the information about symmetric and asymmetric encryption, let’s imagine how we could securely exchange data:

1. The client sends a request containing:
   • The key type.
   • The encryption algorithms it supports.
   • The hashes to verify the integrity of a message.
2. The server selects the preferred options and sends its public key to the client.
3. The client creates a “pre-master password” according to the server’s preferences and encrypts it with the server’s public key. Then, the client sends it to the server.
4. The server decrypts the “pre-master password” with its private key.
5. The client and the server will use this key for symmetric encryption during the communication.

A hacker can perform a “man-in-the-middle” attack by intercepting the server’s public key sent in the first step and tricking the client into believing they are the legitimate server. The hacker then sends their own public key to the client. When the client sends its information, the hacker can decrypt it and re-encrypt it with the server’s key. Neither the client nor the server realizes anything is wrong.

Chain of trust

Simplified principle of chain of trust

Example

We have two people: A and B. A wants to access B’s website. B sends their public key to A. However, A wants to be sure that it is indeed B’s public key and not someone else’s pretending to be B.

To solve this, we introduce a third person: C. A trusts C. (C has a private key and a public key, and A knows and trusts C’s public key)

B will give their public key to C and provide proof of their identity to convince C that they are indeed B. C will create a document containing B’s website name (e.g., www.b-website.com), B’s public key, and other information such as the document’s validity date. C will sign (encrypt) this document with their private key to produce a signature that is added to the document.

Now, when A tries to connect to B’s website, B can send this document containing B’s public key. A wants to verify that B’s public key is indeed B’s: A will check the document’s signature using C’s public key. If the signature is correct, A can be sure that C has certified that B’s public key is indeed B’s. Since A trusts C, A will trust the public key sent by B.

Problematic of this simplified principle of chain of trust

There are not just one but thousands of certificate authorities worldwide. It is impossible for A to know all the certificate authorities, and this is where the concept of the “Chain of Trust” comes into play.

Let’s consider 8 actors: A1 and A2, who are clients; CA1 and CA2, who are certificate authorities; and B1, B2, B3, and B4, who are websites.

• A1 trusts CA1
• A2 trusts CA2
• B1 and B2 are certified by CA1
• B3 and B4 are certified by CA2

Since A1 does not know CA2 (and therefore does not trust it), A1 cannot connect to B3 and B4. Similarly, A2 does not know CA1, so A2 cannot connect to B1 and B2.

Complete chain of trust solution

The solution is to recognize that certificate authorities can themselves be certified. For example, let’s assume there is a higher-level certificate authority called CA. CA1 and CA2 can obtain a certificate signed by CA using the same process.

When the four websites request their certificates from their respective authorities, they receive two certificates: for example, B1 receives the certificate from CA1 and its own certificate.

Now, A1 and A2 no longer need to know CA1 and CA2; they only need to know CA. When A1 connects to B1, B1 sends both certificates (B1’s and CA1’s) to A1. A1 first verifies CA1’s certificate: since A1 trusts CA, A1 considers the certificate valid and decides to trust CA1’s public key. Then A1 looks at the second certificate and can consider it valid because A1 now trusts CA1. Therefore, A1 can trust B1’s public key.

On a larger scale, we can encounter the same problem when there are multiple higher-level certificate authorities. We solve it in the same way multiple times until the number of authorities that clients like A1 and A2 need to trust is relatively small.

This entire infrastructure is called PKI (Public Key Infrastructure). In practice, when B requests a certificate from a certificate authority, it will receive a chain of certificates (its own certificate plus the parent certificates). A can verify all the certificates one by one and trust B.

It is important to note that all trust relies on the first link in the chain. This authority is called the ROOT. The security of communications between A and B depends on the root authority, which is why the chain of trust solution is not perfect. It relies on two assumptions:

• The root authority is a trusted entity that issues certificates only after verifying identities.
• The private key of this root authority is never known by anyone else.

A small recap

Root certificate authorities

• Definition: Root certificate authorities are trusted entities that issue digital certificates. They are at the top of the certificate hierarchy.
• Role: They verify the identity of entities (like websites) and issue root certificates, which are self-signed and highly trusted.
• Trust: Root certificates are pre-installed in browsers and operating systems, forming the basis of trust for all other certificates.

To obtain a certificate, you need to request one from a certificate authority. This is a recognized and validated organization, regularly subjected to security tests, and capable of issuing certificates.

Certificates

A certificate is like an identity card for servers, containing information to verify the presenter’s identity. It includes a public key, details about the holder, certificate specifics (such as the validity date), and an electronic signature from a certification authority. This electronic signature confirms that the certificate has been verified by the certification authority, ensuring the integrity of the information. It combines the certificate information with the public key and is encrypted by the certification authority’s private key.

Intermediate Certificates

• Definition: Intermediate certificates are issued by Root CAs and act as a bridge between the root certificate and end-user certificates.
• Role: They help distribute the trust from the Root CA to the end-user certificates. This adds an extra layer of security and allows the Root CA to remain offline, reducing the risk of compromise.
• Chain of Trust: When you visit a website, your browser checks the chain of trust, starting from the end-user certificate, through the intermediate certificates, up to the root certificate.

Example using the chain of trust

This process solves the identification problem. If a hacker attempts a man-in-the-middle attack by intercepting the server’s certificate and modifying the public key, the signature will no longer be valid because it won’t match. The only way to obtain a correct signature is to have the certificate authority’s private key, which is nearly impossible.

All these steps happen instantly before the first connection, known as the handshake.

Full example

Now, we have our certificate and the intermediate certificate from our authority. Let’s redo the scenario and recap everything:

When the client wants to connect to the server, it will send a request with three elements:

1. Key type and algorithms: The client specifies the key type, the encryption algorithms it supports, and the hashes to verify the integrity of a message. The server selects its preferences and sends its public key along with the certificate received from the authority.
2. Verification: The client uses root certificates to verify the server’s certificate. If everything is correct, the client generates a “pre-master password” based on the server’s preferences and encrypts it with the server’s public key. The server decrypts it with its private key and uses this key for symmetric encryption.
3. Symmetric encryption: Now, symmetric encryption can be used! If the client wants to send login credentials, it encrypts the request information (passwords, URL, headers, etc.) with the symmetric key and sends it to the server. The server decrypts it with the same key to obtain the information. The server then generates the requested HTML/CSS/images page using Java/PHP/JavaScript, etc., encrypts it with the symmetric key, and sends it to the client. Finally, the client decrypts it with the symmetric key.

To go further

List of known certificates authorities

Here are some examples of well known certificate authorities:

• Let’s encrypt
• Google
• Cloudflare
• DigiCert
• Comodo
• Entrust

List of vulnerabilities of chain of trust

Impersonation of the server to the certificate authority

If a hacker successfully impersonates the server to the certificate authority (CA), several risks arise:

• The hacker can submit fake documents, which certificate authority might not verify rigorously.
• The hacker might bribe certificate authority to issue a fraudulent certificate.

Compromised certificate authority

If a hacker breaches a certificate authority and steals its private key, they can create valid certificates. This breach undermines the entire trust system, as the hacker can issue certificates that appear legitimate.

Case studies

In 2011, DigiNotar, a Dutch certificate authority, was hacked. The breach led to the issuance of hundreds of fake certificates, which were used for man-in-the-middle attacks on Iranian Gmail users.

DarkMatter Group, a cybersecurity company based in the UAE, has been involved in controversial activities, including surveillance and hacking. The company has faced scrutiny for its practices and the involvement of former U.S. intelligence operatives.

Check trusted certificates

But, how do we know which certificates to trust? Browsers like Firefox and Chrome maintain a list of trusted root certificates. These root certificates are pre-installed and regularly updated to ensure secure connections.

• On Firefox, you can follow these steps: https://support.mozilla.org/en-US/kb/secure-website-certificate
• On Google Chrome, you can follow this link to see the list of installed root certificates: chrome://flags/#show-cert-link

Setup our own certificates locally to test

Here is an example on how to setup our own CA and certificates with openssl command:

# Generate private CA key
CANAME=MyOrg-RootCA
openssl genrsa -aes256 -out $CANAME.key 4096

# Create certificate, 1826 days = 5 years
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt

# Or this command to autofill the questions
# openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt -subj '/CN=MyOrg Root CA/C=AT/ST=Vienna/L=Vienna/O=MyOrg'

# Linux - Tell to the client that he can trust the CA certificate
sudo cp $CANAME.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Generate certificates signin request for the server
MYCERT=myserver
openssl req -new -nodes -out $MYCERT.csr -newkey rsa:4096 -keyout $MYCERT.key -subj '/CN=My Firewall/C=AT/ST=Vienna/L=Vienna/O=MyOrg'
# create a v3 ext file for SAN properties
cat > $MYCERT.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = myserver.local
DNS.2 = myserver1.local
IP.1 = 192.168.1.1
IP.2 = 192.168.2.1
EOF


# Sign the server certificate with the CA key
openssl x509 -req -in $MYCERT.csr -CA $CANAME.crt -CAkey $CANAME.key -CAcreateserial -out $MYCERT.crt -days 730 -sha256 -extfile $MYCERT.v3.ext

JKS, P12, PEM files

JKS File

A JKS (Java KeyStore) file can be seen as a container that securely stores your private key and certificate. It’s similar to a KeePass file, which stores passwords securely. The JKS file uses a passphrase to decrypt its contents, ensuring that your private key and certificate are protected.

PKCS12 (.p12 or .pfx) File

A PKCS12 file, also known as .p12 or .pfx, serves a similar purpose as a JKS file. It is a container that holds your private key and certificate. The main difference is that JKS is specific to Java applications, while PKCS12 is supported by most non-Java applications. Like JKS, PKCS12 files can be encrypted with a password for added security.

PEM File

PEM (Privacy-Enhanced Mail) files are another format for storing keys and certificates. These files are encoded in base64 and can contain both private and public keys. PEM files are widely used and can be easily converted to other formats like PKCS12 and JKS.

Versions of TLS

TLS 1.3

As of 2026, the industry has moved almost entirely to TLS 1.3. Here is a brief summary of the implementation changes:

TLS 1.3 is more secure:

• Mandatory forward secrecy: In older versions, if a hacker somehow stole a website’s long-term private key, they could theoretically use it to decrypt all past traffic they had recorded from that site. TLS 1.3 makes “Forward secrecy” mandatory; it generates a unique, temporary key for every single session. Even if a master key is stolen later, your past data remains unreadable.
• Removal of insecure “cipher suites”: TLS 1.2 supported hundreds of ways to encrypt data, including many that are now considered broken (like the old SHA-1 or MD5 algorithms). TLS 1.3 only allows a tiny list of modern, battle-tested encryption methods. This prevents “downgrade attacks,” where hackers force a browser to use weak, breakable encryption.
• Encrypted handshake: In older versions, parts of the handshake (like the server’s identity certificate) were sent in plain text. This allowed eavesdroppers to see exactly which websites you were visiting. TLS 1.3 encrypts as much of the handshake as possible, significantly improving your privacy.

TLS 1.3 is faster:

• 1-RTT (One Round Trip Time) handshake: In TLS 1.2, your browser and the server had to talk back and forth twice to agree on how to talk securely. TLS 1.3 optimized this by having the client sends its key-exchange parameters in the initial ‘ClientHello’ message, assuming the server will support a modern cipher suite. This cuts the handshake time in half.
• 0-RTT (Zero Round-Trip Time) resumption: If you have visited a website before, TLS 1.3 allows your browser to start sending encrypted data in its very first message to the server, effectively making the secure connection start instantly.