Boost HTTPS Performance: Protocol and Configuration Optimizations

HTTPS Access Speed Optimizations

1. TCP Fast Open (TFO)

TCP Fast Open allows the client to send data in the initial SYN packet, reducing one RTT; it requires Linux kernel 3.7+ and is not supported on Windows.

2. HTTP Strict Transport Security (HSTS)

HSTS forces browsers to use HTTPS for a configured period, eliminating insecure 302 redirects and saving an RTT.

3. Session Resumption

Reusing TLS sessions saves CPU (no asymmetric key exchange) and one RTT. Two mechanisms are described:

3.1 Session Cache

Servers store session IDs; clients reuse them. Drawbacks include memory usage and lack of distributed caching.

3.2 Session Ticket

Servers encrypt session state into a ticket sent to the client, avoiding server‑side storage. Benefits are lower memory use; drawbacks are limited support (~60%) and the need to protect the ticket‑encryption key.

4. OCSP Stapling

Servers embed OCSP responses in the TLS handshake, avoiding a separate network request to the CA and reducing latency.

5. False Start

Clients can send application data after the ClientKeyExchange, saving one RTT; it requires PFS and ECDHE support.

6. SPDY / HTTP/2

Both protocols multiplex multiple streams over a single connection, improving throughput. They require HTTPS and are transparent to web applications.

HTTPS Computational Performance Optimizations

1. Prefer ECC

Elliptic‑curve cryptography offers comparable security with smaller keys, resulting in faster operations (e.g., ECC‑224 ≈ RSA‑2048).

2. Use the Latest OpenSSL

Newer OpenSSL releases include performance improvements and security fixes; for example, OpenSSL 1.0.2 speeds up P‑256 operations fourfold.

3. Hardware Acceleration

SSL offload cards or GPU‑based SSL acceleration can offload heavy cryptographic work, but they have limitations: limited algorithm support, high upgrade cost, and added I/O overhead.

4. TLS Remote Compute (SSL Acceleration Cluster)

Baidu deploys a dedicated TLS compute cluster that offloads RSA/ECC key operations and runs asynchronously with web servers.

HTTPS Security Configuration

1. Protocol Version Selection

Disable SSL 2.0, optionally support SSL 3.0 for legacy traffic, and prefer TLS 1.1/1.2.

2. Cipher Suite Selection

Use ECDHE for key exchange, RSA signatures (avoid SHA‑1), AES‑GCM for symmetric encryption, and SHA‑2 or stronger for integrity.

3. Anti‑Attack Measures

Enable TLS SCSV to prevent downgrade attacks, disable client‑initiated renegotiation, and prefer server‑initiated renegotiation only when necessary.

Practical Deployment Beyond the Protocol Layer

1. Full‑Site HTTPS

All resources (JS, CSS, images) must be served over HTTPS; mixed content triggers browser warnings and can break functionality.

2. Domain Strategy

Balance the number of domains: fewer domains reduce TLS handshake overhead, but too few limit parallel connections. Use a limited set of controlled domains and consider CDN support for HTTPS.

3. Connection Reuse

Browsers now allow up to 6–8 parallel connections per host; HTTP/2 multiplexing further reduces the need for many domains.

4. Pre‑connect

Predict next user navigation and establish TCP/TLS connections in advance to hide handshake latency.

5. SPDY/HTTP2 Impact

Multiplexed streams improve connection reuse and reduce latency.

Common HTTPS Migration Issues

1. Referrer Policy

Use or "origin" to control referrer transmission from HTTPS to HTTP.

2. Form Submission to HTTP

Redirect through an intermediate HTTP page or encourage third‑party sites to support HTTPS.

3. Video Playback

Prefer HTTPS video sources or non‑HTTP protocols like RTMP.

4. User‑Side Problems

Incorrect system time, missing proxy certificates, DNS interception, ISP HTTPS failures, and high latency can cause errors; provide guidance to users.

HTTPS deployment dramatically reduces hijacking, improves privacy, and, when optimized, adds only a few hundred milliseconds to page load time.