Manual certificate pinning

[unit309]

This is feature request.

Is it possible to add option to manually pin certificate(s) for particular domain? AFAIK this functionality is totally missed on Firefox both on PC and on mobile platforms.

Long ago, in pre-Quantum era, there was XUL-based Certificate Patrol addon...

For now, the only browser/plugin with such feature I found is Privacy Browser on Android (which is far from complete in many ways).

Is it possible with current Firefox API?

[hardfalcon]

Sadly, specifying/implementing such an API for web extensions was declined (for no good reason IMHO, but that's off-topic for the scope of this feature request) by the people in charge at Mozilla.

[unit309]

@hardfalcon, thanks for that link..

So, it's possible to read all certificate information. But API doesn't allows an extension to "change or ignore the normal results of certificate validation".

But maybe it's still possible to notify user with popup/red icon/etc, if pinned cert(s) is missing? Like, 'there is something going on; do you mind to look closer?'

[hardfalcon]

Theoretically, it might even be possible to write an extension that blocks connections to servers based on certificate information, but that would require really nasty hacks, be very slow, and still wouldn't be very reliable.

Since it is possible to hook into the outgoing HTTP(S) requests (which is used for addons like umatrix or ad blockers), you could probably write a web extension that holds outgoing HTTPS requests back, and sends its own test request to the very same server, checks the certificate and/or cryptographic parameters of that test request, and uses the resulting info from that test connection to decide whether to let go forward the outgoing HTTPS requests that were held back at the beginning.

Still, both this and the feature requests you describe seem out of scope for a browser addon like certainly something.

[unit309]

Sorry, just noticed word 'demo' in description...

Ok, just let me try to get attention of (former) Certificate Patrol authors: @tg-x, @20after4

[april]

By the time that WebExtensions can read the certificate information, the connection has already been made. Unless I can get this information before onHeadersReceived, I wouldn't be able to terminate the connection at the appropriate time.

I could certainly notify in some way, but I can't stop a bad connection from happening.

[tg-x]

Manual pinning of certificates (or a CA in the hierarchy) could be possibly interesting, however the trust-on-first-use pinning method employed by CertPatrol turned out to be quite error-prone & tedious to manage, I wouldn't do that part.

These days servers can do certificate pinning via HSTS, and there's also Certificate Transparency. These work via the Strict-Transport-Security and Expect-CT HTTP response headers. The webRequest API supports modifying HTTP response headers. If it's possible to inject these response headers and make the browser enforce them, then an extension could indicate the presence of these headers and add the possibility to manually enforce these for selected sites (with a report-uri to an extension page in case of Expect-CT). Anyone would like to do an experiment to see if this method works?

[rugk]

certificate pinning via HSTS,

HSTS only covers the fact that browsers do connect via HTTPS, not HTTP. You probably meant HPKP. With it, you can really pin the cert, or to be exact: the hash of the public key of the cert.

[hardfalcon]

certificate pinning via HSTS,

HSTS only covers the fact that browsers do connect via HTTPS, not HTTP. You probably meant HPKP. With it, you can really pin the cert, or to be exact: the hash of the public key of the cert.

Faked HPKP headers should never be abused by a browser addon to implement the behaviour requested by unit309. First, some browsers are considering removing HPKP support altogether because even without browser addons faking HPKP headers, a sizeable fraction of webmasters/server admins seem to shoot themselves into the foot by using HPKP in ill-conceived ways, and second, browsers to not offer any UI or API to remove HPKP entries again. Thus, an addon faking such headers could cause severe problems that the addon would not be able to fix again by itself.

So please, for the love of god, accept that there is no API to achieve the desired behaviour, and don't try to abuse security headers for purposes they were not designed to be used for.

[tg-x]

indeed, all the APIs are gone that allowed this. I'm not necessarily advocating abusing other security mechanisms either, just wondering about possibilities in case one really wants to do this. Seems like HPKP is already deprecated due to the problems you mentioned above, but CT is still being rolled out and not yet always enforced -- at least according to Chrome's CT policy. No idea about Firefox, is there any documentation about their CT policy?