Firefox 32 Supports Public Key Pinning

http://monica-at-mozilla.blogspot.com/2014/08/firefox-32-supports-public-key-pinning.html

by jonchang • 12 years ago

188 100 12 years ago

monica-at-mozilla.blogspot.com

cornewut• 12 years ago

Maybe FF and Google should just become CAs? It would remove the extra step as currently both pinning and registering with existing CA are required?

bottled_poe• 12 years ago

Why should we trust them?

belorn2• 12 years ago

With the current setup, people are trusting mozilla/google to: Give you the correct software, Update silently, Determine which CA certificates to trust by default, and Determine which certificates are valid by pinning.

The CA is trusted to do: Determine which certificates are valid.

logicallee• 12 years ago

Yes, why should we trust our browser company with the security of our SSL connections. That's like locking your car with a key made by the company that manufactured it!

Maakuth• 12 years ago

That must be a legal minefield as they'd then be in competition with established CAs that use their browser as sort of a platform (unfair competition or something). Being a CA also seems to be a messy business, I don't now if Mozilla would have the resources to do that. Google seems to have a CA of their own, but they don't seem to be signing certificates other than their own with it.

tptacek12• 12 years ago

I've been told by people on those teams that the legal issues behind this (or any other interference with the CA system) is a big concern.

lucb1e6• 12 years ago

They are.

Google for sure, and Mozilla maintains a list of them that ships with Firefox. If that isn't the ultimate level of trust (deciding which CAs your browser will trust) then I don't know what is.

tptacek12• 12 years ago

Both Google and Mozilla have their hands in some ways tied about which CAs they support. Their browsers have to work on the Internet as it is, not the Internet as they want it, and so both certainly include CAs that their owners would prefer they didn't.

Also, of course, there's the fact that both Mozilla and Google give their users control over which CAs they include. The UI for that functionality is unfortunate. But on the other hand, if generalist developers really want to stick it to NSA, that's a good project they can work on without screwing over users with bad cryptography.

xroche• 12 years ago

What about DANE (http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...) ?

pilif2• 12 years ago

When you support DANE, you trust the various governments responsible for the various country domains to not wanting to MITM owners of said domains.

I'm sure everybody has a different subset of governments they would be putting in the "trustworthy" bucket and it's not up to the browser vendors to make a political statement there.

Browser vendors would have to trust all governments equally and AFAIK, none of them have publicly stated what their policies regarding MITMing DNSsec is, nor how well they protect their DNSsec signing keys.

CAs have to follow quite rigorous protocols if they want to be included in the browser default list and they have all financial incentives to comply.

Governments don't have to follow anything and even if they had, they have all the incentives not to comply.

This is why DANE, while otherwise sounding like a really good idea, is ultimately doomed to failure. No browser wants to take responsibility for less-than-stellarly performing governments and no browser wants to make a political statement by only supporting DANE for certain top level domains but not others.

Qantourisc• 12 years ago

Suppose you could use both normal PKI + DANE ? This way you both need a signed certificate and a MITM for DNSsec. Also in some cases, DANE is "enough". (Unless they start to MITM all websites.)

exo762• 12 years ago

CA model is broken (>500 of CAs, race to the bottom in terms of price, security is not a part of their business model). DANE is no better. What we really want is to be able to withdraw trust. There is no point for me to trust some Iranian CA. Why should I want to trust one? Today - I have to trust it, because you can't just remove CA without breaking a percentage of websites for you. And you can't normally erase CA from existence, because on single CA rely many customers and each of them will have broken website.

Please read about Convergence by Moxie Marlinspike. It solves the removing of trust problem.

fulafel2• 12 years ago

The percentage of government controlled TLDs is rapidly declining though. And making the CA an integral and evident part of the domain and url is a vast improvement to the current state of affairs.

Is the USA-controlled DNS root a problem here? Hopefully interference would require highly visible and suspicious changes to the DNS root.

asdfaoeu• 12 years ago

The difference is you only have to trust the one your domain ends in and you have to trust one anyway.

smutticus• 12 years ago

DANE is just the hash of a site's cert stored in DNS as a TLSA record. I get that it is then signed with DNSSEC, but I don't get how this involves any governments. It's still the site operator putting the hash of their cert in the TLSA. Can you elaborate how you're 'trusting governments' when you're using DANE?

IMO it's much easier for an [NSA|GHCQ|etc] to compel a CA to give site operators broken certs than it is to deal with site operators rolling their own certs and using DNSSEC/DANE. Even if Sweden is controlling .se, example.se can create their own cert and stick its hash in their DNS. Does your model of 'trusting government' then enter into the picture because their entire domain is then signed by .se?

eplsaft4• 12 years ago

Proposed ideas must be compared to current situation, not a utopia. DANE is not the best solution. Trusting governments is a failure right there. But it is an improvment to the current mess.

cpeterso• 12 years ago

The problem I've run into with public key pinning is captive portals. Mobile operating systems or browsers need to provide a better user experience for captive portals.

kijin2• 12 years ago

Don't captive portals already have a problem with every HTTPS website? I don't see why PK pinning would cause any problem that doesn't already exist.

illumen• 12 years ago

Yeah, many captive portals do have a problem with HTTPS. From my experience in 50+ hotels in the last years.

giovannibajo14• 12 years ago

iOS have had good user experience for captive portals since a long time (iOS 3 I think), and also Mac OSX. They automatically detect when a captive portal is present by doing a background connection to some Apple-owned property and trying to download a small text file; if it fails for any reason, they bring up a modal panel showing the captive portal and letting the user login; then, they detect when the Internet access is active and close the panel (or, lately, let the user close the panel with a "Finish" button). What's more important is that the whole operating system / applications are not given the signal "network is on" until the whole process is finished, so you don't get one dozen of failures from applications that try to refresh in background and can't access their backend servers.

This said, I really hate the fact that the WiFi alliance has left us in this very sad state. Like many similar committees, they move too slowly; captive portals arose from a real-world problem that wasn't solved by the WiFi standard, so people had to come up with weird DNS/HTTP interceptions that fail in so many regards it's not even funny. If there's somebody to blame, it's not operating systems for not adding weird heuristics like Apple did, but Wifi Alliance for not bringing to the market a good solution for handling hotspots soon enough.

khc2• 12 years ago

I've never used iOS so I didn't know about it does this, but I've always wondered why Android didn't do the same thing.

mrottenkolber3• 12 years ago

Apple customers, where phoning home on every network connection is good UX. What is wrong with you people?

I had this behaviour crash a captive portal daemon once, was fun tracking down the owner of the device in question in the building. "CapDaemon crashed, request came from around room A2.011!", "Let's get him before he's gone!", "Hey, Mr., do you own an Iphone or I pad? Yes? Please come with us. We need to have a debug session with you."

TazeTSchnitzel3• 12 years ago

OS X's solution is really nice, I only wish other platforms would do it. Microsoft do a similar connectivity check on Windows, yet they don't deal with the portals.

ferongr2• 12 years ago

if it fails for any reason, they bring up a modal panel showing the captive portal

AFAIK, technically, there's no standard address for a captive portal's location so iOS probably tries to navigate to a website. The router then poisons the DNS response and the captive portal loads. Android devices do the same thing to my knowledge. My Samsung pops up a notification that when tapped opens the browser and tries to navigate to Google. If a login happens before the user opens the notification (for example, by an app running a background service like the Fonera app) the notification is cleared automatically.

AlyssaRowan• 12 years ago

Wrong way round. Captive portals need to provide a better user experience for browsers that doesn't involve an MITM! See 802.11u: no excuse for not using it.

DCKing• 12 years ago

Excuses for not using 802.11u it do exist: client support simply isn't there. iOS only supports it since 7, Android doesn't support it (and will not generally for many years even if Android L does include it), Windows doesn't support it generally, OS X doesn't appear to have support for it, the list probably goes on. It will take 5 years at minimum before hotspot owners will provide this functionality, as there needs to be major client adoption first.

Just because your solution is problematic doesn't however mean that your point is not correct. The problem here is indeed with captive portals.

nandhp2• 12 years ago

My solution to that is to open http://example.com/ (instead of, e.g. Google) after connecting to Wi-Fi. It doesn't use SSL (so it works) and I have little use for it the rest of the time (so if the Firefox DNS cache gets messed up, it doesn't matter).

zdw• 12 years ago

I wish that this sort of stuff would come down to API-level interfaces.

For example, for the longest time Python's SSL library wouldn't even verify SSL certs:

https://wiki.python.org/moin/SSL

And would gladly connect to MITM'ed sites. I think this is rectified, but the information I've found is conflicting.

It seems to me that securing API endpoints would be even more important than end users, as there's could be a much larger quantity of data through an API than a browser.

ayrx• 12 years ago

If you are making SSL requests with Python you will want to use service_identity[0] to perform certificate validation. Hynek has some good information on his blog[1].

[0] https://github.com/pyca/service_identity

[1] https://hynek.me/talks/tls/

giovannibajo14• 12 years ago

Python's SSL state has been worse than other languages because of the 2.x -> 3.x transition, so basically 2.7 was left broken for longer than ideal. Eventually, they decided to backport most of the network security improvements (http://legacy.python.org/dev/peps/pep-0466/), see there the timeline.

Notice that this applies to the standard library; many people use the requests library which not only offers a superior API but also more security by default.

jbb555• 12 years ago

Yeah, makes sense. I guess. But I'm more and more worried about the web "platform", it just gets more and more complex each day.

mkal_tsr• 12 years ago

Other mechanisms, such as a client-side pre-loaded Known Pinned Host list MAY also be used.

Fantastic addition IMO. You could distribute/sync hash lists on and offline, awesome.

StavrosK2• 12 years ago

Does anyone know why they didn't go with TACK?

eplsaft4• 12 years ago

TACK is a TLS extension. It must be added to TLS 1.3 RFC.

StavrosK2• 12 years ago

I see, thanks.

tptacek12• 12 years ago

TACK doesn't have to be added to any RFC in order for browsers to adopt it. They could have integrated TACK, but chose not to. I wish they'd go the other way on that.

lucb1e6• 12 years ago

I wonder how this is going to work. I've been using an add-on to pin certificates for a half a year now and it's a hell on some websites. It nicely worked for my bank for a while, but they now employ the same technique as Google, Twitter, Facebook, Akamai, etc., changing certificates and even their CA seemingly at random. You'd think I'm being MITM'd but I'm pretty sure that's not actually the case.

Edit: I should read more closely, found it:

the list of acceptable certificate authorities must be set at time of build for each pinned domain.

So it's directly in Firefox' source code right now. Pretty much useless for anyone but a few big sites.

And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies.

Someone1234• 12 years ago

And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies.

I don't follow. If the user visits a site for the first time (ever) over a secure connection, they will become much more resilient to MITM for all future connections (including the ones where it updates).

That's a win in my book. At least it is a win from the "hacker" MiTM threat. It won't be as useful against states/governments since there might never be a secure connection ever.

But I'd take a solution NOW that works-ish than a solution maybe never which is flawless. Security in depth and all that jazz. The ultimate solution is some kind of secure DNS infrastructure which delivers information about HTTP certificates (which I believe is in the works also).

lucb1e6• 12 years ago

I'm not saying it's entirely bad, but it's something some users will want to disable for privacy concerns. The current model works well enough to allow widespread online banking and although this RFC will certainly make it more secure, there are also disadvantages.

I happen to know that Chrome hardcodes a list of EV certificates (or at least I read so a while ago), it could do the same for CAs. Or the browser could ask a central server which CA belongs to a certificate fingerprint. Not that different from OSCP except that it'll probably be run by the browser manufacturer instead of the CA.

xorcist6• 12 years ago

If the user visits a site for the first time (ever) over a secure connection, they will become much more resilient to MITM for all future connections

.. as long as the site never cycles their certificates, and bugs such as Heartbleed never forces them to.

Not a win in my book. In practice, this will be either useless or amount to a tiny nagscreen that users click through with their brains on autopilot.

rjbrock2• 12 years ago

This isn't really intended for the end user to use. This is for a web service to let Mozilla know that they will only use XXX root CA to issue their certs, and Firefox then only trusts valid SSL certs from the proper root CA for that web service.

Google has had pinning enabled in chrome for their own properties for a while (and some others now I believe). In fact that is how they detected an intrusion in one of the other Root CAs

lucb1e6• 12 years ago

In fact that is how they detected an intrusion in one of the other Root CAs

I know that and that's great, but why only Google? Sure it is Chrome we're talking about, but it is still a mainstream browser. They could make it a bit more neutral by including, say, https-enabled sites from the Alexa top 10k.

This isn't really intended for the end user to use.

Of course, what I meant was how small websites will get their sites secured. Do we have to do a pull request for every browser out there every time we order a new certificate? It doesn't seem manageable for the developers nor the browser builders.

sbierwagen3• 12 years ago

  And the pinning RFC doesn't sound much better. It makes the 
  client store something about sites they visited, which 
  roughly translates to supercookies.

So what? The server can't read it back out of the client store again. The comparison to cookies is completely spurious.

lucb1e6• 12 years ago

The server can't read it back out of the client store again.

Actually it can, by making the client connect to various subdomains with various certificates (valid or not). Like with image caches and everything else that supercookies use, something that is meant to be cached between requests is always detectable.

spurious

Nice day to you, too...

PhantomGremlin• 12 years ago

I've been using an add-on to pin certificates for a half a year now and it's a hell on some websites.

Do you mean Certificate Patrol? I also tried it and have given up. Way too "noisy". Let's hope that Firefox eventually implements a more refined solution.

eplsaft4• 12 years ago

this sounds identical to google CRLSet. Basically a list of pinned certs inside source code.

In the future, we would like to support dynamic pinsets rather than relying on built-in ones. HTTP Public Key Pinning (HPKP) [1] is an HTTP header that allows sites to announce their pinset.

ok cool. Requires initial safe connection once. Like HSTS.

reedloden• 12 years ago

This is nothing like Google CRLSet. CRLSet is just a way of collecting the CRLs from a ton of different CAs and having a way to push those out to Chrome browsers easily without users having to individually download them all from the CAs.

Chrome has its own TLS pinning implementation that basically works the same way as Firefox's. See https://src.chromium.org/chrome/trunk/src/net/http/transport...

tete2• 12 years ago

Meanwhile Chrome doesn't even support OCSP (Certificate Revocation) for performance reasons, not even after Heartbleed.

I hope that doesn't sound like fanboyism, but not being able to communicate a certificate revocation properly is worrisome.

tptacek12• 12 years ago

That's because OCSP doesn't work. The real-world Internet routinely breaks OCSP queries, which results in Firefox (and other browsers) soft-failing them: if OCSP doesn't work, the browser goes ahead with the connection. The security problem here is trivially observed.

TLS certificate revocation is a mess. We know what the solution will look like: it'll be something like HSTS, except that instead of caching "this site must use HTTPS", we'll also cache "this site must use OCSP stapling", and the OCSP data will be conveyed in-band in the HTTPS connection. It's hard to ding Chrome for not supporting something that doesn't really exist yet.

So, no: not "for performance reasons".

Incidentally: Chrome more or less invented certificate pinning.

tete2• 12 years ago

But OCSP is the only thing that's widely supported as of now. You can't on one hand say "don't blame Chrome to not support something that doesn't exist", when at the same time it rejects something that's widely deployed and even is considered a requirement for CAs.

Being able to revoke your certificate, even if it has problems is better than not being able to.

OCSP is still the standard way of communicating certificate revocations and even with all the HTTP-Extensions you need a way for certificate revocation.

Unlike most alternatives OCSP is out of the box supported by IE, Firefox, Opera and Safari. Only Chrome has it disabled per default. Most people revoked their old certificates after Heartbleed. This is an example of where you need an alternative to just pinning a key.

So you are saying that an attacker has to make sure that the OCSP connection isn't working means OCSP is worse than having no possibility of certificate revocation at all?

Not saying that it's absolutely secure. Hopefully everyone knows that there are flaws in HTTPS/SSL. Zooko's triangle[1] even gives you a hint why.

Also I am curious. What better, more widely used way of Certificate Revocation do you know?

[1] https://en.wikipedia.org/wiki/Zooko%27s_triangle

Pxtl3• 12 years ago

OCSP is still useful, it's just not panacea. Getting timely notification that cert A is invalid or that server B should no longer be using cert A is still good. It doesn't solve every problem (like somebody blocking access to the CA to prevent the OCSP check) but it's not worthless.

It can be defeated if the user or his ISP is pwned. It might kick in too late to properly save the user if the connection to the CA is too slow.

But it still does nicely handle the case where a server and its cert are no longer trustworthy.

eplsaft4• 12 years ago

Revocation in this case of pinned key means setting the max-age to 0 of the previous key and pinning a new key. This must be done before attacker is able to MITM.

Firefox 32 Supports Public Key Pinning

Related Stories