FireSheep

It’s nice to see issues of transaction security being brought to public attention, it makes me hope that people might take notice and start to improve things. Unfortunately in this case I suspect the “improvements” may be anything but.

FireSheep basically exploits the “html form + session” authentication model used by the vast majority of websites today. In this model a user authenticates themselves to the server (typically this authentication stage is secured using TLS) via a web form built into a website. This form is usually presented either on a login page, or in response to a user requesting a service they do not currently have access to. There is little or no standardisation to this process beyond the fact that it uses HTTP and TLS.

The part of this model that FireSheep actually exploits is the session component. In order for the server to know that a user is authenticated to access a particular service a cached authentication token must be left behind on the client side, which can be sent with all future requests. This takes the form of a cookie. This authentication token must then be sent alongside every further request by the client. While the initial negotiation is encrypted using TLS in a lot of cases, e.g. for FaceBook, the subsequent requests are not. Thus the authentication token gets passed over the network in the clear.

While this token may not be used to get the user’s login credentials it can be used in a replay attack to access any services the user might currently be authenticated to use. E.g. to post stuff on their wall on FaceBook.

The obvious way to fix this is to simply encrypt all traffic between the user and the website. Simple.

Or is it? For a site like FaceBook encrypting all authenticated session data would be a horrifying prospect because transport-layer crypto is quite expensive in terms of processing requirements. This is a big part of the reason why websites are not currently encrypted as a matter of course.

The user experience of encrypted websites is also usually poorer than for their non-encrypted counterparts. The encryption adds latency to the connection as the data is encrypted and decrypted. Worse still most web browsers do not cache TLS encrypted data, so images downloaded over secured connections must be downloaded over and over.

Fundamentally it is quite wasteful to encrypt everything when the only information that actually needs to be encrypted is that tiny authentication token sent along with every request.

A better way to solve the problem would be to improve and then use HTTP’s built-in authentication mechanism. The two main ones in use are Basic auth and Digest auth. The former sends passwords in cleartext and is only really useful over TLS secured connections. The latter uses an MD5 digest with some cryptographic magic to achieve the same thing without sending paintext passwords. Both are widely supported in web browsers, but neither is widely used.

The two main reasons for lack of widespread adoption are twofold. One big problem is that there is no easy way for the server to “log out” a client, authentication credentials stored in the browser expire only when the browser is closed. There is also the issue of how this method of authentication is presented to the user. In most web browsers (and certainly all the major ones) the authentication is presented as a modal dialog which cannot be integrated into pages in the way that forms can. This is actually a bigger issue than any technical limitation of HTTP auth – web designers want to be able to integrate their own take on how logging in should happen.

It’s my opinion that the problems raised by authentication token hijacking would be best solved by extending HTTP, rather than moving to further use of wasteful encryption. Add a new HTTP authentication method which uses modern cryptographic methods (e.g. SHA256 version of digest auth) and a method for the server to log out clients.

Such a system would need the following characteristics:
1. Allow authentication to be initiated by the client alongside a request, e.g. submission of a login form with special HTTP auth attributes.
2. Allow the server to prompt for authentication via custom 401 error page, e.g. a login page/form.
3. Protect against replay attacks by encrypting the auth tokens.
4. Provide a mechanism for the server to internally expire authentication tokens and thus request a new authentication process from the client (i.e. logout).

The initial login could still use TLS to provide for assessing the authenticity of the server in question (e.g. to tell that you’re talking to the server you think you are). TLS would then only be required to assess the authenticity of the server with which you are communicating, or to provide transport layer encryption for when you are sending sensitive data (e.g. online banking). Potentially TLS could be replaced in this server-authentication role via the use of a DNSSEC-derived mechanism at some point in the future.

The other thing that would need to happen would be to allow these credentials to be pre-emptively specified in web form rather than being requested by the server as a 401 response. This would allow similar branded logins as we have today but using a system which would be built into HTTP. I am fairly sure that this could be achieved using a FireFox plugin initially as a proof of concept.

Given that the (in my opinion) misguided feature “HTTP Strict Transport Security” (which basically allows a server to specify a flag to a client that it should always request pages from that server using TLS-secured connections) is already a part of the latest beta releases of FireFox such a system ought to have a fighting chance, especially since it ought to be much more attractive an option to big websites than the massive cost of full encryption.

This system (lets dub it HTTP Advanced Auth) would provide a standardised login/authentication mechanism for all websites which doesn’t necessarily require transport layer encryption. It would also do away with the need for tracking sessions using cookies, and allow cookie-less login, so you could present stateless access to authenticated resources (which is already possible using the existing HTTP auth mechanisms).

The disadvantages would likely mostly be down to inertia in use of existing technologies, it’s hard to change things like HTTP and get your changes widely adopted. It’s also hard to re-educate users who have been told for years that the “green address bar” means they are secure… I do wonder though if the sheer amount of money involved in implementing the brute-force TLS-everything solution might make the bigger players on the net more open to the idea of supporting a better solution.