Seven months ago Andy Steingruebl, PayPal’s Secure Development Manager, contacted me to know whether a future NoScript version could support server-side activation of its HTTPS-enforcing features, preferably with a more robust approach than the cookie-based one seen in the original Barth & Jackson’s “ForceHTTPS” proof-of-concept. Such a potential development had obvious positive implications for e-commerce businesses and secure websites in general, hardening them against session hijacking attacks. I proposed a X-Force-HTTPS response header, to be ignored if coming through an insecure connection, otherwise switching on or off the “HTTPS-only” policy for the sending host. A dedicated persistence mechanism on the client side, immune from any accidental or malicious override, was meant to overcome the obvious intrinsic limits of cookies. The discussion seemed to die there, though.
Three months later, on May the 1st 2009, Steingruebl sent me another email, introducing Jeff Hodges, a PayPal security researcher who was preparing a specification draft for a refined “X-Force-HTTPS” header, renamed as X-Force-TLS. They were hoping to get a reference implementation in NoScript, and I would have really liked to help, but the timing could not be worse: I was already working around the clock for the first ABE public release, due on May the 25th, and as if that wasn’t enough, just some hours earlier the Adblock Plus “scandal” had exploded all over the Internet, taking away the peace of mind required to sustain NoScript’s traditionally allegro development rhythm. So, after releasing ABE, I spent my summertime focusing on its user-driven stabilization, and the X-Force-TLS sub-project went in the fridge. In the meanwhile an experimental implementation had been provided by Sid Stamm as a standalone extension for Firefox. Sid is a Mozilla guy who’s very active on CSP as well, so this might be seen an encouraging hint to future support in the core browser.
However one week ago the security staff of a (quite easy to guess) leader Asian e-commerce player, which has been closely following the development of NoScript’s “WebAppSec-oriented” features such as ABE, ClearClick and Anti-XSS Injection Checker, asked me whether I could estimate a date for implementing a server-side switch mechanism for HTTPS enforcement, just like the one discussed earlier with PayPal. They were eager to deploy this kind of protection as soon as possible, even in October, as part of a client security campaign involving a “Safest with Firefox + NoScript” recommendation. Therefore I decided to unfreeze my own X-Force-TLS implementation and, after a quick assessment, I committed to inclusion in NoScript 184.108.40.206, scheduled for release this week. As an incredible coincidence, on day later I noticed a message from Jeff Hodges on the WHATWG mailing list, announcing the Strict Transport Security draft, a more formal and public “X-Force-TLS” header proposal, renamed again as Strict-Transport-Security and about to be implemented
in the not-too-distant future by Chrome, too. So I immediately forwarded the exciting news to the interested Asian party and made the necessary HTTP header renaming in my code for NoScript 220.127.116.11, announcing its impending release.
And here we are, with NoScript providing the first public Strict-Transport-Security user agent implementation. If you’re in charge of a secure web site, please refer to the aforementioned specification to increase the reliability of your SSL deployment. If you’re a NoScript user, just keep relying on it as always, knowing that your online transactions are going to become safer during the incoming months, as adoption among secure web properties grows. And if you’re a power user and you prefer not to wait for them, don’t forget that NoScript can already force any website to use secure connections only, at your whim.