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.
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:
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.
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:
- the site is serving large binary downloads (music/video/software distributions) so allowing more caching and faster downloads is important (show data)
- the clients are archaic IE or embedded clients that just can't do SSL adequately (again, show it's actually a problem)
- there are very many resources on the site and you want robots to index it over 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.
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://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. - 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 betweenhttpandhttps. - 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 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
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.
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.
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.
来源：https://stackoverflow.com/questions/2177159/should-all-sites-use-ssl-by-default