Top 7 Myths about HTTPS

calendarJanuary 28, 2011 in Firefox , HTTPS , HttpWatch

Myth #7 – HTTPS Never Caches

People often claim that HTTPS content is never cached by the browser; perhaps because that seems like a sensible idea in terms of security. In reality, HTTPS caching is controllable with response headers just like HTTP.

Eric Lawrence explains this succinctly in his IEInternals blog:

It comes as a surprise to many that by-default, all versions of Internet Explorer will cache HTTPS content so long as the caching headers allow it. If a resource is sent with a Cache-Control: max-age=600 directive, for instance, IE will cache the resource for ten minutes. The use of HTTPS alone has no impact on whether or not IE decides to cache a resource. (Non-IE browsers may have different default behavior for caching of HTTPS content, depending on which version you’re using, so I won’t be talking about them.)

The slight caveat is that Firefox will only cache HTTPS resources in memory by default. If you want persistent caching to disk you’ll need to add the Cache-Control: Public response header.

This screenshot shows the contents of the Firefox disk cache and the Cache-Control: Public response header in HttpWatch:

Myth #6 – SSL Certificates are Expensive

If you shop around you can find SSL certificates for about $ 10 a year or roughly the same cost as the registration of a .com domain for a year.

(UPDATE: you can get domain validated SSL certificates for free. See comment #1)

The cheapest certificates don’t have the level of company verification provided by the more expensive alternatives but they do work with nearly all mainstream browsers.

Myth #5 – Each HTTPS Site Needs its Own Public IP Address

With the pool of IPv4 addresses running low this is a valid concern and it’s true that only one SSL certificate can be installed on single IP address. However, if you have a wildcard SSL certificate (from about $ 125 yr) you can have as many sub-domains as you like on a single IP address. For example, we run https://www.httpwatch.com, http://www.httpwatch.com and https://store.httpwatch.com on the same public IP address:

On IIS 7 there is a trick though to making this work. After adding a certificate you need to find it and rename it in the certificate manager so that the name starts with a *. If you don’t do this you cannot edit the hostname field for an HTTPS binding:

UPDATE: UCC (Unified Communications Certificate) supports multiple domains in a single SSL certificate and can be used where you need to secure several sites that are not all sub-domains.

UPDATE #2: SNI (Server Name Indication) allows multiple certificates for different domains to be hosted on the same IP address. On the server side it’s supported by Apache and Nginx, but not IIS. On the client it’s supported by IE 7+, Firefox 2.0+, Chrome 6+, Safari 2.1+ and Opera 8.0+.  See comment #4 and comment #5.

Myth #4 – New SSL Certificates Have to be Purchased When Moving Servers or Running Multiple Servers

Buying an SSL certificate involves:

  1. Creating a CSR (SSL Certificate Signing Request) on your web server
  2. Purchasing the SSL certificate using the CSR
  3. Installing the SSL certificate by completing the CSR process

These steps are designed to ensure that the certificate is safely transferred to the web server and prevents anyone from using the certificate if they intercept any emails or downloads containing the certificate in step 2).

The result is that you cannot just use the files from step 2) on another web server. If you want to do that you’ll need to export the certificate in other format.

In IIS you can create a transferrable .pfx file that is protected by a password:

This file can be imported onto other web servers by supplying the password again.

Myth #3 – HTTPS is Too Slow

Using HTTPS isn’t going to make your site faster (actually it can – see below) but the overhead is mostly avoidable by following the tips in our HTTPS Performance Tuning blog post.

The amount of CPU resource required to encrypt the data can be reduced by compressing textual content and is usually not a significant on servers with modern CPUs.

Extra TCP level round-trips are required to setup HTTPS connections and some additional bytes have to be sent and received. However, you can see in HttpWatch that this overhead is small once the HTTPS connection has been made:

The initial visit to an HTTPS site is somewhat slower than HTTP due to the longer connection times required to setup SSL. Here’s a time chart of the page load for an HTTP site recorded in HttpWatch:

And here’s the same site accessed over HTTPS:

The longer connection times caused the initial page load to be about 10% slower. However, once the browser has active keep-alive HTTPS connections a subsequent refresh of the page shows very little difference between HTTP and HTTPS.

First, the page refresh with HTTP:

and then with HTTPS:

It’s possible that some users may even find that the HTTPS version of a web site is faster than HTTP. This can happen if they sit behind a coporate HTTP proxy that normal intercepts, examines and records web traffic. An HTTPS connection will often just be forwarded as a simple TCP connection through the proxy because HTTPS traffic cannot be intercepted. It’s this bypassing that can lead to improved performance.

UPDATE: A blog post by F5 challenges the claim the CPU overhead of SSL is no longer significant, but most of their arguments are refuted in this follow up.

Myth #2 – Anything can go in Cookies and Query Strings with HTTPS

Although, a hacker cannot intercept a user’s HTTPS traffic on the network and read their cookie or query string values directly, you still need to ensure that their values can’t be easily predicted.

For example, one of the early UK banking sites used simple counter based numeric values for the session id:

A hacker could use a dummy account to see how this cookie worked and find a recent value. They could then try manipulating the cookie value in their own browser to hi-jack other sessions with nearby session id values.

Query string values are also protected on the network by HTTPS but they can still leak their values in other ways. For more details see How Secure Are Query Strings Over HTTPS .

Myth #1 – My Site Only Needs HTTPS for the Login Page

This is a commonly held view. The theory being that HTTPS will protect the user’s password during login but HTTPS is not needed after that.

The recently released Firesheep add-on for Firefox demonstrated the fallacy of this approach and how easy it is to hi-jack someone’s else session on sites like Twitter and Facebook.

The free public WiFi in a coffee shop is an ideal environment for session hi-jacking because:

  • The WiFi network doesn’t normally use encryption so it’s very easy to monitor all traffic
  • The WiFi network probably uses NAT through a single IP address to access the internet. This means that a highjacked session appears to come from the same network address as the original login

There are lots of examples of this approach to security. For example, by default the Twitter signin page uses HTTPS but it then switches to HTTP after setting up the session level cookies:

HttpWatch warns that these cookies were setup on HTTPS but the Secure flag wasn’t used to prevent them being used with HTTP:

Potentially someone in a coffee shop with Firesheep could intercept your twitter session cookies and then hi-jack your session to start tweeting on your behalf.

46 thoughts on “Top 7 Myths about HTTPS

  1. Lennie says:

    Actually SSL-certificates are free:
    https://www.startssl.com/

  2. Lennie,

    Thanks for pointing that out. It looks like a company name can’t be included in the certificate, but that’s true of most domain validation certificates anyway.

  3. cider says:

    Yep, I also want to add that SSL certs which are trusted in IE (WinXP+), Safari (MacOS 10.5+), Firefox 2.0+, Opera 9.5+ and Chrome can be obtained for free at https://www.startssl.com/.

    Best,
    cider

  4. Hinnerk says:

    Myth 8: You need a wildcard ssl certificate for multiple servers on one IP.

    Really, just configure your web server (Apache2, Nginx, …) to use SNI and virtual domain hosting with ssl works the same as without ssl, i.e. one certificate per domain all on one IP address.

    Some older browsers may not work, but that’Äs the same as with JavaScript, HTML 5 etc.

  5. Bruno Michel says:

    For your information, you can also have several HTTPS hosts on one IP address with Apache2 by using SNI (Server Name Indication).

  6. Randy says:

    Unfortunately, it is true that https: is more expensive to operate, particularly for a very large server farm. The negotiation and encryption does consume extra server resources, which in aggregate can become substantial. There is a much less expensive way to protect login credentials without turning the entire site over to SSL.
    http://akfpartners.com/techblog/2010/11/20/slaying-firesheep/

  7. Max says:

    Great post. Do you know of a way to have multiple SSL certificates on a single website instance in IIS6?

  8. Randy,

    Thanks for commenting on the blog. What do you mean by a “substantial” increase in server resources? By what percentage would the number of servers in a web farm have to increase in your experience to support HTTPS?

    Isn’t your Firesheep Slaying proposal really security through obscurity:

    http://en.wikipedia.org/wiki/Security_through_obscurity

    rather than a secure solution?

    As one of the commenters pointed out, Firesheep could be changed to manipulate the secure script to prevent the redirection.

  9. Another piece of software which supports SNI is my remote HTTP front-end project, PageKite (www.pagekite.net).

    In my experience SNI is not really a complete solution yet, as browsers which don’t send the SNI extension are still sadly quite common. But over time this can only get better!

    Thanks for the article.

  10. cereal says:

    Pay attention, the free solution (https://www.startssl.com/) doesn’t work on Chrome:

    http://img52.imageshack.us/img52/3493/startssl.png

    ;)

  11. cereal,

    Looks like you may not be able to sign up for a free certificate with Chrome, but it should work with Chrome browsers once its setup:

    “The StartCom Certification Authority is today supported by most important platforms like Microsoft Windows, Apple Macintosh OS X and many Linux operating systems and browsers like Internet Explorer, Mozilla Firefox, Safari and Google’s Chrome provide built-in support. Should you be using an older or unsupported browser you may import our CA certificate.”

  12. sachin says:

    I knew only couple of these…thanks for this awesome information…

  13. Mike Slinn says:

    In “Myth #3 – HTTPS is Too Slow” you suggest that modern hardware and keepalive overcomes SSL computation. What cipher length and type are you assuming when making this statement?

    FYI: here is summary of another mythbuster that seems to contradict your conclusions for Myth #3 (see http://devcentral.f5.com/weblogs/macvittie/archive/2011/01/31/dispelling-the-new-ssl-myth.aspx) I have summarized two of Lori’s articles below.

    NIST’s Jan 1/11 recommendations specify 2048 length keys; only Diffie-Hellman, AES or 3DES-EDE-CBC are allowed. RSA and RC4 are no longer recommended because these ciphers are too easy to crack with today’s computers.

    NIST specifies government and military security standards and is therefore influential with commercial certificate authorities. VeriSign, GeoTrust, Entrust and GoDaddy now only provide 2048 bit keys. Microsoft uses and recommends 2048-bit keys. Red Hat recommends 2048+ length for keys. And as of December 31, 2013 Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits.

    I’d like to know the cipher length and type you used to draw your conclusions for Myth #3.

    Thanks,

    Mike

  14. Mike,

    The timecharts are for our site running with a 2048 RSA public key and AES 128-bit as the default symmetric cipher.

  15. There’s an interesting follow up to the F5 blog post here:

    http://www.imperialviolet.org/2011/02/06/stillinexpensive.html

  16. Yiong says:

    This is a very interesting and informative post. Thanks!

  17. This is pretty awesome! Thank you for sharing this informative post to us!

    Geri
    Web Traffic Spreader

  18. looker says:

    Ironic that as I read this blog entry, I cannot view any of the images that go with it – Safari tells me “The certificate for this server is invalid. You might be connecting to a server that is pretending to be “blogcdn.httpwatch.com” which could put your confidential information at risk.”

    And even though the url I am at is “https://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/” the entire page is unencrypted.

  19. looker,

    That error has now been fixed and you shouldn’t see any problems with HTTPS on this blog.

  20. Lennie says:

    Actually your update about SNI and versions of IE is wrong.

    SNI is not support by any version of IE on Windows XP also not by Safari on Windows XP. The problem is in Windows XP, not IE or Safari directly. IE7 or IE8 on Windows Vista does work.

    Android 2.x also does not support SNI, which is an unfortunate mistake which is fixed in Android 3.x.

    If you want to do proper HTTPS, you also should also test your site with: https://www.ssllabs.com/ssldb/ and disable old encryption methods in your webserver configuration.

  21. Robert says:

    NIST specifies government and military security standards and is therefore influential with commercial certificate authorities. VeriSign, GeoTrust, Entrust and GoDaddy now only provide 2048 bit keys. Microsoft uses and recommends 2048-bit keys. Red Hat recommends 2048+ length for keys. And as of December 31, 2013 Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits.

  22. Neill says:

    I always though that HTTPS slower and also seen these. I tried the suggested tips on the HTTPS performance tuning tips: http://blog.httpwatch.com/2009/01/15/https-performance-tuning/ and it’s improved the performance. thanks!

  23. Great post. Do you know of a way to have multiple SSL certificates on a single website instance in IIS6?

  24. 即时比分 says:

    Great post. Do you know of a way to have multiple SSL certificates on a single website instance in IIS6?

  25. Of course HTTPS content is always cached by the browser. There are a lot of myths out there. This is easily one of the most useful articles I’ve read this year. Thanks for writing this post.
    Regards,
    John Como

  26. good information, but I think that not only are 7 myths of https …. missing at least 3 myths.

  27. great website i liked your work. Actually your update about SNI and versions of IE is wrong.SNI is not support by any version of IE on Windows XP also not by Safari on Windows XP.

  28. Great publishing and ironic that as I read this blog entry, I cannot view any of the images that go with it – Safari tells me “The certificate for this server is invalid.

  29. Silvia says:

    This is a great post, but I have notice that HTTPS is a bit slower, maybe is just my percetion.
    Just in case I set up my facebook account with HTTPS
    equipos de estetica

  30. Pretty interesting information, I did not know the HTTPS was kept in cache

  31. comercial says:

    I did put a HTTPS on my facebook, but it is a lot of games and pages that do not work with this , plus it was slower so I have decided to back to the original state

  32. Aydin says:

    There are a lot of myths out there. This is easily one of the most useful articles I’ve read this year. Thanks for writing this post.

  33. interesting did not know about HTTPS

  34. You need a wildcard ssl certificate for multiple servers on one IP.

    Really, just configure your web server to use SNI and virtual domain hosting with ssl works the same as without ssl, i.e. one certificate per domain all on one IP address.

    Some older browsers may not work, but that’Äs the same as with JavaScript, HTML
    HTTPS is Too Slow” you suggest that modern hardware and keepalive overcomes SSL computation. What cipher length and type are you assuming when making this statement?

  35. Frederic says:

    Great post.
    Is there any evolution nearly two years after writing this post ?

  36. Very good information. It has helped me better understand the HTTPS. I have a question, I want to buy an SSL certificate. Do you recommend Godaddy?

  37. Carlos Perez says:

    the negotiation and encryption does consume extra server resources, which in aggregate can become substantial

  38. ralph baker says:

    SSL Certs are essential and a must have.

Got Something to Say?

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Ready to get started? TRY FOR FREE Buy Now