Should all sites use SSL by default?
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 validationthe 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.
In reply to Thomas's answer:
For each site, an SSL certificate has a direct cost. We have a dev, qa, and prod environment and thus that is three certificates that are needed for each site
Hardly true. You don't need to have every single dev and qa behind SSL with valid, current certificates. You -- perhaps -- want one staging site with a valid certificate. But beyond the Apache front-end, your back-end should not know that there's SSL involved. You're not testing anything unique or special by purchasing dev certificates.
Also, the cost is nominal. You're spending more money on the conversation than the certificates actually cost.
For the majority of pages, the content is not secure and forcing SSL would make the page requests take longer on the server because of encrypting and decrypting
A little. Have you measured? You may find that it's hard to measure because the variability of internet speeds trump the cost of SSL processing.
From what I understand, most browsers to do not cache pages that are SSL'ed and thus again, page requests will take longer
Again, have you measured this?
Older browsers have problems with file downloads when they are SSL'ed
Really? Which specific "older browser" are you planning to support that has this problem? If you can't find one and are thinking that someone, somewhere might have this problem, you may be overengineering. Check your logs and see what browsers your customers actually use, and then determine if you have a problem.
I agree that "SSL everywhere" isn't a very good approach. I think you need at least one non-SSL port-80 "welcome" page. But I'm not sure your current set of issues are solid reasons. I think you need considerably more measurements to make the case that SSL actually involves real cost or real performance hits.