Explain how HTTPS work by telling a story

Last updated Feb 26, 2023

• Networking

Once upon a time, there was a young woman named Alice who wanted to buy a new dress online. She went to her favorite online store, which was called “Dress Haven,” and began browsing through the selection. When she found a dress she liked, she clicked on the “Add to Cart” button, which took her to the checkout page.

At this point, Alice was asked to enter her personal and financial information, such as her name, address, and credit card number. Alice was a bit nervous about entering this information online because she had heard that hackers could intercept it and steal her identity.

But luckily, Dress Haven had implemented HTTPS on their website, which meant that Alice’s information would be encrypted and secure as it traveled from her computer to Dress Haven’s servers. HTTPS stands for Hypertext Transfer Protocol Secure, and it’s a protocol that encrypts the data being transmitted between a user’s computer and a website’s server.

When Alice entered her information into the checkout page and clicked “Submit,” her browser used HTTPS to encrypt the data and send it to Dress Haven’s servers. This made it much more difficult for hackers to intercept and read the data.

Dress Haven’s servers then decrypted the data and processed Alice’s payment. Once the transaction was complete, Dress Haven sent a confirmation page back to Alice’s browser using HTTPS again, so that the confirmation page was also encrypted.

Alice was relieved to know that her information was safe and secure thanks to HTTPS, and she completed her purchase with confidence. She was able to enjoy her new dress knowing that her personal and financial information had been protected.

And so, thanks to HTTPS, Alice was able to shop online without worrying about hackers stealing her identity. The end.

Great question! When Alice’s encrypted data arrived at Dress Haven’s servers, the servers used a private key to decrypt the data. The private key is a secret key that is kept by the website owner and used to decrypt the data that has been encrypted using a public key.

The public key is provided to the user’s browser when they access the website, and it is used to encrypt the data before it is sent to the website’s servers. Only the website’s servers, with access to the private key, can decrypt the data.

Once Dress Haven’s servers decrypted Alice’s data using their private key, they were able to read and process her payment information. The servers then used a secure payment gateway to transmit the payment information to Alice’s bank for authorization.

The payment gateway is a secure service that acts as a middleman between the website and the bank. It ensures that the payment information is encrypted and transmitted securely between the two parties.

Once the bank authorized the payment, the payment gateway transmitted the confirmation back to Dress Haven’s servers using HTTPS. Dress Haven’s servers then sent the confirmation page to Alice’s browser, again using HTTPS to ensure the page was encrypted and secure.

In summary, Dress Haven’s servers were able to decrypt Alice’s payment information using their private key, process the payment using a secure payment gateway, and transmit the confirmation back to Alice’s browser using HTTPS. This entire process ensures that Alice’s payment information is kept secure and protected from unauthorized access.

That’s correct! When Dress Haven’s servers sent the confirmation page back to Alice’s browser, they did not need to encrypt the data because the encryption had already been done by Alice’s browser when she sent the original request.

When Alice’s browser initially requested the checkout page from Dress Haven’s servers, it used HTTPS to encrypt the request, so that no one could intercept or tamper with the data being transmitted.

Dress Haven’s servers then processed the request and sent the response back to Alice’s browser. Since Alice’s browser was already using HTTPS, it was able to decrypt the response and display it to her without any additional encryption needed.

So, in summary, Dress Haven’s servers did not need to encrypt the confirmation page before sending it back to Alice’s browser because the encryption had already been done by Alice’s browser when she sent the initial request using HTTPS.

Alice’s browser can verify that the public key provided by the website is indeed generated by the website’s private key using a process called “SSL/TLS Handshake”.

When Alice first connects to Dress Haven’s website using HTTPS, her browser initiates an SSL/TLS handshake process with the website’s server. During the handshake process, the website’s server sends its digital certificate, public key included, to Alice’s browser.

Alice’s browser then checks the website’s digital certificate, which is a file that contains the website’s public key, and is signed by a trusted third-party called a “Certificate Authority” (CA). The digital certificate is used to verify that the public key being used by the website belongs to the website, and has not been tampered with by an attacker.

If Alice’s browser recognizes the CA that signed the digital certificate as a trusted authority, it will use the CA’s public key to verify the signature on the digital certificate. If the signature is valid, Alice’s browser will trust that the public key provided by the website does indeed belong to Dress Haven.

Once Alice’s browser has verified the website’s digital certificate and public key, it will use the website’s public key to encrypt the data that it sends to the website’s server, as we discussed earlier.

In summary, Alice’s browser uses SSL/TLS handshake process to verify the website’s digital certificate, which is signed by a trusted Certificate Authority, and to verify that the public key provided by the website belongs to the website. This ensures that Alice’s browser is communicating securely with Dress Haven’s website, and that her data is protected from interception or tampering by attackers.

When Alice’s browser receives the digital certificate from Dress Haven’s website during the SSL/TLS handshake process, it checks the authenticity of the digital certificate by verifying the digital signature of the Certificate Authority (CA) that issued the certificate.

Here’s how it works:

1. Alice’s browser has a list of trusted CAs that it trusts to issue digital certificates. These trusted CAs are typically included in the browser’s pre-installed list of trusted root certificates.

2. When Alice’s browser receives the digital certificate from Dress Haven’s website, it checks to see which CA issued the certificate.

3. Alice’s browser then retrieves the CA’s public key from its list of trusted root certificates.

4. Alice’s browser uses the CA’s public key to verify the digital signature on the digital certificate. If the digital signature is valid, this confirms that the digital certificate has not been tampered with, and that the website it represents is legitimate.

5. Alice’s browser then checks to see if the website name in the digital certificate matches the website that she is trying to access. If the website name does not match, this could indicate a phishing attack, and Alice’s browser will display a warning to inform her.

If Alice’s browser is unable to verify the digital signature on the digital certificate, or if the website name does not match, it will display a warning to inform Alice that the website’s identity could not be verified, and that the connection may not be secure.

In summary, Alice’s browser verifies the authenticity of the digital certificate by checking the digital signature of the CA that issued the certificate, and by ensuring that the website name in the certificate matches the website she is trying to access. This process ensures that Alice’s browser can trust that she is communicating securely with Dress Haven’s website.

How does HTTPS work?