Security Collapse In the HTTPS Market
CowboyRobot writes: HTTPS has evolved into the de facto standard for secure Web browsing. Through the certificate-based authentication protocol, Web services and Internet users first authenticate one another ("shake hands") using a TLS/SSL certificate, encrypt Web communications end-to-end, and show a padlock in the browser to signal that a communication is secure. In recent years, HTTPS has become an essential technology to protect social, political, and economic activities online. At the same time, widely reported security incidents (such as DigiNotar's breach, Apple's #gotofail, and OpenSSL's Heartbleed) have exposed systemic security vulnerabilities of HTTPS to a global audience. The Edward Snowden revelations (notably around operation BULLRUN, MUSCULAR, and the lesser-known FLYING PIG program to query certificate metadata on a dragnet scale) have driven the point home that HTTPS is both a major target of government hacking and eavesdropping, as well as an effective measure against dragnet content surveillance when Internet traffic traverses global networks. HTTPS, in short, is an absolutely critical but fundamentally flawed cybersecurity technology.
Yes HTTPS is flawed. Name one protocol that is not.
Unless someone can offer a cost effective replacement (IE one that can be deployed and scaled into without breaking existing technology) then the best approach is to continue and fix the flaws as they are found.
The solution to a problem is not always "throw it away and re-write it". In fact the longer you are around in technology, the more you will realize that this is hardly ever a good idea.
Every lock, every door can be attacked and broken. It's no different with protocols. We don't stop locking our bikes or cars just because a government soldier with an M16 can shoot the lock open.
goto_fail is just a bug like every else. Its a major bug, yes, but its "only" a bug. There are more systemic issues.
PKI is broken. Diginotar was just one indident we know of. CAs can secretly give everybody any cert they want. We need a system where the CAs need have to publish their certs, and which itself can't forge. Certificate transparency only centralises this "tree of trust". We still need to give the tree a ground to stand on. This can be achieved by gossip protocols. With all these measures, we don't need CAs anymore. CA is a multi-million dollar industry, they won't like being obsolete.
Third point: Microsoft. They haven't added usable perfect forward secrecy until april 2014.
Fourth point: the users. They don't care, or other things are more important to them (stability, etc): Most of them don't update their browsers regularly. I don't critizise clicking away security warnings.
HTTPS/SSL, but with the signing, distribution, and recovation done in-house. The big SSL vendors seem to often be prone to poor security, as well as possibly succumbing to the demands of certain government agencies and providing "private" keys.
At least if your certificate is signed in-house, you have control of your certs and a certain amount of extra protection against the above. This might not be a good solution for smaller shops, but mid/medium shops could accomplish this, it's just easier to use a "big name" registrar.
Perhaps one solution would be to have an easily deployed appliance/distribution that runs as an internal certificate store.
OpenSSL's heartbleeed bug was a bug in openssl, a buffer overrun that didn't really have anything to do with ssl. A similar bug in any other server software would be approximately as bad. Where https protocol specified a ping, openssl instead leaked the contents of arbitrary memory locations .
Apple's goto bug was Apple's bug. Again, little to do with the protocol. Ssl/tls/https didn't fail here, the company failed to implement https.
The one "fault" of the protocol in the cited cases could be that it isn't brain-dead simple. Since the standard isn't idiot-proof, idiots can screw it up.
It's not HTTPS that's insecure, it's the current certificate authenticity chain.
Eliminate that chain, work out a public exchange and verification program (something akin to bittorrent for
gpg signed certificates from other people you trust.) and plug that in in place of the current certificate authority
model and you're set.
This does of course require you to have people you trust who have some way to verify they got the 'original'
copy of the certificate, and doesn't preclude using the equivalent of modern certificate authorities if desired.
It simply provides 3rd party verification if something appears to be up.
If you need a good example of how this might be carried out, look up 'WASTE', then imagine combining that with slashdot's rating system utilizing the old Kevin Bacon skit about 6 degrees of separation. That should provide secure peering with a layer of trust model that would dwindle the farther away from you a 'trusted individual' is positioned. It's not as 'cheap' in terms of cpu, disk space, or memory requirements as the current system, but it would be harder to exploit than the current centralized system.
If there's a single systemic problem with HTTPS, it's that we're still largely relying on Certificate Authorities which charge a lot of money. The expense and complexity discourages people from using SSL more ubiquitously.
I'm not saying it's a perfect security scheme, but my point is that the single biggest problem with it is that we're not using it enough.
From a technological point of view, it's a good protocol. It works and when implemented correctly, it's very secure. However, a PKI is not much about technology. It's mostly about organisation. In other words, it's not about PK, but all about I.
And that's were most things go wrong. Yes, Heartbeat was about technology, but people who paid attention moved away from OpenSSL a long time ago. There are more than enough alternatives. GnuTLS and PolarSSL for example. Apple's gotofail was also about technology, but name me one piece of software that is 100% bug free.
The real problem with HTTPS is how it's organized. When I install a browser (or get one via the OS), I also get a shit load of CA's which I'm supposed to trust. CA's from China, Turkey, Taiwan and other countries from which I don't even speak the language. I will never need a certificate from one of those CA's, because I will never need a secure connection with any website protected by their certificates. If the people from Iran were wise enough to realize that they don't need Diginotar because they don't speak Dutch, they would never be at risk because of Diginotar's epic failure. The first thing I do when installing a web browser is get rid of all the irrelevant CA's. Just to be sure, just to be safe.
And that's what's wrong with HTTPS. That's what needs to be fixed. Trust shouldn't be imposed by a browser maker. Trust should be earned.
It doesn't have to be like this. All we need to do is make sure we keep talking.
Most all the responses I see to this story so far are kneejerk response to the summary, not very relevant.
Your main point is a good one - there are good reasons for the complexity.
I'm curious about the other thing you suggested. People have been making and breaking ciphers for thousands of years. For thousands of years, every algorithm* has been broken. Why would you say today's won't be? MD5 was believed to be secure for a long time, now it's thoroughly broken. What evidence is there that SHA-3 doesn't have an undiscovered weakness, given that every other algorithm has had some?
Further, quantum computers have now actually factored semiprimes, proving the theorems. So we already know how to break existing keys, given large quantum computers. At this stage, with so little knowledge about what medium-scale quantum computing, is it not hubris to think our kids won't come up with ways to use the new powers of quantum computing to solve problems that we don't yet know how to solve efficiently?
* "every algorithm " meaning all algorithms useful for this purpose. OTPs specifically, aren't applicable to the problem, though they are unbreakable if properly implemented.
These guys have been refreshing and flogging variants of this paper for a year or two. Annoying, particularly as they continue to parrot some inaccuracies that have already been refuted many times by the security community (such as the "1000s of CAs"). This is just a new incarnation of their paper; I liken it to 'kicking a dead whale down the beach.'