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 requiring authentication and containing sensitive content. Our web server admins have (without any input from the development team) decided to make it a standard in the new environment to force SSL for everything. I do not agree with this decision and would like to have as much knowledge as possible when I sit down to discuss it. Here's what I have so far:

• 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
• 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
• From what I understand, most browsers to do not cache pages that are SSL'ed and thus again, page requests will take longer
• Older browsers have problems with file downloads when they are SSL'ed

I do not have an issue with forcing SSL when users are authenticating or they are requesting sensitive data. However, I think forcing SSL by default on all sites is a bit much.

Solution 1

SSL can inhibit network-level caching. There are workarounds to this but it can mean that multiple computers in the same network have to re-download page resources. This can increase network load at both ends. Browser-level caching is not an issue in modern browsers.

SSL complicates usage of so-called "virtual domains". Traditionally in order to form a SSL connection the browser and server need to be working to the same domain name. This made it impossible to host more than one SSL certificate on a single IP because the server would respond with the wrong certificate. The implementations of Server Name Indication (an extension to the TLS protocol that SSL uses) has fixed many of the problems with this.

On pure performance, the symmetric encryption and integrity check on tunneled data is not very expensive; if your server cannot encrypt and decrypt at network speed, then either you have God's own optic fiber, or you should think about replacing those i486. However, the initiation of a SSL connection, known as "handshake", is a bit more expensive, and may imply a performance bottleneck on heavy loads (when there are hundreds of connections per second, or more). Fortunately, a given browser instance will reuse tunnels and SSL sessions, hence this is not a problem if you have only a few dozen users.

Overall, putting SSL everywhere looks like a way to get a "warm fuzzy feeling" on security. This is not good. This usually means that by concentrating on the irrelevant, administrators will be more likely to disregard actual security issues. They will also make the system more complex to maintain, making it more difficult to diagnose and correct problems. Note that from the administrators point of view, this makes their job more secure, since it increases the cost of firing them and replacing them.

Solution 2

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.

Solution 3

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.

Solution 4

So I've seen some fantastic answers to this question, but after a few days I saw that there are a few things missing. Therefore, there are a couple of things I want to mention:

Why Use SSL on Everything

• Security - If only a few pages are SSL encrypted, it's easier to "sniff" out which pages contain sensitive data. Now SSL is pretty goddamn safe, so this isn't something to worry about, but in the case that your private key gets compromised, it's good practice to have that additional layer of security so that it's harder for the bad guys to get at the juicy stuff.
• Trustworthiness - There are people who argue that when you visit a site that has a verified certificate, it is easier to trust. Since a verified certificate costs money, it's easier to trust a site knowing that the owner invested in a symbol of trust.
• Hassle - Blanketing everything under SSL is just so much easier. All you have to do is chop off the http: at the beginning of every resource link and you're good.
• SEO Configuration - You won't have to bother at all with SEO configuration. I've heard that search engines index http:// and https:// as separate entries, so for consistency (in both SEO and page behavior), blanketing SSL over everything and just setting up a 301 redirect seems like a nice easy solution.
• Consistency - You'll have a much more consistent website if you just https:// everything. Lots of frameworks break when you try to do a hybrid of SSL and non-SSL. On top of this, URL-dependent plugins and code will be really mean if you try to bounce back and forth between http and https.
• That Fuzzy Secure Feeling - You have to admit, that little green bar on the top left that says "verified domain" just is a damn good feeling.

Why Not SSL Everything

• Speed - SSL is slower. Not by much, of course, and most of the time the cost is negligible. It's an unavoidable fact, however, that SSL will always be slower.
• Browser Compatibility - This is probably negligible, but if you want to support really old browsers that don't cache over SSL, you'll have to stick with port 80.
• Plugins - A bunch of plugins don't work correctly over SSL, so you'll have to be careful of that. If you ever want to add a new plugin, you'll have to reconfigure your SSL settings or look for another plugin.
• Professionalism - Now although some people argue that seeing a verified SSL domain seems trustworthy, others view it as a very amateur and lazy solution. In fact, it's really easy and cheap (cost me about $10) to get a verified SSL certificate that hits up to 96% of browsers!
• Hassle - So I did say that it's easier to SSL everything, but at the same time you're going to have to make sure every resource is loaded through https:// (or do the http:// -> // quick solution). It can be a bit tedious if you have a bunch of links or even incompatible if you have user-submitted content hosted on a site that doesn't support SSL. In those cases, your browser will whine at you. If you've ever seen that notice that says "this page has insecure content", you'll know how annoying that is and how bad that looks.

So in short, it's really situational but I tend to avoid blanketing SSL. Sure, it does take a bit more configuration but in the end you get a much more flexible system. I personally think the whole "professionalism" thing is bullshit (Twitter and Google SSL everything). However, if you have externally hosted content or user-posted content, it's usually a really bad idea to SSL everything. You might also begin SSL-ing everything and run into a bunch of troubles.

But that's just me. :D

Solution 5

In another response to Thomas answer, especially since it is on top.

Also, further down I linked a white paper with best practices for SSL.

SSL prevents caching, not only from browsers but also from proxy servers. Every web page element will have to be sent by your main server, again and again. This increases network load.

Only partially true. SSL will prevent proxy caching, but not browser caching - also see the answers to this question. Not a big issue in my opinion.

SSL prevents usage of so-called "virtual domains". [...]

This is partially true. However, virtual domains will work fine as long as you have only one certificate. Even if you not, Server Name Indication (SNI) should be a viable alternative (or should be, once Windows XP is off the face of the planet).

[performance] However, the initiation of a SSL connection, known as "handshake", is a bit more expensive, > and may imply a performance bottleneck on heavy loads (when there are hundreds of connections per second, or more). Fortunately, a given browser instance will reuse tunnels and SSL sessions, hence this is not a problem if you have only a few dozen users.

Even the handshake should not cause any performance issues on the server side if you have modern hardware. The main reason of the handshake being "slow" is due to the fact that network packages need to be sent back and forth a few times between the server and the browser - computational power has little to do with it.

To put it another way: Setting up the SSL connection will be an order of magnitude cheaper than rendering a PHP page which fetches data from a database.

Overall, putting SSL everywhere looks like a way to get a "warm fuzzy feeling" on security. > This is not good. This usually means that by concentrating on the irrelevant,

NOT TRUE AT ALL. Either you don't need SSL at all on your site, because it's completely public content. Or you do need SSL for some reason (user logins, protected areas). In that case, the best practice is to put it everywhere.

Having SSL only on parts of your page can open you up to all kinds of obscure risks. And while you can find and mitigate those in other ways, is will be more complex, error-prone and time-consuming than just having SSL enabled on all pages.

I have found the this white paper on SSL. I'm not affiliated with the company that authored it, but I found it a very concise summary of all the things that you need to keep in mind when deploying an SSL setup.

That security has more than one component goes without saying. But already getting the first wrong is not a good start.

View more solutions

Comments

[Jason]

specifically IE 6, and unfortunately it is something we still have to support.

[user1066101]

@Jason: Focus on that issue, since that's the only one where you have facts. Start measuring. Produce details on what -- specifically -- won't work.

[President James K. Polk]

SSL certificates are so inexpensive that most experts recommend against rolling your own.

[RaYell]

What's the point of rolling your own certificate if it's for dev purposes only? It's not very expensive if you look what the whole project would cost but it doesn't give any benefits either.

[Adam Bellaire]

WRT SSL preventing caching, this is only somewhat true: stackoverflow.com/questions/174348/…

[Kevin Wang]

This is very true. Good answer, but slightly unclear. Modern browsers cache all content over HTTPS unless specifically told not to do so.

[poolie]

Good answer. Also, if you want mixed http/https, with ssl only for "important" data, you also need to take into account the cost of developing the right transitions, of fixing bugs in them, and the risk of security bugs when you get it wrong. If you make almost all of the site SSL, most of the application code can just assume the transport is secure, which keeps it simple.

[poolie]

If you're concerned about transport speed, use SPDY and everything will be both under SSL and probably faster than HTTP.

[Kurt]

This is wrong. SSL web hosting works just fine with virtual domains: wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI and techrepublic.com/blog/opensource/…

[poolie]

@Kurt, that's a good point, but SNI is not yet supported by all clients, probably under 90% on many sites - see serverfault.com/questions/270493

[Kevin Wang]

Haha SPDY. This looks amazing! +1

[poolie]

Re "warm fuzzies": it's defense in depth. If your admins think that getting one layer right lets them ignore the other layers, you've got bigger (cultural) problems. And HTTPS is barely any more complex.

[poolie]

3 years later, Microsoft have ie6countdown.com trying to get people to move off it, and its share in developed countries is <0.5%.

[Starkers]

Just saying it appears github in its entirety is served over HTTPS protocol, even when you're not logged in and are just browsing static areas: https://github.com/features And I'm sure the github peeps know exactly what they are doing.

[averell]

There are several misconceptions here: Virtual Hosts are only a problem when you have to use multiple certificates. Even then, Server Name Indication (SNI) could be a viable solution.

[poolie]

Further evidence: Youtube.com is now served over https. If they can do it with such vast data volumes and probably relatively low revenue/byte, you can too.

[Justin Warkentin]

This really should not be marked as the "correct" answer. It is very misleading and even wrong. The fact is that there are many possible MITM attack vectors against users that a company might never find out about if SSL isn't used everywhere. SSL is a cheap and necessary requirement, no matter what type of site you are serving. It's not just for "warm fuzzies". I'm sick of developers having little to no understanding of security or having such a lax and irresponsible attitude towards it.

[Justin Warkentin]

You cover several good points, but the professionalism point you make is a bit misleading and beside the point. Unless the website developer is in control of the full security stack on the client and server (it's not and can't be without using a separate piece of software entirely), there is absolutely no possible way to securely verify identity and know that your communications aren't compromised without using SSL/TLS. Which brings me to my next point. It doesn't matter how cheap a cert is. Its purpose is simply to verify that the client is in fact communicating with who it thinks it is.

[Justin Warkentin]

Excellent answer. After all the misinformation in answers here, I'm glad to see someone here mostly gets it. I want to point out though that your bolded statement at the top isn't exactly true. One possible MITM attack vector could be to redirect the user to a phishing site that looks like the one they think they're on. Hence, even if there's no login involved it is still good practice to use SSL everywhere.

[Justin Warkentin]

Right, but even that isn't safe. A man in the middle could still attack a user by modifying downloaded executables to insert viruses or malware, redirecting the user to phishing sites, or even modifying the web content being sent to the user under the domain name they think they are at. The moment you serve anything over an unencrypted connection, you are exposing site visitors to unnecessary security risks. It's actually dangerous even for a user to initially request an HTTP site, even if it redirects to HTTPS, because session cookies can be captured my a MITM.

[Justin Warkentin]

This is why you get entities, like Google, that actually understand the importance of security advocating SSL everywhere. Users should install HTTPS Everywhere to ensure they don't expose session cookies, allow SSL stripping, or allow other attacks by even attempting an HTTP connection where possible.

[poolie]

I like the way you have professionalism and it's a really good idea to protect your user and site's security, but it's just a bit of hassle right next to each other :)

[poolie]

Yes, I agree with all this, and added mention of HTTP STS which is more scalable than HTTPS Everywhere.

[Justin Warkentin]

Great addition. HSTS will protect against SSL stripping. However, it should be used in combination with something like HTTPS Everywhere because even with HSTS the first request can still be made over HTTP. With HTTPS Everywhere it protects against much of that. They should really be used together, especially since most sites still don't send the STS header.

[Justin Warkentin]

Also, the caching issues can be dealt with. When I need caching I set up Nginx or a load balancer that handles the SSL/TLS encryption, and make that actually forward requests to Varnish which caches everything. It only hits the back end server if it needs to. Varnish is excellent with or without SSL, but since it doesn't handle the SSL itself you just have to set it up behind something that will, like Nginx.

[poolie]

The OP was talking about client-side or near-client caching. But yes, you obviously don't need to terminate SSL on the origin server.

[colan]

SSL doesn't necessarily prevent caching. If you're using something like Varnish as a caching proxy (which doesn't support SSL), simply stick an SSL terminator (like Nginx or Pound) in front of it.

[Oli]

A lot of people whinging about the accuracy of this answer. If you see something wrong like this, just fix it. That's the point of SE.

[Nayuki]

Even a website with completely public information is unsafe over HTTP. An ISP can modify the page to inject ads and trackers. A hostile government can inject code to attack a third party (see China's attack on GitHub).