http outdated…

Since the release of the Firesheep extension for Firefox, making http-session-hijacking easyer than ever, I've seen an increasing concern about security on the web.

In this article, i'm going to review the technical fundaments of http-sessions, explain the problems encountered and offer a view on possible solutions.

A technical overview

We first need to remember that http is a clear-text protocol. This means that ther is no encryption between the user's browser and the webserver, unless both client and webserver uses https which is a simple ssl wrapping of http, encrypting the complete http request.

Another important characteristic of http is that it is a stateless protocol, so there is no built-in mechanism to handle things like sessions that require a logged-in state opposed to a default logged-out state.

Now you're thinking i'm telling stories since you've been browsing the web and loggin in on your facebook account using http... So let's have a look at following communication description for a better understanding.

This depicts the most common login scenario used on the web. We see that we establish a new encrypted https session to pass the credentials to the server. In response tou our https login request, we are going to recieve a cookie containing a "http session key" provided by the application behind the webserver (not the webserver itself).

This session key identifies at this point our https connexion, but since this cookie is also passed along with each and every http-request, it definitely also identifies our http session.

This is a necessary mechanism to have seamingly statefull http since this cookie is going to be recognized by the application executed by the webserver, alowwing it to identify the user at each request. This session-key becomes a time-restriced token, that identify the user, and it needs to be passed with every http request in order to sort out the several users sending requests to the server.

So even if you never send your username & password in clear text, every time  you make a http request you are going to send this session-key in cleartext over the internet, allowing the application to recognize you and serve you specific content, allow you to trigger actions on the applications and any other application-specifig things you can do...

To sum up, http-session are used in this scenario as a temporary username&password that are send in clear-text with every http request. The 2 only advantages of the http-session-id is that it does not leak informations about your username&password (talking about the string here), and that it is time-restricted.

The problem

Now that you understand that with every http-request, a session-key is passed along in clear-text, playing the role of your credentials, the problem is well known in the télécommunication world : spies.

Internet has never been a secure communication channnel, spying is not so hard, but the problem has become more and more frequent since the arrival of public networks.

Now that lots of people uses public wifi hotspots, it has become very easy to spy on them since you can connect to the very same network and simply listen to everything.

Firesheep has'nt caused the problem, it has just pointed out how easy you can be spied on and the consequences it can have !

Abandon http for the benefit of https ?

There are some technical reasons to why companies are not willing to use exclusively https. A simple explanation is that https is consuming a lot more computing ressources that http since the whole http request is encrypted.

Decyphering requires lots of CPU time but also causes problems with load-balancing and ssl-certificates.

Load balancing problematic

A loadbalancer is an dpecialized proxy that is going to read the incoming http request and distribute it to a backend server depending on the load of those servers.

In most cases, a loadbalancer will read the http session-id and make a permanent link between a session-id and a backend server so that backend webservers don't neet to share the session ids.

The problem with https is that this loadbalancer will need to be an encrytption endpoint in order to keep doing this job. Since the whole http-request is encrypted when using https, the session-id is too, and in order to dispatch the request to the correct backend server, the loadbalancer will need to decypher it first, causing the ssl computing overhead to happen at the loadbalancer.

This would require trumendest computing power since a loadbalancer is only used when the amount of incoming requests is too important to be handeled by a single server, and is not an acceptable scenario for most companies.

Possible solutions

Defining the actual security issues is the key

To find an acceptable solution, we need to reconsider the problem and point out what is realy disturbing.

In most cases, the spying is not the real problem since the data passed in the http request is going to become public or almost public at some point in time. For example, when you post something on your facebook wall, well you meant to send it so others can see it online... The idea is that in most cases you can accept the fact that an attacker can spy on what you published or what you read.

The realy ennoying thing is the identity theft. The fact that an attacker is able to hicjack your session and thereby gain your online credentials is realy problematic. You can never accept that an attacker is able to send a mail in your name, or change your ogin/password...

So the real problem is not the session hijacking, it's more the fact that the server relies _only_ on this session-id that can so easily be stolen. And there we might have a solution !

A first solution proposal

The same way that client and server negociate a token during the https requests, we can easily imagine that they also negociate something else.

During the https phase of the login, we can easily have the server negociate the client a method to generete a http-request-authentication keys.

The idea here is that with each next clear-text http request, the client is going to pass a kind of token which time-restriction is limited to one http request. This way, identity theft can be prevented since the method for generating those tokens have been negociated using a secure connexion and is only known by the real user and the server.

The generation of those http-request-authentication keys can then take different forms. A complex unique password generation algorithm can be used, deriving the unique passwords from a key shared during the https phase.

This method have several advantages :

• the amount of encrypted data is minimal
• the (possible) encryption is offloaded on the webserver, and transparent to the loadbalancers.

I said "possible encryption" because we actually don't need encryption. We can negociate an ordered set of token, each token to be used with one http-request and then thrown away. In this case there is almost no computing overhead to the actual solution, just a bit more data stored in the session-file on the server and in the browser of the client.

Moreover, this solution doesn't require updated browers, since the logic on the client side can be achieved using javascript to add the http-request-authentication in the DOM before the browsers makes the next request.

Conclusion

http sessions are not enought to identify a user. But there are possible ways to overcome the biggest problem of the http-session, making identity theft impossible without encryption. More important : we can find solution that will work even on old crappy browsers, using old technologies and creating very little overhead to the current non-suffisent security measures.

This article is the sommary of my latest thought, but I must admit I didn't give a lot of effort to find my "solution", so any constructive critic is welcome !