What you want is Moxie Marlinspike and Trevor Perrin's TACK.
It is already the case today that for Chrome and Firefox users, a compromised CA can't easily hijack connections to Google Mail. Not only that, but any attempt to hijack Google Mail connections in the large will run aground on Chrome and Firefox users, who will not only not accept the rogue certificates, but will also alert Google, which will put a gun to the head of the CA.
The feature that enables this is called certificate pinning. It works well for small numbers of high-profile sites, but requires manual intervention on the part of browser vendors.
TACK pushes certificate pinning out to site operators. It works like HSTS: the first connection to a website is trusted, and that connection loads up state that the browser holds. Subsequent connections check for consistency with the first connection. Dynamic pins, or "tacks", make dragnet surveillance of all sites asymptotically as risky as spoofing Google Mail. The attacker is nearly certain to accidentally catch someone with a tack loaded, and at that point the game is up: the attempt to present an otherwise-valid certificate that violates a tack is a smoking gun, to which Google and Mozilla ca respond with their own firepower.
The nice thing about TACK is that it works alongside the CA hierarchy, and even derives some value from it. A tiny fraction of the Internet could adopt TACK and still make life much harder for attackers. The effort required from site operators is small, and the whole system is invisible to end-users.
Fixing the CA hierarchy is a lot less sexy than ground-up rewrites of the whole Internet security model. But the ground-up rewrite is never going to happen, and the incremental fixes are not only doable, but doable by the kinds of generalist developers who are champing at the bit to stick it to the NSA. The biggest security problem on the Internet isn't protocols; it's browser UX.
Not only that, but any attempt to hijack Google Mail connections in the large will run aground on Chrome and Firefox users, who will not only not accept the rogue certificates, but will also alert Google, which will put a gun to the head of the CA.
This is one of those "Things which somebody would probably bring up at an anti-trust meeting if anybody at an anti-trust meeting had the foggiest clue of what was going on", incidentally. (The hypothetical threat is "You give our web properties a better SLA than anyone else in the world gets, or we will use the coincidental fact that a large portion of the world's web traffic runs code under our control to end you.")
It's funny, people (including me) always thought that Google's big swinging Wand of Annihilation was google.com, but now they have at least four of them.
It's not just google properties, the Strict Transport Security sectionof the chromium dev docs [1] lists multiple properties they do this for (for example, twitter and paypal), and it appears you can specify your own as well through the command line (and probably elsewhere).
I believe patio meant Google/Mozilla going to the CA and saying 'You duplicated our cert, you better explain or we will stop trusting you in our browsers'. Which would end the CA, of course. As they deserve to.
I took it as an implication that Google properties were getting special treatment by Chrome. I'm not sure how Chrome blacklisting a CA could be construed as anti-trust, even if it essentially killed the CA, because there's plenty of healthy competition in the browser space. They could just switch to Firefox, and not even lose the extra protections they were getting since Firefox pins google property certs as well.
And here I thought the "gun to the head" was more of a "smoking gun" -- as in, hey, that MITM attack you thought you could get away with? Yeah, we noticed.
Why would that be an anti-trust concern? What Ptacek is referring to is a CA compromise being detected. At that moment the CA would be, quite correctly, with a gun to their head as their entire purpose for existing -- their whole business model -- would have evaporated.
"The biggest security problem on the Internet isn't protocols; it's browser UX."
I think it is security UX in general. Anything around certificate issuance/life cycle (SMIME or PGP signed/encrypted mail), PGP key exchanges, etc. That problem has not been solved.
TACK looks cool. I read through the RFC and have some questions ....
At first I thought an active MITM could drop TACK negotiation from ClientHello and wait 30 days until pins expire, but as I read it, I think that should result in a "contradicted" pin.
You could do browser profiling though, and only MITM clients which don't send a TackExtension in the ClientHello, or behaviourally look like IE, say. I wonder if it would have been better not to indicate that client supports TACK? (Maybe constraints not obvious to me).
The other thing I'm not sure about is overlapping TACK handling. I don't see what's to prevent an MITM from adding an additional new TACK of their own in the ServerHello, gradually superseding the "valid" TACK. That would take like 60-90 days though.
This looks like a massive improvement, although I wonder if it actually protects clients which do not support the extension?
I think I see, so one client advertising TACK and one not?
Right, that would work, assuming there are people going around doing it for every web site (the TACK police!). I can easily see that happening, it is just the kind of thing moxie would do, say.
It still seems to me that it would be simpler if the client just didn't advertise the extension. I am probably missing something though.
>This looks like a massive improvement, although I wonder if it actually protects clients which do not support the extension?
Only indirectly through network effects. It's much harder for a valid attack certificate to stay undetected in the wild when a subset of the people you might attack are running TACK. You're right that it might not help clients if the MiTM software intelligently avoids attacking TACK-capable clients.
I'd say to just get the word out. Around this time last year I was working at a security company and personally pushing for establishing automatic TACK protection for our clients, passively sniffing certs for SMB networks and learning which ones were good, but no one else knew what I was talking about, I couldn't convince them the project wasn't dead, and at the time I couldn't answer the question "how do we deal with a legitimate change in browser cert."
If you can grok TACK better than I do at the moment, start writing patches for web servers.
I may not be understanding it clearly but won't a non-browser app be better off simply pinning whatever certificates/public-keys etc. directly in the binary of the app?
The key idea of TACK is that it puts controls of pins in the hands of the site operators. The goal is to protect trustworthy site operators from rogue or compromised CAs (e.g. Diginotar, Comodo). The site operators have a better idea than anyone of what keys and certificates are correct for their site.
Pinning directly in the app puts trust in the developers of the app instead, which is indirect and prone to lag. It is also generally fragile (have to issue app updates for cert revocations) and can be hard to scale. How many secure sites does your app need to connect to? Is it flexible, unknown? How are you, the app developer, going to validate those certs beyond relying on the CA PKI? (and then you're back to square one).
What are these "site operators" that you speak of? If facebook or google or twitter is publishing a native app, they can embed any credentials/certs/keys etc. they want into their app. It's not a great leap to think of a cert/key renewal mechanism via DNSSSEC or some other proprietary mechanism.
Essentially, it's the same as google pinning their certs in the chrome browsers. Except, since you control both end points (your app and your own servers), you don't have to participate in the broken (trust based) PKI system at all.
I think the comparison is that you don't meaningfully authenticate the first connection.
This is wrong, though: although new users will, in fact, be temporarily MITMed, all returning users will see a big scary warning page that will cause them to (perhaps automatically) report the problem to their browser vendor. Google/Mozilla will promptly drop the offending URL into the malware-sites list, and the new users will thereby be rescued as well.
That's true, and also, those first connections are authenticated (they're just not authenticated perfectly). There's a difference between weak authentication and no authentication, as aggravating as it is to point out.
We're talking about referring to Telehash's approach as "ubiquitous encryption" with "self-consistent authentication" but nobody seems to agree on what authenticating an identity means in the first place.
Pinning encryption to addressing solves those problems at a lower layer, and leaves phishing attacks to be solved separately. I don't know that anything I'd call "perfect authentication" can be solved within the X.509 framework.
Could you elaborate what you mean by "pinning encryption to addressing"? Do you mean DNSSEC? Doesn't that suffer from the same third party trust problem as any other PKI based system?
Public key cryptography doesn't require X.509's third party trust model, but as the author of the article points out, PGP key exchange is not quite as simple as just trusting the CAs your browser vendor decided you should trust.
Telehash is taking an approach that completely sidesteps the problem of human-memorable names, though. It uses the public key fingerprint as the "network address" of a node in a DHT. The Telehash address is globally routable, like an IP address, but there is no MITM possible, because only a node with the private key generating the address (fingerprint) can communicate at all using that address.
There is still the problem that humans don't want to type in an IP address, let alone remember something unwieldy as 9ba9c175c3c26af9df5c8163ea91d4ae4eca59ba95d66deb287c89ea0c596979. But deciding whether to trust that key is distinct from verifying data is signed with the same fingerprint.
Yeah, that's what I meant (and couldn't properly articulate).
So the difference is the reporting mechanism, that allows a powerful organisation to make meaningful threats to protect others?
Because in [Garfinkel 2003] it's similar: returning users get a big, fat warning, but they can't meaningfully do anything about it on their own, except not trust the other side.
TACK is really cool, but is it still pushed to the vendors? (Or even, are the vendors interested?). I've seen patches floating on github, but alas, not that much activity lately.
The vendor space, considered seriously, consists of Google, Mozilla, Apple, and Microsoft.
Of those four, Google is pushing hardest for CA-compromise countermeasures.
Google's current preferred solution is Certificate Transparency. I don't love CT, for reasons very similar to those that the typical HN reader would come up with after reading it, but it's still a step forward.
We sponsored development of some TACK code last summer, but none of the browser vendors are itching to integrate TACK. Google has nice things to say about it, but "backburnered" would be a fair summary of where it stands right now.
If TACK can rewrite the trust model away from the CA and into the state of subsequent connections, we won't need the actually CA. Self-singed certs are equally fine to establish trust after first connection.
If however we do use CA's as the trust model in order to trust the first connection, then TACK is nothing but a policy system to attempt keep CA honest. Users would still need to put their trust to third-parties that they never meet, and who's priorities and objectives are unknown.
I see TACK as a decisive mitigation for the biggest danger posed by CAs today (that they enable global passive adversaries to conduct dragnet surveillance), and as a step towards a workable web-of-CAs system.
I do not believe in pure peer-to-peer schemes as workable solutions, but I do believe that we could in 5 years have a system where I can trust ACLU first, and then Verisign as a fallback.
Nobody is claiming that it provides perfect security, but it massively reduces the attack window for successfuly certificate spoofing, while turning any failure to hit that window into a big red blinking alarm sign.
That threw me off too. But I think they may mean the first visit ever. Meaning it would be something they could control and validate before releasing to the public?
This has been discussed multiple times now [1], but TACK is not a solution because:
1. It amounts to a preservation of today's pay-for-security system (the no-so "nice thing" you mentioned), which is not necessary. It is not necessary, thanks to distributed databases like Namecoin, to have to pay for SSL certificates anymore (or fax credentials, or any of that).
2. It doesn't offer a strong mathematical proof of authenticity the way a blockchain-based solution does. [1][2]
I wonder whether there is any meaningful difference between the effort it would take to implement TACK securely in a way that doesn't involve paying what amounts to protection money, and the effort required to use a blockchain-based solution.
It wouldn't surprise me in the slightest if the blockchain-solution were actually simpler to implement and deploy. Fetching public key fingerprints involves a single HTTP request that returns some JSON. That's about it.
Don't we still have to then trust whoever is hosting the server returning the json? I guess you could verify with multiple servers, but that doesn't really guarantee anything and increases the requests.
The other option is to a full namecoin client with an up to date chain, correct?
> Don't we still have to then trust whoever is hosting the server returning the json?
It's assumed that you find yourself (or a close friend) trustworthy.
DNSChain is designed to be run by individuals, with no powerful deciding authority (like browser vendors) deciding who you should trust (as with CAs today).
Today, you trust the least trustworthy of hundreds of organizations that you've never heard of.
With this proposal, anyone is free to trust whoever they want, and they can change that instantly without any browser updates or anything along those lines. It's about as trustworthy as you can get.
Blockchain protocols: the Ron Pauls of distributed systems design.
Replacement of DNS with a blockchain protocol is never going to happen. It's hard enough to talk DNS operators out of baking the CA system into DNS, despite the utter inapplicability of DNS to that problem. DNS has a fierce, powerful status quo advantage.
If you believe strongly that blockchains are going to be the future of global networking, a better plan would be to build a system that ignored the DNS and used a blockchain protocol instead. For instance: the DNS doesn't play any role in matching Google search terms to SERPs, nor does it control how AIM matches names to IM accounts, nor does it control how IRC matches nicks to receivers.
Forklifting out giant chunks of the Internet is a bad plan. Deprecate the Internet and build a new layer on top of it. Eventually, TCP/IP will find itself in the same role as Ethernet; it's inevitable.
> "Deprecate the Internet and build a new layer on top of it."
That's sorta what's taking place (not the entire Internet, but a part of it that's not serving us well). It's interesting that nearly that exact language was used when DNSChain (back then "DNSNMC") was introduced:
[therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security
How many times has humanity heard that refrain repeated?
> "For instance: the DNS doesn't play any role in matching Google search terms to SERPs, nor does it control how AIM matches names to IM accounts, nor does it control how IRC matches nicks to receivers."
You seem to not understand that DNSChain is not just a DNS server. It also is a RESTful HTTP API and interface to the blockchain. This means using HTTP, not DNS. DNS is just icing on the cake (and not "throwing the baby out with the bath water").
BTW, some of those things are already starting to happen. For instance, there's PoC Pidgen fork that works with Namecoin, and also a working Bitmessage + Namecoin client out there:
It is already the case today that for Chrome and Firefox users, a compromised CA can't easily hijack connections to Google Mail. Not only that, but any attempt to hijack Google Mail connections in the large will run aground on Chrome and Firefox users, who will not only not accept the rogue certificates, but will also alert Google, which will put a gun to the head of the CA.
The feature that enables this is called certificate pinning. It works well for small numbers of high-profile sites, but requires manual intervention on the part of browser vendors.
TACK pushes certificate pinning out to site operators. It works like HSTS: the first connection to a website is trusted, and that connection loads up state that the browser holds. Subsequent connections check for consistency with the first connection. Dynamic pins, or "tacks", make dragnet surveillance of all sites asymptotically as risky as spoofing Google Mail. The attacker is nearly certain to accidentally catch someone with a tack loaded, and at that point the game is up: the attempt to present an otherwise-valid certificate that violates a tack is a smoking gun, to which Google and Mozilla ca respond with their own firepower.
The nice thing about TACK is that it works alongside the CA hierarchy, and even derives some value from it. A tiny fraction of the Internet could adopt TACK and still make life much harder for attackers. The effort required from site operators is small, and the whole system is invisible to end-users.
Fixing the CA hierarchy is a lot less sexy than ground-up rewrites of the whole Internet security model. But the ground-up rewrite is never going to happen, and the incremental fixes are not only doable, but doable by the kinds of generalist developers who are champing at the bit to stick it to the NSA. The biggest security problem on the Internet isn't protocols; it's browser UX.