Version 2.0 of my Force-TLS add-on for Firefox was released by the AMO editors on Tuesday, and in incorporates a few important changes: It supports the Strict-Transport-Security header introduced by PayPal, and also has an improved UI that lets you add/remove sites from the forced list. For more information see my Force-TLS web site.
On a similar topic, I've been working to actually implement Strict-Transport-Security in Firefox. The core functionality is in there, and if you want to play with some demo builds, grab a custom built Firefox and play. These builds don't yet enforce certificate integrity as the spec requires, but aside from that, they implement STS properly.
The built-in version performs an internal redirect to upgrade channels -- before any request hits the wire. This is an improvement over the way the HTTP protocol handler was hacked up by version 1 of Force-TLS, and doesn't suffer from any subtle bugs that may pop up due to mutating a channel's URI through an nsIContentPolicy. I'm not sure that add-ons can completely trigger the proper internal redirect, since not all of the HTTP channel code is exposed to scripts, and add-ons would need to replicate some of the functions compiled into the nsHttpChannel, opening up a possibility of obscure side-effects if the add-on gets out of sync with the binary's version of those functions.
Edit: The newest version of NoScript does channel redirecting through setting up a replacement channel in a really clever way -- pretty much the same as my patch. It replicates some of the internal-only code in nsHttpChannel, though, and it would need to get updated in NoScript if for some reason we change it in Firefox.
There is no way to trigger the proper internal redirect from an add-on, so the only way to 100% correctly implement STS in Firefox without obscure side-effects is through a patch.
ReplyDeleteEh eh, not exactly. NoScript does trigger "proper internal redirects" at the channel level -- after nsIHttpChannel::asyncOpen() and before nsIHttpChannel::Connect() -- all the time, both for ABE and STS. Not easy to do without a patch, but feasible nonetheless ;-)
I did not to intend to say that NoScript's STS support is broken, I'm saying that there is potential for UI or other breakage due to the fact that I'm told not all of the needed functionality is exposed to script.
ReplyDeleteLast time I looked at NoScript's STS implementation, it was simply mutating the URI passed to it through a ContentPolicy. I just took another look, and it appears you're actually setting up a replacement channel (by re-implementing lots of nsHttpChannel in JS), which might work better. I'll edit my wording in the post to indicate there's a very complex way to do this from an add-on, but a simpler way to do it with a patch.