HTTPS: HTTP over TLS

Introduction

HTTPS (Hypertext Transfer Protocol Secure) is the encrypted version of HTTP, the foundational protocol used to transfer data between a web browser and a website. HTTPS uses TLS (Transport Layer Security) -- formerly known as SSL -- to encrypt all communication between the client and server, providing three critical security properties: confidentiality, integrity, and authentication.

Without HTTPS, all data transmitted between a browser and a web server travels in plaintext. Anyone with access to the network path -- an attacker on a public Wi-Fi network, a compromised router, or a malicious ISP -- can read, modify, or inject content into the communication. This includes passwords, credit card numbers, session cookies, and personal information.

As of 2025, over 95% of web traffic uses HTTPS. Major browsers now mark HTTP sites as "Not Secure," and search engines give ranking preference to HTTPS-enabled sites. The transition from optional security feature to baseline requirement represents one of the most significant shifts in web security history.

"HTTPS is no longer optional. It is the baseline expectation for any website, not just those handling sensitive data." -- Troy Hunt, security researcher and creator of Have I Been Pwned

How HTTPS Works

HTTPS is not a separate protocol from HTTP. It is standard HTTP sent over an encrypted TLS connection. The URL scheme changes from http:// to https://, and the default port changes from 80 to 443. All HTTP headers, request bodies, response bodies, and cookies are encrypted before transmission.

The TLS Handshake

Before any application data is exchanged, the client and server must establish a TLS connection through a process called the TLS handshake. The modern TLS 1.3 handshake requires only one round trip (1-RTT), a significant improvement over TLS 1.2's two round trips.

TLS 1.3 Handshake Steps:

1. Client Hello: The client sends supported cipher suites, its key share (typically an ECDHE public key using X25519 or P-256), and supported TLS versions
2. Server Hello: The server selects the cipher suite, sends its key share, its certificate, and a certificate verify message (all encrypted after the key share)
3. Finished: Both sides derive the session keys from the shared ECDHE secret and begin encrypted communication

TLS 1.3 also supports 0-RTT resumption, where a client that has previously connected to a server can send encrypted application data in the very first message. However, 0-RTT data is vulnerable to replay attacks and should only be used for idempotent requests.

TLS Versions

TLS 1.3 removed numerous legacy features that had been sources of vulnerabilities: RSA key exchange (no forward secrecy), CBC mode ciphers, SHA-1, MD5, static Diffie-Hellman, and renegotiation. The only key exchange mechanism in TLS 1.3 is ephemeral Diffie-Hellman (ECDHE or DHE), ensuring perfect forward secrecy for every connection.

Certificate Validation

HTTPS authentication relies on X.509 digital certificates issued by trusted Certificate Authorities (CAs). When a browser connects to an HTTPS site, the server presents its certificate, and the browser validates it through a series of checks.

Certificate Chain of Trust

Certificate validation follows a hierarchical chain of trust:

1. Root CA Certificate: Self-signed certificate pre-installed in the operating system or browser trust store. Root CAs are the anchors of trust.
2. Intermediate CA Certificate: Signed by the root CA. Intermediate CAs issue end-entity certificates, keeping root CA private keys offline for security.
3. End-Entity Certificate: The server's certificate, signed by an intermediate CA. Contains the server's public key and domain name.

The browser validates the entire chain from the end-entity certificate up to a trusted root. It checks that each certificate is signed by the next certificate in the chain, that no certificate has expired or been revoked, and that the domain name matches.

Certificate Types

Let's Encrypt, launched in 2016, revolutionized HTTPS adoption by providing free, automated DV certificates. By 2025, Let's Encrypt had issued over 4 billion certificates, removing cost as a barrier to HTTPS deployment.

Certificate Transparency

Certificate Transparency (CT) is a framework designed to detect misissued or fraudulently obtained certificates. Proposed by Google engineers Ben Laurie and Adam Langley in 2013 (RFC 6962), CT requires Certificate Authorities to submit every issued certificate to publicly auditable, append-only CT logs.

The system works through three components:

• CT Logs: Cryptographically append-only log servers that record every issued certificate. Anyone can query these logs.
• Monitors: Services that watch CT logs for suspicious or unauthorized certificates for specific domains.
• Auditors: Verify that CT logs are behaving correctly and that certificates are properly logged.

Since April 2018, Google Chrome requires all newly issued certificates to include Signed Certificate Timestamps (SCTs) proving they have been logged in at least two CT logs. Certificates without SCTs are rejected as untrusted. CT has successfully detected numerous misissued certificates, including incidents involving Symantec, WoSign, and other CAs.

HTTP Strict Transport Security

HSTS (HTTP Strict Transport Security), defined in RFC 6797, is a security mechanism that forces browsers to communicate with a website exclusively over HTTPS. Once a browser receives an HSTS header, it will automatically convert any HTTP requests to HTTPS before sending them, eliminating the window of vulnerability during the initial HTTP-to-HTTPS redirect.

HSTS Header Example:

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

• max-age: Duration in seconds the browser should remember the HSTS policy (31536000 = 1 year)
• includeSubDomains: Applies the policy to all subdomains
• preload: Indicates the domain should be included in the browser's built-in HSTS preload list

The HSTS Preload List is a list of domains hardcoded into browsers that are only accessible via HTTPS. Sites on the preload list are protected from the very first connection -- the browser never attempts an HTTP connection at all. This defeats SSL stripping attacks where an attacker intercepts the initial HTTP connection before the redirect to HTTPS.

"HSTS is the single most important HTTP security header. Without it, the first connection to any HTTPS site is vulnerable to downgrade attacks." -- Scott Helme, security researcher

Mixed Content

Mixed content occurs when an HTTPS page loads sub-resources (images, scripts, stylesheets, iframes) over insecure HTTP. This undermines the security guarantees of HTTPS because those sub-resources can be intercepted and modified by an attacker.

Browsers classify mixed content into two categories:

Modern browsers now auto-upgrade mixed content by attempting to load HTTP sub-resources over HTTPS instead. If the HTTPS version is unavailable, the resource is blocked. Developers should audit their sites for mixed content issues and ensure all resources use HTTPS or protocol-relative URLs.

Performance Considerations

A common misconception is that HTTPS significantly degrades performance. While there is overhead from the TLS handshake and encryption, modern optimizations have made the difference negligible for most applications.

TLS 1.3 Performance Improvements:

• 1-RTT Handshake: TLS 1.3 completes the handshake in a single round trip (vs. two for TLS 1.2), reducing latency by one full RTT
• 0-RTT Resumption: Returning clients can send data immediately with zero additional latency
• Reduced Cipher Suite Complexity: Only five cipher suites in TLS 1.3, simplifying negotiation

Additional Optimization Techniques:

• TLS Session Resumption: Reuses previously negotiated parameters to skip expensive key exchange operations
• OCSP Stapling: The server includes the certificate revocation status in the handshake, eliminating the need for the client to contact the CA separately
• HTTP/2 and HTTP/3: Both protocols require or strongly encourage HTTPS, and their multiplexing and header compression features more than compensate for any TLS overhead
• Hardware Acceleration: Modern CPUs include AES-NI instructions that accelerate AES encryption to near-wire speed

Google reported that deploying HTTPS across all of Gmail added less than 1% CPU overhead, less than 10KB of memory per connection, and less than 2% network overhead. The performance cost of HTTPS is effectively solved.

Common Vulnerabilities and Attacks

Despite the strength of modern TLS, several attack vectors have been discovered over the years:

SSL Stripping (2009): Presented by Moxie Marlinspike, this attack intercepts the initial HTTP connection and prevents the redirect to HTTPS. The attacker communicates with the server over HTTPS but serves the victim over HTTP. HSTS and the HSTS preload list are the primary defenses.

BEAST (2011): Exploited a vulnerability in TLS 1.0's CBC mode encryption. Mitigated by TLS 1.1+ and the 1/n-1 record splitting workaround. TLS 1.3 removes CBC ciphers entirely.

CRIME/BREACH (2012-2013): Exploited TLS compression and HTTP compression respectively to recover secrets like session cookies through compression ratio analysis. CRIME was mitigated by disabling TLS compression. BREACH remains a concern when HTTP compression is used with secrets in response bodies.

Heartbleed (2014): A buffer over-read vulnerability in OpenSSL's heartbeat extension that allowed attackers to read up to 64KB of server memory per request, potentially including private keys and session data. Affected an estimated 17% of HTTPS servers at disclosure.

POODLE (2014): Exploited a padding oracle in SSL 3.0's CBC mode. Led to the complete deprecation of SSL 3.0.

ROBOT (2017): "Return Of Bleichenbacher's Oracle Threat" -- demonstrated that RSA key exchange in TLS remained vulnerable to a 1998 padding oracle attack in many implementations. TLS 1.3 removes RSA key exchange entirely.

Best Practices

To properly deploy HTTPS, follow these guidelines:

• Use TLS 1.3 as the preferred protocol, with TLS 1.2 as a fallback only if necessary
• Disable all versions of SSL and TLS 1.0/1.1
• Enable HSTS with a long max-age and submit your domain to the HSTS preload list
• Use ECDHE key exchange for perfect forward secrecy (X25519 or P-256 curves)
• Use AEAD cipher suites only: AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305
• Enable OCSP stapling to improve certificate validation performance and privacy
• Implement Certificate Transparency monitoring for your domains
• Eliminate all mixed content -- audit every sub-resource
• Use CAA (Certificate Authority Authorization) DNS records to restrict which CAs can issue certificates for your domain
• Automate certificate renewal with ACME (e.g., Let's Encrypt with Certbot)

Tools like SSL Labs Server Test (ssllabs.com) and Mozilla Observatory provide comprehensive analysis and grading of HTTPS configurations. Aim for an A+ rating.

For deeper understanding of the underlying encryption, see SSL/TLS and asymmetric encryption. For related authentication protocols, explore SSH and two-factor authentication.

References

• Rescorla, E. (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF.
• Hodges, J., Jackson, C., & Barth, A. (2012). RFC 6797: HTTP Strict Transport Security (HSTS). IETF.
• Laurie, B., Langley, A., & Kasper, E. (2013). RFC 6962: Certificate Transparency. IETF.
• Durumeric, Z., et al. (2014). "The Matter of Heartbleed." ACM Internet Measurement Conference.
• Marlinspike, M. (2009). "New Tricks for Defeating SSL in Practice." Black Hat DC 2009.
• Clark, J., & van Oorschot, P. C. (2013). "SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements." IEEE S&P 2013.
• Barnes, R., et al. (2019). RFC 8555: Automatic Certificate Management Environment (ACME). IETF.
• Google Transparency Report. (2025). HTTPS encryption on the web. transparencyreport.google.com.
• Let's Encrypt. (2025). Let's Encrypt Stats. letsencrypt.org/stats.
• Bock, H., et al. (2018). "Return Of Bleichenbacher's Oracle Threat (ROBOT)." USENIX Security 2018.