This is called immediately after Firefox passes the certificate to its internal certificate verifier (and before Firefox’s verification happens), which allows the Experiment and the WebExtension to work in parallel to Firefox’s certificate verifier. This works by adding a new non-blocking function to the Experiment (called from C++), which simply notifies it that a new certificate has been seen. I decided to start with making the Experiment’s communication with the WebExtension asynchronous.

The natural solution is to try to make things asynchronous. This means 2 layers of cross-thread synchronous calls, one of which is entirely in JavaScript (and is therefore less efficient). Similarly, the WebExtensions Experiment has to wait for the WebExtension to reply before the Experiment can reply to Firefox. That means that Firefox verifies the certificate according to its normal rules, and only then passes the certificate to my WebExtensions Experiment and has to wait for the Experiment to reply before Firefox can proceed. The biggest bottleneck in my codebase was that basically everything was synchronous. Meanwhile, I talked with David Keeler from Mozilla some more about performance, and it became clear that some additional latency optimizations beyond Phase 3 were going to be highly desirable. It wasn’t too hard to figure out what was broken, though.)Īfter doing this, I was able to get my WebExtensions Experiment to trigger negative certificate verification overrides.

(The only irritating part was that the Mozilla wiki’s C++ sample code for this hasn’t been updated for years, and Mozilla’s API has made a change since then that makes the sample code fail to compile. Luckily, I had recently gained some experience doing synchronous cross-thread calls (it’s how the Experiment calls the WebExtension), and converting that approach from JavaScript to C++ wasn’t incredibly difficult. This means that the naive way of accessing an Experiment from the C++ function that would handle negative overrides causes Firefox to crash when it detects that the Experiment is being called from the wrong thread. WebExtensions Experiments always run on the main thread. The specific issue I encountered is that while positive overrides are called from the main thread of Firefox, negative overrides are called from a thread dedicated to certificate verification.

However, as is par for the course, Murphy’s Law decided to rear its head (but Murphy has been defeated for now). In Phase 2 of Namecoin TLS for Firefox, I mentioned that negative certificate verification overrides were expected to be near-identical in code structure to the positive overrides that I had implemented. Namecoin TLS for Firefox: Phase 4 (Fun with Threads)

Performing a tls handshake firefox