Showing posts with label forcetls. Show all posts
Showing posts with label forcetls. Show all posts

Thursday, March 24, 2011

Force-TLS compatible with Firefox 4!

I've updated the Force-TLS Firefox Add-On to work with the newest version of Firefox! Force-TLS version 3.0.0 should work in all Firefox 3.0 and newer.

So what does this mean? Well, HTTP Strict-Transport-Security (HSTS) is implemented in Firefox 4, and that's a pretty similar technology to Force-TLS. In fact, it is nearly identical except there's no UI in Firefox 4. If you install Force-TLS, you'll get a UI and also get the built-in HSTS support that's implemented much more completely and efficiently than any add-on. A while ago, I blogged about an experimental add-on called STS-UI that adds a UI to HSTS; Force-TLS shows essentially the same user interface but I've been wanting to keep both the back-end for Firefox 3.x and the front-end for all versions of Firefox in the same add-on.

So what's new in version 3.0.0?
  • Smarter: The invisible bits of Force-TLS are restructured to use the custom HTTPS-upgrading and header-noticing bits for earlier Firefox versions but use the HSTS back-end built into Firefox 4 when it's available.
  • Better: A few bugs in the user interface were fixed.
  • Organized: I've moved the code into an open source repository.

I've got a list of enhancements queued up for the next version of Force-TLS, but not a whole lot of time to work on it. If you'd like to help make Force-TLS more awesome, send an email to forcetls@sidstamm.com

Previously:

Thursday, August 26, 2010

HTTP Strict Transport Security has landed!

It was a year ago now that I first blogged about ForceTLS, and it's matured quite a bit since. I revised ForceTLS to be more robust, and began actually implementing it as HTTP-Strict-Transport-Security in Firefox. I'm excited to say that my patch has been reviewed and landed in mozilla-central.

What's that mean? Look for it in the next beta release of Firefox 4! If you can't wait, grab a nightly build, but when 4.0 is released, HTTP Strict-Transport-Security will be built-in and turned on by default.


Though the feature's core functionality is there, work on HSTS is not completely finished. There are still a few tweaks I'd like to make, mainly providing a decent UI so people can add/remove HSTS state for servers themselves -- but none of this is necessary to be specification compliant. As landed, HSTS is the behind-the-scenes implementation that listens to the HTTP Strict-Transport-Security header and follows those instructions.


In case you don't feel like trawling through the IETF Internet Draft specification but you want to figure out how it works, here's a quick summary:


  1. Over an HTTPS connection, the server provides the Strict-Transport-Security header indicating it wants to be an HSTS host. It looks something like this:
    Strict-Transport-Security: max-age=60000
    The header's presence indicates the server's desire to be an HSTS host, and the max-age states for how many seconds the browser should remember this.
  2. For an HSTS host (e.g., paypal.com), any subsequent requests assembled for an insecure connection to that host (http://paypal.com), will be rewritten to a secure request (https://paypal.com) before any network connection is opened.
  3. Optionally, the header can include a second includeSubdomains directive that tells the browser to additionally "upgrade" all subdomains of the serving host. That looks like this:
    Strict-Transport-Security: max-age=60000; includeSubdomains

If Firefox knows your host is an HSTS one, it will automatically establish a secure connection to your server without even trying an insecure one. This way, if I am surfing the 'net in my favorite cafe and a hacker is playing MITM with paypal.com (intercepting http requests for paypal.com and then forwarding them on to the real site), either I'll thwart the attacker by getting an encrypted connection to paypal.com immediately, or the attack will be detected by HSTS and the connection won't work at all.

There are more details in the specification, like some further restrictions on cert errors and the like, but this is the general setup, and I believe a pretty nice feature to increase your site's security.


Also: Jeff and Andy at Paypal are working hard at standardizing this.



Friday, November 20, 2009

update on HTTPS security

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.

Monday, August 10, 2009

force tls

A while back, Collin Jackson and Adam Barth presented this idea called ForceHTTPS. The main idea was simple, yet powerful: allow sites a way to say "in the future, ALWAYS load me via HTTPS". Why?

"Computers are increasingly mobile and, to serve them, more and more public spaces (cafes, airports, libraries, etc.) offer their customers WiFi access. When a web browser on such a network requests a resource, it is implicitly trusting the hotspot not to interfere with the communication. A malicious computer hooked up to the network could alter the traffic, however, and this can have some unpleasant consequences." [Mozilla Security Blog]

I like this force-security feature, and by suggestion from a few other interested parties, I took to implementing a slightly different version from what Jackson and Barth had done in the past. For now, I'm calling it ForceTLS, and the indicator to "always load via HTTPS" is an HTTP response header.

There's more details on my Force-TLS web site, but that's the gist of what it does. Some folks are working on a more detailed specification that hopefully will be published soon. For now, check out the add-on for Firefox, and let me know what you think!

Thursday, August 06, 2009

inheriting XPCOM across languages

I've been working on an Add-On for Firefox 3.* recently, and came across a situation where I wanted to do a little XPCOM component inheritance. Basically, there's an HTTPProtocolHandler in Firefox that is used in a variety of places, mainly in the creation of URIs and connections through HTTP. I wanted to modify the HTTP Protocol Handler so that it would get to "filter" each HTTP URI before a connection is created, and then maybe upgrade it to HTTPS if necessary (ForceTLS: see the AMO listing, my site, and the blog entry).

Anyhow, since there can be only one HTTP protocol handler, I have to somehow modify it, and since it's written in C++, I basically have to write my own from scratch to deploy it in an add-on.

But wait, there's got to be an easy way. Here's a thought: create a really basic component, capture a reference to the existing HTTP protocol handler, register the new one as the HTTP protocol handler, and for all method calls and property accesses on my handler, delegate back to the original protocol handler. In js-pseudocode:

myHandler.aPropertyAccessed = function(propName, context) {
if(typeof this[propName] === 'undefined')
return oldHandler[propName];
return this[propName];
};

myHandler.aFunctionCalled = function(fname, args) {
if(typeof this[fname] === 'function')
return this[fname].apply(fname, args);
return gOldHandler.functionCalled(fname, args, gOldHandler);
}


But of course it's not that easy because there is no propertyGetter or functionCalled general methods (like in python). So instead, I had to take to playing with prototypes, aided of course by my JS guru Ben:

// "@mozilla.org/network/protocol;1?name=http"
var kCID = "{4f47e42e-4d23-4dd3-bfda-eb29255e9ea3}";
var gOldHandler = Components.classesByID[kCID]
.getService(Ci.nsIHttpProtocolHandler);

function MyHandler() {}
MyHandler.prototype = {
//custom methods and overridden stuff here
}
MyHandler.prototype.__proto__ = gOldHandler;


But this didn't work because of XPCOM and QueryInterface: the JS object oldHandler may have other interfaces it supports, but the appropriate methods aren't in the JS instance. So I have to do something a bit more elaborate:


// Given two instances, copy in all properties from "super"
// and create forwarding methods for all functions.
function inheritCurrentInterface(self, super) {
for(let prop in super) {
if(typeof self[prop] === 'undefined')
if(typeof super[prop] === 'function') {
(function(prop) {
self[prop] = function() {
return super[prop].apply(super,arguments);
};
})(prop);
}
else
self[prop] = super[prop];
}
}

function MyHandler() {
//grab initial methods (nsIHttpProtocolhandler)
inheritCurrentInterface(this, gOldHandler);
}

MyHandler.prototype = {
QueryInterface:
function(aIID) {
gOldHandler.QueryInterface(aIID);
inheritCurrentInterface(this, gOldHandler);
return this;
},

newURI:
function(spec, originCharset, baseURI) {
var uri = gOldHandler.newURI.apply(gOldHandler, arguments);
//... do my stuff here ...
return uri;
}
};


Essentially, I have to import the functions and variables from the old HTTP protocol handler, and every time my instance (which is replacing the old protocol handler) is QI'ed, I have to QI the old one and re-import all its properties. This is because the old handler was also an nsIObserver and who knows what else.

I implemented my own newURI method by wrapping the one in the old handler and manipulating the URI that comes out of it. Because this is manually defined, it won't be shadowed by functions imported by the inheritCurrentInterface() calls.

The only lingering XPCOM question I've got is what to do with getInterface(). I think because of the inheritCurrentInterface() implementation, getInterface will get imported with the appropriate functionality when it's needed, but I'm not sure.

So I guess the next step is to try and figure out how to provide a JS library that makes this all a lot easier. I'd like some syntax like:

Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");

var MyService = XPCOMUtils.extendService(kCOMPONENT_CLASS_ID);
MyService.constructor = function(foo) {
//do something with foo
};
MyService.prototype = {
//override methods here
componentMethod: function(a, b, c) {
super.componentMethod(a, b, c);
},
};

// then the rest of XPCOMUtils init stuff...


That syntax may not be workable, but something like it would be nice.