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

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.

Answer 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.

Answer 3

I don't think that you should SSL all your sites and definitely you don't need to buy certs for your dev environments. If you want/need an SSL certificate for dev it can be easily generated and that in most cases would be enought for that environment. The other possibility is that you can buy a wildcard certificate and set you dev servers in one of the subdomains, this way you can have the same certificate for both environments but again: it's a waste of money if you buy wildcard certificate (which are more expensive) just to have dev work on it as well. It makes sense if you have multiple subdomains on prod that needs to be SSLed.

As for the speed: yes it's a bit of a problem but not that significant. SSL responses are not cached so using them will increase your servers load a bit but I think this is the part that admin should be aware of.

Answer 4

This first thing to ask yourself, what does SSL buy you? It buys you the assurance that no one and no application can "sniff" the traffic and see what is going between the web-server and the browser. The cost is the real cost of purchasing an SSL certificate, and the on going cost of a slight increase in download speed. You mention that older browser have trouble downloading files over SSL communication. I can not speak to that, and I wouldn't concern myself too much with that. From a security stand point, you have another concern. Modern firewalls monitor traffic looking for various hack attempts. SSL prevents the firewall from monitor that communication, so the application developer / web-admin needs to be even more concerned with protecting their application and sites from various hacking attempts. Long story short, one should only encrypt communications that truly need it.

Answer 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.

Answer 6

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