HTTPS Can Byte Me
This paper on the security problems of HTTPS was already presented at Black Hat 2010 by Robert Hansen, aka “RSnake”, of SecTheory and Josh Sokol of our own National Instruments.
This was a very technical talk so I’m not going to try to reproduce it all for you here. Read the white paper and slides. But basically there are a lot of things about how the Web works that makes HTTPS somewhat defeatable.
First, there are insecure redirects, DNS lookups, etc. before you ever get to a “secure” connection. But even after that you can do a lot of hacking from traffic characterization – premapping sites, watching “encrypted” traffic and seeing patterns in size, get vs post, etc. A lot of the discussion was around doing things like making a user precache content to remove noisiness via a side channel (like a tab; browsers don’t segment tabs). Anyway, there’s a lot of middle ground between “You can read all the traffic” and “The traffic is totally obscured to you,” and it’s that middle ground that it can be profitable to play in.
How do you make your Web site secure? “SSL!” is the immediate response. It’s a shame that there are so many pain points surrounding using SSL.
- It slows things down. On ni.com we bought a hardware SSL accelerator, but in the cloud we can’t do that.
- Cert management. Everyone uses loads of VIPs, so you end up needing to get wildcard certs. But then you have to share them – we’re a big company, and don’t want to give the main wildcard cert out to multiple teams. And you can’t get extended validation (EV) on wildcard certs.
- UI issues. We just tried turning SSL on for our internal wiki. But anytime there’s any non-https included element – warnings pop up. If there’s a form field to go to search, which isn’t https, warnings pop up. Hell, sometimes you follow a link to a non-https page, and warnings pop up.
- CAs. We have an internal NI CA and try to have some NI-signed certs, but of course you have to figure out how to get them into every browser in your enterprise.
- It’s just retardedly complicated. For putting a cert on Apache, it’s pretty well-worn, but recently I was trying to set up encrypted replication for mySQL and OpenDS and Jesus, doing anything other than the default self signed cert is hell on earth. “Oh is that in the right format wallet?”
The result is that SSL’s suckiness ends up driving behavior that degrades security. People know to just “accept the exception” any time they hit a site that complains about an invalid cert. We have decided to remove SSL from most of our internal wiki and just leave it on the login page to avoid all the UI issues. We couldn’t secure our replication from a combination of bugs (OpenDS secure replication works, until you restart any server that is – then it’s broken permanently) and the hassle.
In general, there has been little to no usability work put into the cert/encryption area, and that is why still so few people use it. PGPing your email is only for gearheads. Hell, you have to transform key formats to use PuTTY to log into Amazon servers using SSL. Stop the madness.
If the world really gave a crap about encryption, then e.g. your public key could be attached to your Facebook profile and people’s mail readers could pull that in automatically to validate signatures, for instance. “Key exchange” isn’t harder than the other kinds of more-convenient information exchange that happen all the time on the Net. And you could take a standard cert in whatever format your CA gives it to you and feed it into any software in an easy and standard way and have it start encrypting its communication.
Me to world – make it happen!