HTTP Strict Transport Security (HSTS) & Certificate Transparency

While obtaining an SSL/TLS certificate is the first step toward securing your web traffic, simply having a certificate does not prevent users from accessing your site over insecure connections.

To force secure connections and protect against certificate spoofing, you must implement HTTP Strict Transport Security (HSTS) and monitor Certificate Transparency (CT) logs.

The Problem: SSL Stripping Attacks

Even if your web server redirects http://example.com to https://example.com, the very first request is still made over unencrypted HTTP. During this initial connection, an attacker on the same network can intercept the request and perform an SSL Stripping attack:

1. The user types example.com or clicks an HTTP link.
2. The user’s browser sends an insecure HTTP request.
3. The attacker intercepts the request and forwards it to the secure site (https://example.com) on behalf of the user.
4. The attacker returns the secure page’s contents back to the user over plain HTTP.
5. The user is now communicating insecurely, while the attacker reads and modifies all data in real time.

sequenceDiagram
    participant U as User (Browser)
    participant A as Attacker (On-Path)
    participant S as Secure Server
    
    U->>A: GET http://example.com (Insecure)
    Note right of U: User types example.com
    Note over A: Attacker intercepts<br/>the insecure request
    A->>S: GET https://example.com (Secure)
    S-->>A: 200 OK (Secure HTTPS response)
    Note over A: Attacker reads/modifies<br/>the sensitive data
    A-->>U: 200 OK (Insecure HTTP response)
    Note over U, A: User thinks they are browsing safely,<br/>but data is sent in plaintext!

The Solution: HTTP Strict Transport Security (HSTS)

HSTS is an HTTP response header that instructs browsers to never load the site over HTTP. Once a browser receives this header, it automatically converts all future attempts to access the site via HTTP into secure HTTPS requests locally, before any network packets are transmitted.

The HSTS Header Directives

A secure HSTS header looks like this:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age: The duration (in seconds) that the browser should remember to enforce HTTPS. 63072000 seconds represents 2 years (minimum recommended for production is 1 year / 31536000 seconds).
• includeSubDomains: Enforces the same rule for all subdomains of the site (e.g. api.example.com and staging.example.com).
• preload: Confirms your consent to submit your domain to the global HSTS Preload List, maintained by Google and compiled directly into Chrome, Firefox, Safari, and Edge.

HSTS Preloading

To eliminate the vulnerable “first HTTP request” window entirely, you can apply to have your domain hardcoded into web browsers via the HSTS Preload list:

1. Configure your HSTS header with a max-age of at least 1 year (31536000s), include subdomains, and append the preload token.
2. Ensure you have an active redirect from HTTP to HTTPS on the root domain, including all subdomains.
3. Submit your domain at hstspreload.org.

Once accepted, browsers will contact your site over HTTPS even on the very first visit.

Certificate Transparency (CT)

HSTS forces browsers to connect via HTTPS, but how do they know the certificate they are receiving is legitimate and not a counterfeit issued by a compromised or rogue Certificate Authority?

Certificate Transparency (CT) is a framework of public, append-only cryptographic logs that record all SSL/TLS certificates issued by CAs in real time.

Why Certificate Transparency is Critical

CT logs make it impossible for a Certificate Authority to issue a certificate for a domain secretly. Anyone can query CT logs to see every certificate issued for their domain.

If a rogue CA issues a fake certificate for yourdomain.com (for example, to perform government espionage or a DNS hijack), it will immediately appear in the public CT logs. Security teams can detect this anomaly and revoke the fraudulent certificate before it is exploited in the wild.

Sources & Standards

• IETF RFC 6797: HTTP Strict Transport Security (HSTS) - The official specification defining HSTS response header behavior and browser enforcement.
• IETF RFC 6962: Certificate Transparency - Describes the architecture of append-only CT logs, monitoring mechanisms, and audit paths.
• HSTS Preload Submission: hstspreload.org - The global service maintained by Google to preload domains into browsers.