Should all sites use SSL by default?

Question

We are in the process of moving our web architecture to a new environment. Included are dozens of different sites ranging from almost completely static to dynamic sites requirin

Answer 1

As of 2020, all sites should use SSL.

• Certificates have been available for free from Let's Encrypt since 2016.
• Chrome and Firefox have been marking plain HTTP websites as insecure since 2018.
• Google has been giving a SEO penalty to plain HTTP websites since 2017.

It's sometimes argued that sites which publish only low-value, low-trust, read-only public information should still use HTTP, but they should be using HTTPS too. HTTP content can still allow attackers to insert malware or adware, or redirects, into the content. Some major ISP inject ads into HTTP pages for all their customers; this is a potential issue should a malicious ad slip into their feed.

A corporate policy of "everything over SSL, without a specific exemption" is recommended. Security standards (PCI-DSS, ISO, big4 audits, etc...) expect encryption for systems working with sensitive information and the lack of it is considered a red flag.

You should also look at deploying HTTP Strict Transport Security to make sure even the user's first request from typing example.com is sent over HTTPS.

Man-in-the-middle attacks are a real-world problem, especially on wifi networks, but also at the ISP and country level. If your site only uses SSL for login and then returns a session cookie over an unencrypted link, that session cookie not only can, but will be stolen. See Firesheep for a clear demonstration.

SSL is safely cacheable per-user, either for the session or indefinitely. Client-end proxy caches are now rare and optimizing for that case is not important. When they do exist, they commonly get things wrong and bypassing them through SSL is worthwhile.

Properly-implemented SSL or SPDY can be fast: the server overhead is not high and is easily moved onto a separate reverse proxy machine. There are SSL CDNs.

There's no need to buy real certificates for sites that are only for developers and testers. The cost of certificates, in the low tens of dollars, is negligible even for non-commercial sites.

Encrypting data across the network is a useful layer of defense-in-depth. Obviously it is not sufficient by itself to make the service secure, but it eliminates some kinds of problems and has a low cost.

Even for read-only data, there is value in clients knowing they're getting the authentic site: for instance, if they are downloading binaries you don't want trojans to be inserted.

Safely distinguishing pages that need to be over SSL from those that don't takes developer effort that could almost certainly be better used.

Making standards a straightjacket for diverse systems, especially without consultation, is rarely desirable, but there should be a strong default to everything on SSL.

Good examples of case-by-case exceptions, where you should still offer SSL but not force a redirect:

• the site is serving large binary downloads (music/video/software distributions) so allowing more caching and faster downloads is important (show data) -- it's important binaries aren't modified in transit and it provides defense in depth with other validation

• the clients are archaic IE or embedded clients that just can't do SSL adequately -- in 2020, such clients would be very old (and likely dangerous)

• there are very many resources on the site and you want robots to index it over HTTPS -- Google, and likely other bots, will do fine if you force everything to HTTPS

If you use SSL everywhere you will use a few more machine resources, in ways that can be optimized if they become important. If you don't use SSL, you either spend more developer resources to consider security case-by-case, or quite likely you will be more prone to account theft.

Adam Langley of Google wrote in 2010:

If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.