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.

Answer 1

"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 2

Except your apps/websites have extremely sensible information don`t use SSL.

Or use it only for "log in" forms.

To provide correct SSL session you will have to load images, css-es etc. trough SSL. That will increase your bandwidth significantly

Have in mind and the supporting, renewing the certificates etc.

Answer 3

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 4

I don't think that you should SSL all your sites and definatelly 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 5

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.

SSL prevents usage of so-called "virtual domains". When a browser connects to a HTTPS server, the server must respond using a server certificate which contains the server name; the browser verifies that the name in the certificate matches the server name in the URL. This happens before the browser actually sends the URL; hence, a server machine which hosts several HTTPS servers must guess the "right" certificate, out of thin air. In practice, this means one public IP address per server name (the server then uses the incoming IP address to guess which certificate to use). Depending on your situation, this may or may not be a serious issue.

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.