Firefox 32 Supports Public Key Pinning
monica-at-mozilla.blogspot.com
monica-at-mozilla.blogspot.com
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.
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.
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.
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).
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.
.. 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.
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
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.
And the pinning RFC doesn't sound much better. It makes the
client store something about sites they visited, which
roughly translates to supercookies.
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...
1. The client is new enough that it supports HPKP
(information you get from the default UA string anyway,
but could be used to smoke out someone using a blank UA
string)
2. The client has connected to this server once before.
You could add a new subdomain once a day, then invalidate the cert 24 hours later, to get more bits of information, but this is an attack that requires buying a new cert once a day, forever, which costs money. (StartSSL gives you one free cert, but only one) (It wouldn't cost a state sponsored attacker any money to create certs, of course...)
Is there even any way to implement PKP that wouldn't leak client information via failed handshakes? Is killing pervasive monitoring worth enabling an expensive supercookie attack?
(One dumb mitigation: ignore handshake failures due to PKP, proceed with the connection as normal, but throw away the data. You'd have to load and parse the requested page in the background, though, or else the attacker would notice that the client isn't requesting inline images/scripts...)
---
EDIT: Ah, the draft mentions the supercookie attack: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#...
I didn't actually know that. Nice to see they thought of it while designing, but besides the attack scenarios I don't see anything to do about it, for users nor 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.
The CA is trusted to do: Determine which certificates are valid.
Firefox is giant. It shouldn't be hard for a malicious party — should one appear someday — to hide some tiny backdoor somewhere in a more-than-a-hundred-megabyte source code tarball.
Verifying GPG signatures of the tarball could prevent some (but not all) issues, but from my observations it's rarely done. And when I've seen it done public key's origin wasn't thoroughly verified, just blindly `gpg --recv-keys`'d from keyserver.
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.
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.
Fantastic addition IMO. You could distribute/sync hash lists on and offline, awesome.
If a captive portal is able to display a valid web page when you try to visit an HTTPS website, that would be a serious red flag.
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.
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."
To handle this less centrally, you would need a distributed list of URLs to be used for captive portal checks, with servers handled by different entities, and each device selecting one at random from the list. This wouldn't change the UX though.
For your other remark, if the captive portal crashes for a standard HTTP GET to a normal URL, you can't really blame this on anybody else but the captive portal developers.
http://www.apple.com/library/test/success.html http://clients3.google.com/generate_204 http://www.msftncsi.com/ncsi.txt
And some other implementations of dubious longevity: http://start.ubuntu.com/connectivity-check http://network-test.debian.org/
Now, if only NetworkManager could add support for this.
To handle this less centrally, you would need a distributed
list of URLs to be used for captive portal checks, with
servers handled by different entities, and each device
selecting one at random from the list.
"...because Apple already fucked it up elsewhere so double fuckup doesn't give extra points."
> you can't really blame this on anybody else but the captive portal developers.
I don't think I did, thats just how I found out about this particular appleism. Also: This behaviour enabled us to track down that device and its owner physically too. So think about the sensibility of this "feature" in this light. Every other device would have enjoyed relative anonymity amongst the other devices in the building.
If you don't trust Apple with your IP, you shouldn't use a device which runs their kernels, that's a no brainer; if you do trust them, though, you might appreciate the way they go through multiple hoops not to handle too much of your sensitive personal data, see for instance the design of iCloud Keychain: http://www.apple.com/ipad/business/docs/iOS_Security_Feb14.p...
So it's not like the impact of an IP connection is not taken into account in design considerations; it's just that it doesn't look so important in the big picture of the security and privacy implications of using such a device. For personal passwords, different avenues are taken.
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.
Just because your solution is problematic doesn't however mean that your point is not correct. The problem here is indeed with captive portals.
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.
Please read about Convergence by Moxie Marlinspike. It solves the removing of trust problem.
The web site owner gets to choose which top domain to use and trust. It is not the end user that is supposed to value how much trust they put in each CA. That alone is the most important point right there.
If DANE were adopted and the current CA system abolished, then the registrar or the registry could still change the NS and DS records to takeover a domain, but that takes us from 100+ parties capable of signing a cert to 2 parties that are already part of the system.
No cryptography in the world can protect you from a fully legal domain trasfer. So, who better to be your CA than the registrar who have this power anyway?
Your resolver probably already supports it. Your TLD probably already publishes the records.
I don't need to trust the Iranian top domain (which is what you mean, not "government") for all of the web that is not in .ir. I don't know about you, but 100% of my web use falls in that bucket.
And if you want to visit an .ir domain you need to trust the Iranian domain registry, independently if you use CAs, DANE or even Convergence. If they change the legitimate owner of the domain (which is what you mean here!), they can just as easily get a legitimate SSL certificate in every trust model in practical use.
(Indeed, if a legitimate owner of a domain couldn't get a legitimate certificate, there'd be no possibility to do things like rotate your keys and change your certificate. That would be an even bigger problem than broken CAs.)
So DANE makes sense. And while there are known issues with DNSSEC, trusting governments is not one of them. Not more so than with any other model.
Is the USA-controlled DNS root a problem here? Hopefully interference would require highly visible and suspicious changes to the DNS root.
Also: I have a really hard time seeing how baking a CA into the fabric of the Internet is a vast improvement over the current situation we have now, in which we are continually tormented by our reliance on CAs.
No matter what the PKI system is, there will be more and less trustworthy actors around. I agree that many state controlled TLDs are currently quite popular, but I don't see them as generally less trustworthy than the commercially operated TLDs. Both groups will contain some iffy elements, but I don't know if there's any way to build a system where iffy actors can't play. At least they can only mangle their own domains with DANE. And sounds like DNSSEC should be quite a bit more tamper-evident than our current CA sysetm.
Or rather: The users trust the browsers to show an SSL warning if there's an indication that the connection is being MITMd.
Today, the browsers trust (hand-picked, subjected to stringent rules) CAs to tell them whether a connection is being MITMd or not and they then tell the users.
In the case of DANE, the UI to the user is the same (Blow up or don't blow up), so the trust given by the user to the browser is also the same, but now the browsers can't rely on CAs which they control to some extent (using said rules and monetary incentives), but they must rely on governments, often without oversight or clue and with all the incentives to MITM connections.
That means that by trusting DANE, browsers force users to also trust DANE and users might not want to trust some or all of the entities behind DNSSec.
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?
> 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.
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...
I hope that doesn't sound like fanboyism, but not being able to communicate a certificate revocation properly is worrisome.
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.
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?
The problem is that if you can MITM someone, you can deny them access to the OSCP service and cause a soft fail, which makes OSCP worthless.
If a certificate is worth issuing when a server is trustworthy, it's worth revoking when the server loses that trust.
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.
This is a common pathology when thinking about security. Lots of things appear to work when they aren't being tested by a real attacker, but don't work at all when they are. It's like an insurance policy that you pay small premiums to that then vanishes when a disaster strikes.
Like I said upthread: there's a way to make something like OCSP work: the OCSP signaling can be moved in-band, so it can't be attacked separately from the TLS session itself, and then made sticky through an HSTS-like mechanism. But until OCSP gets a "Must-Staple" mechanism, it provides literally no real benefit.
But don't let the perfect be the enemy of the "better than nothing".