On the WebSockets mailing list, there is a heated discussion going on about whether or not WebSockets should be deployed over TLS (aka “httpsâ€) or not. The common misconceptions about TLS arise, of course. But it has become increasingly clear that most people view protocol security completely backwards, because of HTTP. (Thanks to Jim Roskind for crystallizing this)
Today, we view the web as two protocols:
- HTTP: The protocol of the web
- HTTPS: The secure version of HTTP. Cool!
But we should think of it like this:
- HTTPS: The protocol of the web
- HTTP: The insecure version of HTTPS. Yikes!
We shouldn’t feel safe when we use https. We should feel unsafe when we use http.
Our vantage point is backwards because we started with the notion that security is an “add onâ€. In today’s hostile networking environment, nothing could be further from the truth. Security is not a feature, but a requirement. Offering an “insecure†version for those that want to play risky should be the optional feature. This just becomes more true when you think of the fact that new protocols will be in use 10 years from now…
Sorry, but this is nonsense. Your argument is that the default position should be HTTPS doesn’t hang together for a number of reasons:
1. Most websites don’t need secure features.
2. HTTPS has a significant processing overhead, meaning that the web would need many times more servers to cope with the traffic. Tis is the opposite of what the industry is trying to acheive. We need fewer servers and to operate as efficiently as possible
3. HTTPS has a more significant client side burden, meaning that it will eat mobile device batteries at a faster rate than http. I want my phone to last as long as possible
4. HTTPs has a certificate requirement, which is another expense that many people that run small sites can’t afford.
It’s always been my view that SSL (in its current state, anyway) is snake oil.
SSL’s security is really determined by two points: the encryption algorithm in use, and the authenticity of the SSL certificate holder.
Too often, servers are configured to allow weak ciphers which completely undermines the purpose of encrypting on the transport layer. As I understand it, it’s pretty easy to break most of the ciphers less than 128 bits, so using anything less is asking for trouble.
As for authenticity, many Certificate Authorities are content to simply accept the information you put into their online form and not perform any kind of follow-through to ensure that you are the entity you claim to be. This also undermines the purpose of encryption, as a deceptive entity can obtain an SSL certificate almost as readily as a legitimate entity.
Having said that, there is also no fundamental difference between the encryption provided by a self-signed SSL certificate and that of a signed SSL certificate. In either case, the connection is encrypted.
It can be argued that the only reason SSL certificates (especially those which don’t extensively verify the information in a CSR) aren’t free is to limit the number of available SSL certificates in the market and to signify that a site is “serious about security” when in fact they probably aren’t using a secure enough cipher to prevent eavesdropping and their information may or may not be verified.
It can also be argued that it will be increasingly difficult to provide enough dedicated IPs as required for an SSL-only web until IPv6 has fully proliferated.
Since it’s safe to assume that the preferred and even default state of both servers and home internet users is a secured endpoint, the only time SSL is *really* necessary is when someone is connecting to a server from a foreign location where they are uncertain whether or not their traffic can be intercepted, or when there is some risk that their traffic can be intercepted in transit.
Geoffrey –
I’ll address your points.
1) Websites may not need secure features, but the users accessing them do. It’s not the website that determines if I need privacy or not, it’s me. Notice that all of your arguments state that the we shouldn’t do HTTPS because of the *server*? I’m trying to protect the users. Why should anyone sitting in the cafe next to me know what I’m doing on http://www.whatever-random-site.com/? Why does the server get to determine if I have privacy?
2) You should go get some data on that. Remember CPUs a lot faster than they were in 1995. Check here for some good information: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
3) I work on browsers, and I can assure you that we can do this on the client side without burden. We can have both security and speed. I’m not saying existing SSL doesn’t need improvements, it does. But we’re fixing that. Don’t forget that SSL is the unoptimized frontier.
4) Certificates cost $10. If a website isn’t willing to spend $10 to protect its users, its probably not worth going there. But, if that is too much, you can get a free one too. https://www.startcom.com/
I disagree with your basic premise that performance is more important than privacy and security. But – there is no reason we can’t have both. Will server CPUs use a little more power? Yes. But users won’t notice and they will finally have more privacy. (How many times do we need to get bitch-slapped about privacy before we learn that this is a big deal?)
This argument might hold some weight if supporting HTTPS effectively didn’t require extortion payments to the “Certificate Authorities” . . .