Phase 1: Foundations

HTTP/HTTPS protocols, TLS handshakes & certificates

Beginner ~1 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you want to send a message to a friend across town. If you write your message on a plain postcard and send it, anyone who handles it along the way – the post office workers, the delivery person – can read what you've written. This is a bit like how websites used to send information using something called HTTP (Hypertext Transfer Protocol). When your computer asks a website for information (like loading a picture or a story), it sends a request, and the website sends back the answer. With HTTP, all that information travels like an open postcard, which means if someone sneaky was trying to peek, they could easily read your messages, especially if you were sending something private like your name or address.

To keep things secret, we use HTTPS (Hypertext Transfer Protocol Secure), which is like sending a sealed envelope with a special lock and key. Before you put your secret message inside, you and your friend have to do a quick, secret dance called a TLS (Transport Layer Security) handshake. It's like you both quickly agree on a super-secret, unique lock and key design that only you two know. But how do you know you’re talking to your actual friend and not someone pretending to be them? This is where a certificate comes in. Your friend has a special ID card, like a verified permission slip from a trustworthy organization, that proves they are who they say they are. You check this certificate, make sure it’s real, and then you feel safe to agree on the secret lock and key.

Once you both have your secret lock and key, you put your message in the special envelope, lock it, and send it. Even if someone intercepts it, they can't open it because they don't have your secret key. Only your friend, with their matching key, can unlock and read the message. This means when you’re shopping online or logging into a game, HTTPS makes sure your passwords, credit card numbers, and other personal information travel securely. Your computer and the website are constantly using these secret keys to scramble and unscramble all the messages, keeping them safe from prying eyes.

So, next time you see "HTTPS" or a little padlock icon in your web browser, you'll know that your computer is having a secret, locked conversation with that website. This understanding is really important for building safe and reliable online tools. When you start creating your own websites or apps, knowing about these secure 'mail systems' means you can design them so that your users' information is always kept private, just like sending a secret message only your friend can read.

At its core, HTTP (Hypertext Transfer Protocol) is the foundation of data communication for the web. When your browser requests a webpage, it uses HTTP to send a request to a server, which then sends back a response containing the page content. However, HTTP transmits data in plain text, making it vulnerable to eavesdropping and tampering. This is where HTTPS (HTTP Secure) comes in. HTTPS encrypts the communication between your browser and the server, protecting sensitive information like login credentials or payment details. Think of HTTP as sending a postcard, and HTTPS as sending a sealed, locked letter.

Key Takeaways

  • HTTP is for unencrypted web communication, HTTPS uses TLS to encrypt it.
  • The TLS Handshake establishes a secure, encrypted connection between client and server.
  • TLS Certificates verify the server's identity and contain the public key needed for encryption.
  • SREs are responsible for managing, renewing, and troubleshooting TLS certificates to maintain application security and availability.

Code Example

bash
# Check the TLS certificate details for a website (e.g., google.com)
openssl s_client -connect google.com:443 < /dev/null | openssl x509 -noout -subject -dates

How this code works

This code snippet's job is to connect to a web server securely, mimicking how a browser visits a website using HTTPS, and then extract specific details from the server's digital certificate. The first part, openssl s_client -connect google.com:443, initiates an SSL/TLS connection to google.com on the standard HTTPS port 443. During this connection, the server sends its TLS certificate as part of the handshake. A crucial, subtle detail is < /dev/null, which feeds an empty input stream to s_client. This prevents the command from waiting for additional user input after the initial handshake, ensuring it promptly completes the connection and outputs the certificate information received from the server.

The | (pipe) then takes all the output from the s_client command, including the certificate data, and feeds it directly as input to the next command, openssl x509. This second openssl utility is specifically designed to parse and interpret X.509 digital certificates. The -noout option tells x509 not to print the entire certificate again in its raw format. Instead, the -subject and -dates options precisely instruct it to display only the certificate's subject, identifying who the certificate was issued to, and its validity period, indicating when it becomes active and when it expires.