Slashdot Mirror
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.
As long as we rely on CAs for trusted certificates SSL will always have an easily-exploited weak link.
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.
I think it is wrong to claim HTTPS is flawed by blaming the underlying software vulnerabilities. The post didn't mention anything about how HTTPS itself is flawed at the protocol level, or its design is flawed.
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.
Like all technology, it's really about what you are trying to protect. For most people and applications HTTPS is probably enough, if you're protecting multi-billion dollar transactions or infrastructure then you should use something stronger. Think of it like door locks -- all are flawed, but it's not worth spending $1 million on security to protect a $300,000 house.
I'm reasonably satisfied with the level of protection from HTTPS for my twitter posts and even banking.
As an aside, is the Microsoft HTTPS implementation any better? It seems like only open source and Apple have been implicated in the HTTPSgate scandal.
That's why I prefer to use a VPN
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.
That's it. Nothing to see here.
Well done, authors obviously spent a lot of time on it. Splitting implementation and deployment was refreshing to see.
Fundamental problem is aggregation of power/value is an irresistible beacon of abuse. From criminals to states the more value protected the bigger the effort to coopt the system.
I have two "practical" ideas which might help slightly..
1. Replace CA's with DANE or something like it. We already have global view of naming.. Trust should flow from ownership of names as a standard feature of domain ownership.
While this reduces overlapping CA craziness it just replaces headaches associated with one trust anchor with another... however with non-overlapping view there is a lot more that can be done to distribute trust.
The other problem deployment of DNSSEC without first fixing DNS DDOS amplification is in my view negligent and irresponsible.
2. Use "zero knowledge" authentication protocols in addition to or instead of CAs. I have an account on some device or some service somewhere let my credentials be source of trust to protect my session. This solves the aggregation of power issues of planet wide trust anchors and allows people to secure their shit without having to screw around with certs.
All of the technology to implement this exists... all browser vendors need to do is get off their asses and commit the TLS-SRP patches in their ticket systems.
This is no panacea there are two issues using credentials for trust imposes which cannot be solved.
1. Your 'identity ... (e.g. username)' is necessarily transmitted in the clear. While you can play games with reversible transforms or grouping the basis for deriving your identity is transmitted.
2. There is no difference between storing a password and a password hash. Since we are establishing proof of mutual possession servers need to reversibly protect their passwords. Hashes no longer work.
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.
Maybe you meant TLS? how do you even confuse the two....isn't this a nerd site?
The HTTP layer was never the problem, the fact that it is the most used protocol nowadays should not excuse you from confusing TLS/SSL with HTTPS...
PKI: Don't trust that random stranger on the Internet to sign his own key, trust this other random stranger on the Internet to sign it instead.
Security prevents casual theft. When vulnerabilities are found, we fix them, to maintain a basic level of security. Sufficiently determined criminals may be able to break your security anyway. With https, the route that is always open is directly monitoring your computer directly, where the data is unencrypted. They are, after all, criminals - and it is the job of our governments to help chase them down and put them out of business.
What is frightening about the today's situation is the discovery that many western governments are among the worst of the criminals. Governments have more resources than criminal organizations, and (short of vigilantism) there is no one who can enforce the law on the government officials involved. This is the real dilemma we face, as we consider our security systems.
Enjoy life! This is not a dress rehearsal.
I drew a diagram on my office wall to help explain the difficulties of "Trust" in the internet/cloud world to my wife. Her problem is unique to a small subset of Americans.. her profession (Licensed Clinical Social Worker) is granted "Privileged" communication status similar to Attorney/Client rights... This limits her choices as to who and what can be trusted as a computer system. In bold RED marker I circled all of the entities that would need to be "trusted" to one extent or another to keep her data secure when placed onto the internet/cloud. It makes it really difficult to communicate with clients when the ubiquitous solution is the least secure. Her simple answer when faced with current choices was NO, it's my license at risk why should I trust anybody. At the end of the conversation, she asked me to build her something that could be trusted... (good-bye free time, sex life, hobbies, etc...)
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.
Or do it like we do on europe:
rely on chip, instead of magnetic stipe.
(Which can't get skimmed).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Something better that works huh :
o The Tor network is trustworthy enough. (Unlike the flawed untrustworthy CA system.)
o .onion is end-to-end. (Unlike the third-parties CA system.)
o .onion is always strong encryption. (Unlike HTTPS where encryption strength varies.)
o .onion is high security at zero cost. (Unlike the CA payware system.)
o .onion is only accessible with a secure enough browser, TorBrowser.
(Unlike HTTPS which is accessible with browsers of varying security.)
o .onion is slightly slower because it takes it's time to carefully protects
the privacy. (Unlike HTTPS which is quick and always leaks meta-data.)
http://it.slashdot.org/story/12/07/25/1612236/father-of-ssh-says-security-is-getting-worse
The article linked from that Slashdot story states:
So is the solution just to take everything off the web entirely? But then I realized that can't be right, and the real article is here.
SSH
The "key continuity management" model, used by SSH and by HTTPS sites using self-signed certificates, is vulnerable to a day-one man in the middle without some out-of-band method for verifying the key fingerprint. Tatu Ylonen's article didn't appear to describe in detail how this might be changed.
Have a key get "known" may be an add-on, but some sites use hundreds of server keys and change them out often.
Then let an organization be the CA for its own registered domain, and let it issue certificates for these "hundreds of server keys". DNSSEC with DANE was supposed to do this, at least at the same assurance level that domain-validated certificates are intended to provide.
Other tasks might work with an out of band method for distributing and authenticating keys.
Good luck describing that out-of-band method for distributing the key for every single web site you visit. The only decent proposals I've read are the status quo (X.509), DANE, and Perspectives. Perspectives checks a server's key fingerprint through multiple routes on the Internet. This detects a man in the middle even with unknown-CA certificates so long as it isn't between the server and its only uplink to the Internet (called the "Lserver attack" in the Perspectives white paper).
been going for years.
"If any question why we died, Tell them because our fathers lied."
It would have provided just that type of security. It had two problems: The amount of public key crypto could not easily be handled by servers of that era and merchants did *not* want to give up access to customer credit cards (SET would have made the merchants a pass through for encrypted card numbers they could not directly access). The latter point is not mentioned in Wikipedia, but was ultimately the source of merchant inertia in adopting SET.
Had SET been adopted, we would not be seeing massive compromises of credit cards through insecure merchant systems. Instead we got SSL, very good at encrypting the transport, not designed for secure management at the financial transaction level.
See http://en.wikipedia.org/wiki/Secure_Electronic_Transaction, Wikipedia
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.'
HTTPS isnt flawed. Any protocol like this would have implementation issues. These are implementation problems, not a problem with HTTPS design itself.
DV certs are incredibly cheap.
But the certificate is not the only cost of upgrading from HTTP to HTTPS, as not all browsers still in use support Server Name Indication. Without SNI, a browser can see only the first certificate associated with port 443 of a given IP address, which requires your domain to have its own IP address as opposed to name-based virtual hosting. In the era of IPv4 address exhaustion, some hosts have started charging $60 per year for a dedicated IPv4 address (source: godaddy.com). The leading SNI-ignorant browsers are probably Internet Explorer on Windows XP and Android Browser on Android 2.x. But if you can get through to Roulette without a certificate error, your browser is capable of SNI and has StartSSL.
On the other hand, you probably shouldn't be sending anything sensitive over the Internet to IE/XP anyway because XP isn't getting patches anymore. So depending on browser usage share in your audience's countries, it might be time to bite the bullet and upgrade small sites from HTTP to HTTPS+SNI.
http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
nothing :)
SRP enables strong security from weak passwords. It does NOT rely on Certificates Authorities at all.
Never heard of it? Then have a look at
https://en.wikipedia.org/wiki/...
A bigger problem is securing our username and password that we use to login over the SSL connection.
The username and password are vulnerable because:
1) They are typically exposed on the same system that handles the connection, which makes them vulernalble to trojans, key loggers, hackers, etc.
2) They must be managed by humans or vulnerable password managers.
3) They don't authenticate the server, making the user completely reliable on SSL certificate mechanism for authenticating the server, which as we are aware has a number of weaknesses including most browsers allow a user to ignore a bad certificate and bad certifcates can be trusted through accident or malicious intent.
Having a well designed protocol underneath SSL to authenticate between the client and the server that:
1) is key based
2) has bidirectional authentciation
3) allows authentication to be done on an isolated computer or dedicated security device
Would go a long ways towards improving security.
Maybe there is an existing protocol that provides some of this, but I don't believe OAuth on its own does.
I cannot resist promoting my own excellent paper about TLS hardening. Copying abstract:
This document presents TLS and how to make it secure enough as of 2014 Spring. Of course all the information given here will rot with time. Protocols known as secure will be cracked and will be replaced with better versions. Fortunately we will see that there are ways to assess the current security of your setup, but this explains why you may have to read further from this document to get the up to date knowledge on TLS security.
We will first introduce the TLS protocol and its underlying components: X.509 certificates, ciphers, and protocol versions. Next we will have a look at TLS hardening for web servers, and how to plug various vulnerabilities: CRIME, BREACH, BEAST, session renegotiation, Heartbleed, and others. We will finally see how the know-how acquired on hardening web servers can be used for other protocols and tools such as Dovecot, Sendmail, SquirrelMail, RoundCube, and OpenVPN.
We assume you already maintain services that use TLS, and have basic TCP/IP network knowledge. Some information will also be useful for the application developer.
When people use HTTPS these days, it's not to ensure that they are definitely communicating with their bank, that is.easily verified with the url, what people want to.ensure is that their data is secure between these two points. HTTPS needs ditching totally and just replaced with POP end to end encryption on the fly, something unbreakable so that government agencies can stop walking all over our privacy.