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.
As of 2012, sites should use only SSL if they have personally identifiable (PII) or commercially important information, or if they have any concept of a login.
Sites that publish only low-value, low-trust readonly public information are a bit arguable, but probably could still usefully serve everything over HTTPS. Attackers may try to insert malware or adware, or redirects, into HTTP content.
A corporate policy of "everything over SSL, without a specific exemption" is reasonable.
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 you do only the login phase over SSL and then pass a session cookie unencrypted, that session cookie 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 readonly 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 never good. But saying that sites should all be on SSL unless there is a particular reason to do otherwise in one case makes sense to me. Good examples of case-by-case exceptions, where you should still offer SSL but not force a redirect:
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:
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.
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.
In reply to Thomas's answer:
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.
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.
Again, have you measured this?
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.
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.
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.
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).
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.
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.
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
http:
at the beginning of every resource link and you're good.http://
andhttps://
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.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 betweenhttp
andhttps
.Why Not SSL Everything
https://
(or do thehttp:// -> //
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