In light of this recent announcement from the Chrome developers, I decided to comment on the situation. Basically, there has been something of a drive over the past few years to switch the entire web to use SSL everywhere. This is an absurd goal. I will elaborate on why shortly. The Chrome plan is that non-SSL pages always be marked as insecure rather than the situation now where an SSL page that references non-SSL resources is marked as such, or an SSL page that has a dubious certificate for some value of “dubious”.
The Case for SSL Everywhere
There is a case to be made for having every web site use SSL. It does afford some level of protection from snooping if your traffic happens to pass through some network element that allows traffic to be viewed (non-switched ethernet, wifi, proxy, etc.). It also theoretically gives some level of identity verification. It also has the potential advantage that the communcation cannot be proxied if the browsers and servers implement SSL and certificates properly.
The Case against SSL Everywhere
That all seems helpful on the surface. There are, however, some problems with the idea, and these outweigh the potential benefits.
First, to run an SSL site, one must have a certificate. In this age of sub $5 monthly hosting fees, having to obtain an SSL certificate pretty much doubles the cost of running a web site. That doesn’t include the hassle of obtaining the certificate in the first place. To do this right, every web site operator must deal with this directly rather than outsourcing this to their providers. The reason for this is the theoretically identity verification. A basic SSL certificate can run anywhere from about $75/year and up. You should be skeptical of the cheaper ones and certainly of the free ones because the browsers may not have the auhority certificate in their certificate bundle and will thus whine about the certificate not being trusted. Self-signed certificates also run into the same problem with browsers whining about trust.
Second, for maximum compatibility, you must have a dedicated IP address for your web site in order to use SSL. That is because the SSL negotiation and session setup happens before the HTTP protocol even starts up. That means that unlike non-SSL HTTP which can multiple many web sites on a single IP address, using SSL means that every web site requires its own IP address. Until IPv6 finally gets enough traction that IPv4 can be neglected, this simply cannot happen. (There are not enough IPv4 addresses in the entire address space to handle every single web site out there having a dedicated address once you consider that the users have to have addresses too.) There are some virtual hosting technologies which theoretically allow multiple SSL sites on a single IP address but these haven’t had significant penetration and it’s not clear that they are necessarily the right solution.
Third, the encryption and negotiation adds non-trivial overhead to every web page request. HTTP is already a verbose protocol with measurable overhead. Add in the non-trivial computation required to handle encryption, the need to transfer certificate and key information, and other additional protocol framing overhead, and you begin to add measurable overhead to every request. In this age of AJAX, a single web page can generate hundreds or even thousands of requests to the server. Every one of these requests will have the SSL framing overhead, and if persistent connections cannot be used, the session startup overhead, too. This does not seem like a significant problem to most because they tend to run maybe a handful of related sites on a single server which usually has significant resources to spare. For the web hosting operation with potentially thousands of unrelated sites on a single server, this becomes measurable. The resources used are more than just the CPU resources, though. The aggregate increase in bandwidth usage is also measurable. (A similar result happens for large sites with dedicated hosting, especially if they do not use a content delivery network.)
Finally, most web sites do not need any level of security at all. Period. This blog, for instance, does nothing that is actually security sensitive. Sure, I log in to the site over HTTP. But I am the only user that does. Even if you did create an account here, I do not collect sensitive information and you do not need an account to view the site. This is a public site publishing information publicly. I do not handle payments over the web. I do not run an authentication service. My site has absolutely no need for SSL. Period. Adding SSL to the site would incur higher hosting fees, require a certificate (more fees), and would increase the maintenance burden because I would then have to deal with certificate renewals, etc.
Why Security Warnings on Non-SSL Are Dumb
The last point against SSL everywhere is really the main point here too. If the majority of sites see no real benefit from using SSL, then there is no impetus to adopt it. If the vast majority of sites do not adopt SSL, then showing a warning on non-SSL simple adds to the noise. People will become accustomed to ignoring the warning icon and the status quo will continue, but with less real information available to those who do care.
The fun thing here is that there used to be an obvious signal that SSL was not in use on a web site. Web browsers used to show the entire URL in the address bar when displaying a page. Now that they abbreviate the http:// part out of the URL, that signal is no longer present so now they feel the need to overload another signal to do so. Had the web browser makers not insisted on making the interface “easier”, we would not have this problem. It would be clear to anyone who actually cares that things are not secure.
Finally, given that most users don’t understand security at all, having a warning about non-SSL is just going to confuse them and they will ignore it anyway because they have to see their pictures of kitties eating cheeseburgers or whatever it is.
Closing Remarks
In summary, this plan from the Chrome developers is misguided. It is sufficient that the major web sites people use (Facebook, Twitter, Gmail, MSN, etc.) which do deal in sensitive information enable SSL. Vanity blogs simply don’t need it. For sites that do enable SSL, the existing browser warnings are sufficient to identify dumbness.
If enabling SSL everywhere really had real tangible benefits that outweigh the hassle and cost, it would be happening without help. It is not. If the problem is simply that the operators do not know what the benefits are, then the solution is education, not bludgeoning with spurious warning. With proper education, if the benefits sufficiently outweigh the drawbacks, change will happen without employing blunt instruments. Given that major hosting companies haven’t made the switch in this direction, it seems that is unlikely to happen in this case.
I sincerely hope this plan from the Chrome developers never moves past Chrome and is derided by the other browser makers as misguided. Should a time come when web sites really are primarily delivered using SSL, then such a plan starts to look sensible. Until such time, it should be derided as the dumb idea it is.