Comment by moxie | Hacker News Reader

Comment by moxie | Hacker News Reader

This compromise was detected by Google because they have hard-coded "certificate pins" in Chrome which specify which CAs the browser should expect to see when connecting to Google.

This type of "pinning" is the only technique that we know of which has actually detected a CA-assisted MITM attack in the wild (a few times now). So it works really well, but only if you're running Chrome, and only if you're connecting to Google (or the few other pinned sites hardcoded in Chrome).

It doesn't scale well because not every website can (or is willing to) hardcode their CA information in browser binaries, the pinned information has to expire at some point (otherwise you can never change your CA), sites are still vulnerable to their own CAs, and it only works in browsers which are willing to maintain this hardcoded list of pins in their client binaries.

Trevor Perrin and I developed a dynamic certificate pinning solution called TACK (http://tack.io) that is designed to address all of those issues. It's a fully specified TLS extension; all we need are browsers to support it.

If you're interested in whats been going on with the CA system, "SSL And The Future Of Authenticity" is a Defcon talk where I discuss some of the problems with CAs, and even interview the original SSL protocol author about them: https://www.youtube.com/watch?v=8N4sb-SEpcg

Sounds good, great even.

all we need are browsers to support it

So why isn't it already? Does it need public support? If so, is there a coordinated way we can encourage the vendors to acknowledge it?

The somewhat difficult thing about a lot of this stuff is that its future is really in the hands of the browser vendors, not the IETF, W3C, or anyone else. What they choose to do or not do is all that matters, so there's not much more that any of us can do other than make suggestions and see what happens.

My experience thus far is that most browser vendors only have one or two people working in this area of their code base, and those people are so overwhelmed that they spend most of their time just treading water. SSL cipher suite problems seem to be absorbing most of their time lately.

Google has a larger set of really good engineers working in this area, so for the most part they seem to take the lead. Right now, my impression is that they're pretty all-in on Certificate Transparency. The major roadblock with CT is that it requires all CAs to willingly participate. If that's even possible, my sense is that it's a long road, so I would love to see Chrome incorporate TACK in the mean time (and Trevor has even written the patch) while they try to drive CA adoption.

But ultimately, how they decide to spend their time is up to them.

Rather than persuading CAs to implement Certificate Transparency, how about sorting CAs into groups by jurisdiction and displaying different icons or colors for low/medium/high security, corresponding to having signatures from 1, 3, or 5 complementary jurisdictions? This would give CAs a financial incentive to cooperate: people are less likely to buy 3 or 5 certs at full price, so they could capture significantly more market-share by teaming up and offering to sign each other's customers for half or quarter price. It's (more) free money for them and it significantly complicates the process of performing a MITM, especially if you aren't the USA.

EDIT: Nevermind, I think I understand why it wouldn't work: independently verifying customers is hard, so they would either have to trust each other or spend a nontrivial amount of money verifying each customer. If they trusted each other, the additional security would be worthless, since the host country of the principal CA could just order them to lie. If they each verified the customer independently, they would each incur the usual amount of fixed cost, so they couldn't offer much of a discount.

TACK works without coordination between the 1/2-time TLS maintainer at a browser and the (elaborate) UX/UI team at that browser; it's something you can implement in the backend.

The UX for certificate trust on the Internet is dreadful and essentially hasn't evolved since the late 1990s. It is badly due for an overhaul. But we can get TACK working today; UX changes could take years.

Well since 1990s we at least got EV, which is something.

EV was an exercise in money making, not security.

all we need are browsers to support it

This makes it sound easy: after all, there aren't many browsers, but really the problem is that everything that talks SSL needs to support it. Browsers are the starting point, after that I guess the OS-level libraries, then everything else.

No. It would be nice if backend TLS tools supported TACK, but they don't need to for TACK to be hugely valuable, both by increasing the security of browsers themselves and by drastically expanding the surveillance network we have to detect bogus certificates.

What's so incredibly fucked up is that its left to you as a guerrilla-hacker-promoter to evangelize a model that should have been used in the first place, and already adopted long long ago in the second.

Good for you for doing the work, though. You rock.

Isn't this also accomplished via the SSL Observatory functionality in HTTPS-Everywhere?

AFAIK SSL Observatory only sends the certs you receive to a EFF server to be included in a DB, it doesn't protects you against MITM's.

A great add-on for Firefox that helps you to detect any possible MITM is Certificate Patrol (https://addons.mozilla.org/en-US/firefox/addon/certificate-p...), it may be a bit annoying for some people though.

X.509 is broken, it only protects you against casual script kiddies on Starbucks. I know about people who deleted the CA directory from their systems, in my case I prefer to use Certificate Patrol (both in Firefox and Thunderbird) or use self-signed certs and then pgp sign the fingerprint.

>I know about people who deleted the CA directory from their systems, in my case I prefer to use Certificate Patrol (both in Firefox and Thunderbird) or use self-signed certs and then pgp sign the fingerprint.

How does the latter work? Is that possible with Firefox?

Yeah sure, if your system doesn't have any CA cert installed you will be asked to accepted every new certificate you receive when you start a TLS connection, and you can permanently accept it. Would be pretty manual, since you also need to ask the issuer to digitally sign the fingerprint and then check it...

How are TACK and convergence related? Is one the better version of the other?

I think TACK is targeting browser vendors, and convergence is targeting browser users. But it doesn't look like it has been updated since 2011 (still in beta, too), and there's no add-on for Chrome.

So basically TACK is a side channel that verifies cert fingerprints right?

The problem with PKI is that there's no collision detection. e.g. Under the same PKI same CN should only have exactly one cert.

Sounds fantastic. It should be possible to secure a site with something that can be taken offline and stored with physical security.

Hi Moxie, What do you think of the certificate transparency project they mentioned? It is quite a bit different than pinning and doesn't have any of the scalability issues.

If you haven't heard about it, it basically requires that a certificate be observed in a central database for the browser to accept it. The server provides a proof (signature) of it being in the database when it passes the cert to the client so no extra connections are required.

This makes it immediately known when another cert is issued for a site.

CT requires all CAs to willingly participate. They are, obviously, less than willing:

https://groups.google.com/forum/#!msg/certificate-transparen...

(Symantec is VeriSign)

The efficacy of CT will largely hinge on whether Google can get CAs to participate. Even if they can, it'll be a long road (it already has been), and TACK is immediately deployable in the short term.

Something like pinning for S/MIME would be great, too…

Is it necessary to get every cert? Getting the CAs to participate would be the best way, but it seems there are workarounds that will result in a large number of certs to be listed, though not all of them:

"Google is currently operating a Certificate Transparency log, and we are filling the log with certificates that we retrieve while crawling the web. We are also actively working on monitoring and auditing software."

http://www.certificate-transparency.org/faq

It doesn't require all of them. They just need enough to reach a critical mass at which point they can start rejecting.

Also, a client can submit their cert to the log regardless of CA support. The only thing CA support is needed for is automated submissions.

Reply on news.ycombinator.com