.png)
Pinning helps protect users from man-in-the-middle-attacks and rogue certificate authorities. When the root cert for a pinned site does not match one of the known good CAs, Firefox will reject the connection with a pinning error. This type of error can also occur if a CA mis-issues a certificate.
.png)
Pinning errors can be transient. For example, if a person is signing into WiFi, they may see an error like the one below when visiting a pinned site. The error should disappear if the person reloads after the WiFi access is setup.
Firefox 32 and above supports built-in pins, which means that the list of acceptable certificate authorities must be set at time of build for each pinned domain. Pinning is enforced by default. Sites may advertise their support for pinning with the Public Key Pinning Extension for HTTP, which we hope to implement soon. Pinned domains include addons.mozilla.org and Twitter in Firefox 32, and Google domains in Firefox 33, with more domains to come. That means that Firefox users can visit Mozilla, Twitter and Google domains more safely. For the full list of pinned domains and rollout status, please see the Public Key Pinning wiki.
Thanks to Camilo Viecco for the initial implementation and David Keeler for many reviews!
Firefox 32 and above supports built-in pins, which means that the list of acceptable certificate authorities must be set at time of build for each pinned domain. Pinning is enforced by default. Sites may advertise their support for pinning with the Public Key Pinning Extension for HTTP, which we hope to implement soon. Pinned domains include addons.mozilla.org and Twitter in Firefox 32, and Google domains in Firefox 33, with more domains to come. That means that Firefox users can visit Mozilla, Twitter and Google domains more safely. For the full list of pinned domains and rollout status, please see the Public Key Pinning wiki.
Thanks to Camilo Viecco for the initial implementation and David Keeler for many reviews!
When a captive portal is detected, many Android devices (like my Samsung) open the preferred browser (I think the one that the user has selected in the intent dialog) and navigate to Google. DNS poisoning happens and the user is redirected to the login page. What happens with pinned certificates for Google in this case? Will an error show up? If yes, does the user have to know and try to navigate to a website without a pinned cert?
ReplyDeleteYes, the paragraph above about transient errors is mostly about captive portal. The person needs to finish signing into wifi before visiting a pinned site.
DeleteCaptive portals break standards-compliance, so if there are issues visiting them, it's the portals that need to be fixed.
DeleteThe problem as I see it is that many devices (like my Samsung Galaxy) navigate to Google during the captive portal login. Seeing an error instead of the captive portal will really confuse users.
DeleteOn the wiki page (in the last section), it says '[dynamic pinsets] relies on "clean load" in order to provide a similar level of assurance as built-in pins'. What does "clean load" mean?
ReplyDeleteIt means that the first time you visit the site, no one is trying to MiTM the connection.
DeleteWouldn't it be feasible to check DANE/DNSSEC records for domain names supporting them ? This would be a more global (and standard) solution for this problem ?
ReplyDeleteWithout knowing too much about DANE or HPKP, I tend to agree with you. It seems silly to bloat every HTTP response with a pin list, plus it avoids the clean load problem.
DeleteThat being said, I think that built-in pins for high traffic sites are a fine intermediate solution.
I would strongly be in favor of DANE too. Certificate Pinning that doesn't integrate with DNS-SEC is very much a dead-end solution IMO.
DeleteWill the stock pin list be scrapped once the HTTP extension is fully implemented?
ReplyDeleteThat's an interesting question. Some sites have dozens of pins. I don't know that they could embrace HPKP without being able to reduce that to just a few. That kind of operational work can be very time-consuming, so I doubt that we would scrap built-in pins immediately unless everyone we were currently pinning could immediately switch over to HPKP.
DeleteInteresting idea, but how could it prevent man-in-the-middle-attacks and rewrite the Public-Key-Pins header?
ReplyDeleteHi Dennis, I assume you're talking about HPKP. I think the idea is that if the first time you connect to the site and the PKP header has *not* been re-written, then subsequent attacks to rewrite the PKP header will fail because the user-agent will remember the correct set of pins from the first clean load.
DeleteYou may want to link to draft-ietf-websec-key-pinning-20 instead of draft-ietf-websec-key-pinning-12...
ReplyDeleteThanks Julian, fixed.
DeleteHow does this key pinning work with MITM done in many companies, where a (usually self signed) proxy CA is deployed to the clients browsers to trust the certificates created with that CA ? Will now any Firefox User behind a HTTPS corporate proxy see those warnings, or are manually added CA certificates handled from FF the same way as before ?
ReplyDeleteyes, its a self sign cert
ReplyDeleteThat was my precise question as well. That could force us away from Firefox if it interferes with the user experience. Much of the malware is coming in via legitimate but compromised sites and we're seeing a few legit compromised HTTPS sites a week now. Hopefully there is a way to disable this via Group Policy for corporate environments if it is going to cause user experience issues. You don't really have an option to use anything but a self-signed certificate. I think it's in 2016 when public CA's are forbidden from issuing certs for internal-only domains and they have to revoke any that they issued.
ReplyDeleteBummer. I should have RTFM:
ReplyDeleteHow to use pinning
Starting with FF 32, it's on by default, so you don't have to do anything. The pinning level is enforced by a pref, security.cert_pinning.enforcement_level
0. Pinning disabled
1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)
2. Strict. Pinning is always enforced.
3. Enforce test mode.
So no worries. Mozilla is obviously smarter than me. Although malware installing their own cert was being done last decade, this is a very good compromise.
My Corporation has installed an internal SSL certificate on all browsers and then uses it to encrypt the connection and traffic to the Corporate web proxy. The Corporate web Proxy falsifies the certificate information to look like the traffic is coming from Google so the certificate and URL matches.
ReplyDeleteI am told there is not much Firefox can do at this point because the web proxy is applying a basic man-in-the-middle attack on the SSL connections using a pre-authorized imported certificate.
Will "pinning" help detect this and at least give a warning (eg red, but locked, padlock) to indicate the connection is encrypted but using an imported, not recognized, certificate?
Anonymous, from https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#How_to_use_pinning you can change security.cert_pinning.enforcement_level to 2. This will disallow user-installed trust anchors (or corporate-installed ones) from being able to MitM connections. We may make this the default setting in FF 35.
DeleteMonica, that is a horrible plan. Corporate sanctioned SSL proxy customers are not going to love having to change the default behavior in all their web browsers.
DeleteAnother way to look at it is that enterprise users are about 1% of the total user base, and that changing the default makes the other 99% safer at the expense of administration time for enterprise. I imagine that enterprise sysadmins change many other settings in Firefox.
DeleteHey, thanks for the informative and straight-forward article on public key pinning.
ReplyDeleteThe last picture on the Wifi scenario does not load for me, with ACL error.
Thank you Hanxue, not sure why that happened but I re-uploaded it.
ReplyDelete