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 1.9.8.9, 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 1.9.8.9, 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.

28 Responses to “Strict Transport Security in NoScript”

  1. #1 Throompe says:

    Great!

    But…
    I suppose those entries are saved permanently, but what happens if the domain is no more accessible through HTTPS? Let’s say "example.com" sends this header in order to force users into HTTPS on the whole domain and does not specify a expiration time. Then this domains gets sold to someone else who is cheap and does offer HTTPS (no response on port 443). Do those users who accessed the page before the sale have now problems accessing the page? How likely would they realise the situation and how likely could they solve the problem (i.e. purge the cache)?

    Speaking of ports, what about them? What if HTTPS is offered only over a non-standard port?

  2. #2 hackademix.net » Strict Transport Security in NoScript « Security says:

    […] Rea­d mo­­re: hac­kad­em­ix.n­et » S­tric­t Tran­s­p­ort S­ec… […]

  3. #3 hackademix.net » Strict Transport Security in NoScript « Security says:

    […] Read the rest here:  hackad­emix.n­­et­ » St­rict­ T­ran­­sport­ Secur… […]

  4. #4 Alan Baxter says:

    Should I uninstall the Force-TLS extension now?

  5. #5 Nan M says:

    Quoth Throompe http://hackademix.net/2009/09/23/strict-transport-security-in-noscript/#comment-14955

    "How likely would they realise the situation and how likely could they solve the problem (i.e. purge the cache)?"

    The onus is on the service provider to document such data persistence problems in their user help section. Just like they are supposed to now…and often don’t :-/
    Ever looked at the FAQs of a medium to large online banking site re cookies, browsers and operability?
    If these headers have to be controlled by the server operator, how much knowledge of their own browser configuration will a browser user have to acquire (and, importantly, understand) in order to clean up misconfiguration (accidental or otherwise)? In other words, where is the STS UI proposed to reside?

    This is a welcome push however - even if very much baby steps towards a solid standard for all secure web operations.

  6. #6 Giorgio says:

    @Throompe:
    The “Strict-Transport-Security” flag is saved permanently, but only for the timespan decided by the server, whose responsibility is planning its SSL availability, e.g. based on its certificate renewal schedule - see http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html#sctn-hosting-spec-advice

    However, if you’re in (very unlikely) troubles or you’re testing your implementation, you can just delete or edit the textual database file named “NoScript-STS.db” in your profile. Even better, you can use the long time implemented NoScript Options|Advanced|HTTPS|Behavior exceptions, which override STS if needed.

    @Alan Baxter:
    Yes, you should uninstall Force-TLS, because:

    1. Force-TLS is obsolete at this moment. The specification changed, so it won’t be compatible with the adopting servers.
    2. Compatibility aside (that will be fixed in next version, if any) Force-TLS’ implementation is quite broken. Rather than observing and redirecting loads just before they hit the network like NoScript does, Sid choose to override the built-in nsIHttpProtocolHandler in order to replace the protocol at URI creation time. This causes conflicts with other extensions takig the same path for various reasons (e.g. FireKeeper), and may produce other unwanted side effects, e.g. easy reconnaissance by looking for link attribute changes. Furthermore, Sid had to fight against XPCOM obstacles, and this battle left on the field some non obvious but nasty (especially for privacy-sensitive users) bugs, e.g. changes in your general.useragent.* preferences are not reflected “live” in your user agent string and navigator properties, needing a browser restart instead.
    3. Since you’re a NoScript user, you’re keeping around code duplicating equivalent functionality, with memory and performance overhead.
    4. NoScript’s implementation is much lighter anyway.
    5. NoScript’s HTTPS exceptions apply to NoScript’s STS mechanism but not to Force-TLS.
  7. #7 Twitter Trackbacks for hackademix.net » Strict Transport Security in NoScript [hackademix.net] on Topsy.com says:

    […] hackademix.net » Strict Transport Security in NoScript hackademix.net/2009/09/23/strict-transport-security-in-noscript – view page – cached 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. — From the page […]

  8. #8 mikh says:

    Is this function optional (e.g. can user enable\disable it)?

  9. #9 Giorgio says:

    @mikh:
    Yes, it can be controlled through the noscript.STS.enabed about:config preference.

  10. #10 GµårÐïåñ says:

    This is some good stuff, thank you my friend.

  11. #11 Rafael Minuesa says:

    You are awesome Giorgio.
    A one-man gig doing for Web Security what all big corporations put together are unable to do.
    Makes you wonder, doesn’t it?

    Cheers and Thank You

  12. #12 Basti says:

    Sounds cool. Just needs a site that supports that.

    Is there any site it can be tested with? Thank you.

  13. #13 Giorgio says:

    @Basti:
    https://secure.informaction.com does already.
    As mentioned in my article, the biggest Asian Ebay’s competitor will in October. Paypal and Ebay are obviously likely to adopt it very soon as well, since they’re sponsoring the specification.

  14. #14 David M. Razler says:

    Georgio - Thanks for a great effort and a wonderful (though at times aggravating because of the site attackers I really worry about despite using all the 1984-flagged tools and more on my browser).

    Sure, Black-Hats are scary, BUT the perfectly LEGAL, sometimes unstoppable "targeted ad" and information brokers scare me more. They may even be monitoring the existence of this connection, if not "reading over my shoulder" as well as any mal-ware keylogger can.

    Why? Googlesyndication, 0.1, Digg and three Javascripts of your own are attempting to run and GoogleSyndication has attempted to insert a tracking bug on my screen. I have opened "simple" websites and found FIVE infobrokers are active parts of the page, usually datagathering and attempting to push advertising on me I won’t see, but will find in a file saved for me to examine later.

    The FIRST order of the day might be a US/EU/UK and anyone else who wishes to grab on ABSOLUTE prohibition on any corporate entity or individual STEALING info before announcing that "information about your use of Google today will be retained for 90 days, everything except personal information you may deliberately or inadvertently provide. "Personal Information is regarded as your name and exact address by Google - Every bit of information will be transferred to our subdivision DoubleClick, which has a prohibition on gathering or retaining for any length of time all but an undefined category of personal information, these policies subject to change as we wish.

    Secondly, laws prohibiting infogathering of any kind beyond those needed to make a business transaction, complete it, and run a business. For instance, Amazon might retain info on the names of books or disks I buy from them (and other products too) ONLY as long as it takes to guarantee the product has arrived, it has been paid for, and the customer is happy. After that, the company may NOT maintain a list that shows my interests, and which is a product in itself.

    Thirdly, we need to revitalize the old Newsgroups, and allow unlimited group establishment, possibly as an open UN grant, more likely grants by the various governments, with provisions REQUIRING public kee encryption. The US’s NSA and its colleagues in almost every nation wealthy enough to afford such a luxury, will no doubt subscribe to EVERY new newsgroup. I find this better than info going directly to Yahoo and the other group sponsors.

    Incidentally, those of you who have not read Gulliver’s Travels, or remember Johnathan Swift’s biting political satire (or think they know the book from a Disney film) nay wish to read it and find the origin of the word Yahoo - you may find out the identity of company’s real targets in his last voyage.

    Then we can tackle securing e-mail and delivery by a real urgency system.

    Now this may mean a search through Google or Yahoo or Bing will cost us a few cents. Freedom costs, and I’d rather pay for an anonymous Google account than pay by walking nude through the world.

    aka Winston Smith

  15. #15 SSL & transport security thread reminded me … : 39831 says:

    […] http://hackademix.net/2009/09/23/strict-transport-security-in-noscript/ […]

  16. #16 Bill says:

    Use IE8 in protected mode in Windows 7 and you will have no security problems.

  17. #17 dumbwabbit says:

    Yeah, sure, I can just afford to go out and purchase every new version of Windows… right. You gonna buy it for me? And as far as "no security problems" … sorry, but Microsoft’s and IE’s LONG history of bugs and other problems, including MANY that have absolutely no excuse for having been overlooked (bad coding, unchecked buffer overflows sound familiar to you? eg), or that have been around for over 10 years but were only recently discovered (OpenFont - remember that one from several months ago?) doesn’t exactly leave me with the warm and fuzzies when it comes to trusting Microsoft’s products "out of the box"… so please, don’t try to sell me THAT particular bottle of snake-oil.

  18. #18 evden eve nakliyat says:

    Hii .. Is this function optional (e.g. can user enable\disable it)??

  19. #19 Giorgio says:

    @evden eve nakliyat:
    Yes, just turn the noscript.STS.enabled about:config preference to false.

  20. #20 hackademix.net » PayPal is Safer with NoScript says:

    […] Strict Transport Security (STS) has gone live on PayPal yesterday. […]

  21. #21 hackademix.net » Google Talk Badges vs X-Frame-Options says:

    […] Google playing the early adopter of bleeding edge security technologies like X-Frame-Options or STS, both in its browser and in its web properties, is really great because it speeds up their […]

  22. #22 Look For A New Revision Of Chrome Soon ~ Revelations From An Unwashed Brain says:

    […] provide extra security against snooping, although it’s not bullet-proof. It’s already implemented in NoScript and a native Firefox implementation is being worked on. Some security-conscious web sites, […]

  23. #23 Kayce Obenshain says:

    There is surely plenty to recognize concerning this. I do think you put together good quality points in Features of security issues too. I still use XP and believe still most stable version. Keep doing the great job!

  24. #24 Chrome中5大安全增强 « Chrome Blog says:

    […] 目前,Paypal实现了该特征。Chrome 4也实现了STS,此外还有Firefox的安全插件 NoScript,它也拥有相同的功能。FireFox自身的STS实现正在进行当中。 […]

  25. #25 Security in Depth: New Security Features – 21th Edition | Chrome Secrets says:

    […] In addition to being in Google Chrome 4, Strict-Transport-Security has also been implemented in NoScript, a security add-on for Firefox, and a native implementation is underway in Firefox. A number of […]

  26. #26 Security in Depth: New Security Features « Twit Browser says:

    […] In addition to being in Google Chrome 4, Strict-Transport-Security has also been implemented in NoScript, a security add-on for Firefox, and a native implementation is underway in Firefox. A number of […]

  27. #27 The EFF releases new HTTPS Everywhere Firefox extension | ZDNet says:

    […] worth pointing out is that, forced SSL connections (STS support in both, NoScript and HTTPS Everywhere), as well as the additional security added by Secure Cookie Management, has […]

  28. #28 hackademix.net » Forcing HTTPS with NoScript says:

    […] input, in order to help websites make HTTPS setup more reliable and safe against hijacking attacks. HSTS has been implemented by NoScript and by the Chrome web browser more than one year ago, and it’s currently shipping also in […]

Bad Behavior has blocked 7476 access attempts in the last 7 days.