Debunking 7 Common HTTPS Myths: Caching, Cost, Speed, and More

Misconception 7: HTTPS cannot be cached

Many believe browsers never store HTTPS content locally for security reasons, but if the HTTP headers permit caching, HTTPS can be cached. IE caches HTTPS when Cache-Control: max-age=600 is set, and Firefox caches to disk when Cache-Control: public is present, as shown in the image.

Misconception 6: SSL certificates are expensive

Cheap SSL certificates are widely available for around $10 per year, and free certificates also exist. While they may lack some prestige, mainstream browsers accept them.

Misconception 5: HTTPS sites must have a dedicated IP address

Using wildcard SSL certificates (≈$125/year) allows multiple sub‑domains on a single IP. Unified Communications Certificates (UCC) and Server Name Indication (SNI) enable multiple domains or certificates on one IP; Apache and Nginx support SNI, while IIS does not.

Misconception 4: You must buy a new certificate when moving servers

Deploying an SSL certificate involves generating a CSR, purchasing the certificate, and installing it. To transfer a certificate, export it in a portable format such as a password‑protected .pfx file (e.g., on IIS) and import it on the new server.

Misconception 3: HTTPS is too slow

HTTPS does not inherently make a site slower; compression reduces CPU load, and the extra TCP round‑trip adds minimal bytes. Initial page loads may be slightly slower due to SSL handshake, but once established, performance is comparable to HTTP, and in some LAN environments HTTPS can even be faster.

Misconception 2: HTTPS makes cookies and query strings safe

Even over HTTPS, cookies and query strings must be unpredictable. Predictable session IDs can be hijacked, as demonstrated by a UK bank example where sequential IDs allowed attackers to capture and reuse sessions.

Misconception 1: Only login pages need HTTPS

HTTPS protects credentials, but other pages remain vulnerable. Tools like Firesheep show that session hijacking is easy on sites that switch from HTTPS login pages to HTTP after authentication, especially on unsecured Wi‑Fi networks where NAT masks client IPs.