security.cert_pinning.enforcement_level set to 0, but still can't bypass
Hello!
I'm testing a security flag in Firefox's config that will let my ignore HSTS certificate settings, but it doesn't actually seem to do that. I've triggered a certificate error from facebook.com, and attempted to set security.cert_pinning.enforcement_level to 0 as shown in the image to ignore the warning, but it won't anyway. I know that facebook.com is a protected domain (https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json), but I was hoping that the config change would override the cooked in protection. Can anyone confirm that the list can't be bypassed?
Solution choisie
I'm not sure that preference actually allows you to bypass HSTS. Did you see that documented officially?
If you expand the Technical Details section of the error page, what is the error code that appears toward the end?
Lire cette réponse dans son contexte 👍 0Toutes les réponses (8)
Here's the image, btw.
Solution choisie
I'm not sure that preference actually allows you to bypass HSTS. Did you see that documented officially?
If you expand the Technical Details section of the error page, what is the error code that appears toward the end?
Oh that's almost certainly it then. The error is what you'd expect: invalid certificate issued by an unexpected host. (Error code: ssl_error_bad_cert_domain)
I was hoping because of this that setting that value to 0 would disable pinning and let me add the certificate from the unexpected host and ignore the error, but it doesn't.
You shouldn't get ssl_error_bad_cert_domain from Facebook! Does the Technical Details section indicate what site the certificate is actually for? Or maybe the problem is in a framed page?
So, this error is because of how OpenDNS handles its content filtering, and I'm testing to see if I can make it go away.
OpenDNS' content filtering works on DNS based redirection. When I request facebook.com and have blocked it, I get redirected to hit-block.opendns.com. However, the browser was expecting the cert to come from facebook.com, and when it gets the page as *.opendns.com instead, it freaks out with the cert warning, as expected.
I thought that by setting the flag to 0 to negate pinning, and by manually adding the cert, that the exception would be allowed and the "Connection is Untrusted" warning would go away, but it doesn't. Instead, I'm given the error as normal and because it's an HSTS-pinned domain, it can't be bypassed. I'm really looking for the way around that within the browser, and had hoped that this flag would be it.
Oh I see, as configured, the OpenDNS filter doesn't redirect to an error page, it associates the requested host name with a different site.
I don't think you want people to make exceptions for blocked domains just so they can then view the OpenDNS page. That seems like a waste of time. Does OpenDNS offer a different solution that would bypass this problem?
But to get back to the main point, I think the pinning preferences relates to a different four-letter acronym, HPKP, and isn't connected to HSTS. Although for reasons unbeknownst to me, there is a cross references to HSTS at the end of this article: https://developer.mozilla.org/docs/Web/Security/Public_Key_Pinning
Not for its blocking architecture. There's an ability that certain users of OpenDNS have to bypass the filtering, but that relies on the same lander/redirection technology, and accordingly runs into the same problems.
Ideally, administrators should allow access to the users who need access to these protected domains, but often they don't, and rely on the bypassing functionality instead, which runs into the HPKP problem. Instead of giving social media coordinators a bypass code for twitter.com for example, they should just allow the coordinator access to twitter.com.
I think you should bounce the FB example to OpenDNS and see what they suggest. HSTS is only going to become more common over time.