What Is HTTPS?

HTTPS stands for HyperText Transfer Protocol Secure. It is the encrypted version of HTTP, the protocol your browser uses to communicate with websites. When you visit a site over HTTPS, all data exchanged between your browser and the server is encrypted, preventing anyone on the network from reading or tampering with it.

Without HTTPS, everything you send and receive travels in plain text. This includes passwords, credit card numbers, personal messages, and even the pages you view. Anyone on the same network -- whether a coffee shop Wi-Fi operator, your ISP, or a malicious actor performing a man-in-the-middle attack -- can intercept and read this data.

You can tell a site is using HTTPS by looking at the URL bar. The address will start with https:// and most browsers display a padlock icon next to it. Clicking the padlock shows certificate details, including who issued it and when it expires.

The TLS Handshake Process

Before any encrypted data can flow, your browser and the server must agree on how to encrypt the connection. This negotiation is called the TLS handshake. It happens in milliseconds, completely behind the scenes, every time you connect to an HTTPS site.

Step-by-Step Handshake (TLS 1.3)

Modern browsers use TLS 1.3, which streamlined the handshake to just one round trip:

The entire handshake in TLS 1.3 completes in a single round trip (1-RTT), compared to two round trips in TLS 1.2. This makes HTTPS connections faster than ever before.

Certificate Authorities

When a server presents its TLS certificate during the handshake, your browser needs to verify that the certificate is legitimate. This is where Certificate Authorities (CAs) come in.

A Certificate Authority is a trusted organization that verifies the identity of website owners and issues digital certificates. Your operating system and browser ship with a pre-installed list of trusted CAs -- called the trust store. When a server presents a certificate signed by one of these CAs, your browser trusts it automatically.

The Chain of Trust

Certificates form a chain:

• Root CA Certificate -- Pre-installed in your OS/browser trust store. These are the ultimate anchors of trust. Examples include DigiCert, Let's Encrypt (ISRG Root), and GlobalSign.
• Intermediate CA Certificate -- Signed by the root CA. Most website certificates are issued by intermediate CAs, not directly by root CAs. This limits exposure if an intermediate key is compromised.
• Server Certificate -- The certificate presented by the website, signed by the intermediate CA. Contains the site's domain name, public key, validity dates, and the issuer's signature.

Your browser walks up this chain: it verifies the server certificate was signed by a valid intermediate, that the intermediate was signed by a trusted root, and that none of the certificates have expired or been revoked.

Symmetric vs. Asymmetric Encryption

HTTPS uses both types of encryption, each for a different purpose. Understanding why requires knowing their strengths and weaknesses.

Asymmetric Encryption (Public Key Cryptography)

Asymmetric encryption uses a pair of keys: a public key that anyone can have, and a private key that only the owner keeps secret. Data encrypted with the public key can only be decrypted with the private key, and vice versa.

This solves the key distribution problem -- you can share your public key openly without compromising security. However, asymmetric encryption is computationally expensive and slow, making it impractical for encrypting large amounts of data.

Symmetric Encryption

Symmetric encryption uses a single shared key for both encryption and decryption. It is vastly faster than asymmetric encryption -- typically 100 to 1,000 times faster. The problem is that both sides need to have the same key, and you cannot safely send a key over an insecure channel.

How HTTPS Combines Both

HTTPS uses asymmetric encryption during the TLS handshake to securely establish a shared session key. Once both sides have the session key, all subsequent communication uses fast symmetric encryption. This gives you the best of both worlds: secure key exchange plus fast bulk encryption.

# Common cipher suite in TLS 1.3:
TLS_AES_256_GCM_SHA384

# Breakdown:
# AES_256_GCM  = Symmetric encryption (fast, for data)
# SHA384       = Hash function (for integrity verification)
# Key exchange = X25519 or P-256 (Diffie-Hellman, asymmetric)

How to Verify HTTPS

Knowing how to check a website's HTTPS configuration helps you assess whether your connection is truly secure. Here are practical methods anyone can use.

In Your Browser

Click the padlock icon in your browser's address bar to view:

• Whether the connection is secure
• The certificate issuer (CA)
• The certificate's validity dates
• The domain names the certificate covers

Using Command-Line Tools

For deeper inspection, use openssl from the terminal:

# View a site's certificate details
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -text

# Check certificate expiration date
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

# Check the TLS version and cipher suite
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -E "Protocol|Cipher"

Online Tools

Services like SSL Labs (ssllabs.com/ssltest) provide a detailed report grading a website's TLS configuration from A+ to F. They check for outdated protocols, weak ciphers, certificate chain issues, and known vulnerabilities.

Mixed Content Issues

Mixed content occurs when an HTTPS page loads some resources (images, scripts, stylesheets) over plain HTTP. This is a security problem because those HTTP resources can be intercepted and modified by an attacker, potentially compromising the entire page.

Types of Mixed Content

• Passive mixed content -- Resources like images, audio, and video loaded over HTTP. Lower risk because they cannot directly execute code, but an attacker could swap an image to display misleading information.
• Active mixed content -- Scripts, stylesheets, iframes, and other resources that can execute code or change the page structure. Modern browsers block active mixed content entirely because the risk is too high.

Fixing Mixed Content

<!-- Bad: loading over HTTP -->
<img src="http://example.com/image.png">
<script src="http://cdn.example.com/lib.js"></script>

<!-- Good: loading over HTTPS -->
<img src="https://example.com/image.png">
<script src="https://cdn.example.com/lib.js"></script>

<!-- Also good: protocol-relative (inherits page protocol) -->
<img src="//example.com/image.png">

You can also use the Content-Security-Policy header to enforce HTTPS for all resources:

Content-Security-Policy: upgrade-insecure-requests;

This header tells the browser to automatically upgrade any HTTP resource requests to HTTPS before sending them, eliminating mixed content without changing your HTML.

HSTS: HTTP Strict Transport Security

Even if your site supports HTTPS, a user might type http://yoursite.com or click an old HTTP link. During that brief HTTP request before the redirect to HTTPS, an attacker could intercept the connection. This is called an SSL stripping attack.

HSTS solves this. It is a response header that tells the browser: "For the next N seconds, never connect to this domain over plain HTTP. Always use HTTPS, even if the user types http:// or clicks an HTTP link."

# HSTS header example
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# Breakdown:
# max-age=31536000    -- Remember this policy for 1 year (in seconds)
# includeSubDomains   -- Apply to all subdomains too
# preload             -- Eligible for browser preload lists

After the browser receives an HSTS header, it stores the policy locally. For the duration specified by max-age, any attempt to connect over HTTP is automatically converted to HTTPS on the client side, before any network request is made. This completely eliminates the window of vulnerability that SSL stripping attacks exploit.

Summary

HTTPS is the foundation of secure communication on the web. Here is what you learned:

• HTTPS encrypts all traffic between your browser and the server, preventing eavesdropping and tampering
• The TLS handshake negotiates encryption parameters and establishes a shared session key in a single round trip (TLS 1.3)
• Certificate Authorities verify website identity through a chain of trust from root CAs to server certificates
• HTTPS combines asymmetric encryption (for secure key exchange) with symmetric encryption (for fast data transfer)
• You can verify HTTPS using browser tools, openssl commands, or online services like SSL Labs
• Mixed content weakens HTTPS pages and should be eliminated by loading all resources over HTTPS
• HSTS prevents SSL stripping attacks by forcing browsers to always use HTTPS