HTTPS Optimization: Protocol and Configuration Best Practices

Part 3: Protocol‑and‑Configuration Optimizations

The previous part discussed the impact of HTTPS on user access speed. This section introduces optimizations for HTTPS speed, computational performance, and security based on protocol features and configuration.

1. TCP Fast Open (TFO)

HTTPS and HTTP use TCP, which normally requires a three‑way handshake before any application data can be sent. TFO (RFC 7413) allows data to be carried in the initial SYN packet, reducing one RTT. Linux kernels ≥ 3.7 support TFO, but Windows does not, so its use is limited to internal servers.

2. HTTP Strict Transport Security (HSTS)

Redirecting HTTP to HTTPS with a 302 response adds latency and exposes the original request. HSTS lets the server send a header that tells browsers to always use HTTPS for a given period, eliminating the extra RTT. All major browsers support HSTS.

3. Session Resumption

Session resumption reuses TLS session information to skip the expensive asymmetric key exchange, saving CPU and one RTT.

3.1 Session Cache

The client includes a session ID in its ClientHello; if the server has a matching entry, it can resume the session. Drawbacks: server memory consumption and lack of distributed cache support in common servers (nginx, Apache). Advantages: universal browser support.

3.2 Session Ticket

Defined in RFC 4507, the server encrypts session state into a ticket and sends it to the client. The client returns the ticket on subsequent connections, allowing stateless resumption. Benefits: no server‑side storage. Drawbacks: limited support (~60 %) and the need to protect the global ticket‑encryption key.

4. OCSP Stapling

OCSP (RFC 6960) checks certificate revocation status. Stapling lets the server include the OCSP response in the TLS handshake, avoiding a separate network request to the CA and reducing latency. Nginx enables it with:

ssl_stapling on; ssl_stapling_file ocsp.staple;

5. False Start

Google’s False Start (draft‑bmoeller‑tls‑falsestart‑00) sends application data after the ClientKeyExchange, saving one RTT. It requires PFS and prefers ECDHE key exchange.

6. SPDY / HTTP/2

SPDY (Google) and its successor HTTP/2 multiplex multiple HTTP requests over a single connection, improving throughput. Both require HTTPS and are transparent to web applications. Chrome dropped SPDY in favor of HTTP/2; Baidu’s servers and mobile browser already support SPDY 3.1.

HTTPS Computational Performance Optimizations

1. Prefer ECC

Elliptic‑Curve Cryptography offers stronger security per bit than RSA/DH. NIST recommends key sizes where a 224‑bit ECC key provides security comparable to a 2048‑bit RSA key, resulting in faster modular exponentiation.

2. Use Latest OpenSSL

New OpenSSL releases improve speed and fix vulnerabilities. For example, OpenSSL 1.0.2 with Intel optimizations speeds up P‑256 operations by ~4×.

3. Hardware Acceleration

Two common approaches: SSL‑offload cards and GPU‑based SSL acceleration. Both offload CPU‑intensive cryptographic operations but have drawbacks such as limited algorithm support, high upgrade cost, and added I/O overhead.

4. TLS Remote Compute Cluster (Baidu)

Baidu built a dedicated SSL acceleration cluster that offloads RSA, ECC key generation, and shared‑secret computation, allowing asynchronous, non‑blocking TLS processing for web servers.

HTTPS Security Configuration

1. Protocol Version Selection

Disable insecure SSL 2.0. SSL 3.0 is deprecated due to POODLE but may be kept for a tiny fraction of traffic. TLS 1.1 and 1.2 are recommended.

2. Cipher Suite Selection

Prefer ECDHE key exchange, disable DHE, and use RSA only as fallback. Use RSA signatures with SHA‑2 (avoid SHA‑1). Prefer AES‑GCM for symmetric encryption and disable RC4. Use SHA‑2 or stronger for integrity checks.

3. Anti‑Attack Measures

Prevent protocol downgrade attacks with TLS_SCSV. Block insecure renegotiation; allow only server‑initiated renegotiation when necessary.

Part 4: Practices Beyond the Protocol Layer

1. Full‑Site HTTPS Rationale

HTTPS must protect all resources (HTML, JS, CSS, images). Mixed content triggers browser warnings or blocks, breaking functionality.

2. Site Types and Deployment Complexity

Simple personal sites load resources only from the main domain – easy HTTPS migration. Complex personal sites load external resources – require CDN support for HTTPS. Large sites range from simple (controlled domains) to complex (many third‑party resources), each with different migration effort.

3. Domain Strategy

More domains increase DNS lookups and TLS handshakes. Reducing domain count and leveraging HTTP/2 multiplexing can improve performance, especially under HTTPS.

4. Connection Reuse

Browsers now allow up to 6–8 concurrent connections per domain. HTTP/2’s multiplexing further reduces the need for many connections, but pre‑connecting (DNS‑prefetch, TCP/TLS pre‑connect) can still lower perceived latency.

5. SPDY/HTTP2 Impact

Both improve connection reuse by allowing multiple streams over a single TLS connection.

6. Other Techniques

Pre‑building connections, using HSTS, and other tricks can reduce handshake overhead.

HTTPS Migration Common Issues

1. Referrer Transmission

HTTPS → HTTP referrer is dropped. Use <meta name="referrer" content="always"> or origin . For browsers without meta support (e.g., IE8), employ an intermediate HTTP redirect.

2. Form Submission to HTTP

Submitting forms to HTTP endpoints triggers security warnings; similar redirection techniques can be used, though they introduce risk.

3. Video Playback

HTTP video streams cause mixed‑content warnings. Options: obtain HTTPS video sources or use non‑HTTP protocols like RTMP.

4. User‑Side Anomalies

Issues include incorrect system time (certificate appears expired), missing proxy root certificates, ISP‑level interception, high failure rates on certain ISPs, and general network latency.

Conclusion: Deploying HTTPS at scale involves extensive protocol tuning, hardware considerations, and operational practices. Proper optimization dramatically reduces latency (e.g., eliminating the 400 ms penalty of a 302 redirect) and improves user security.