Gathering session cookies with Firesheep

First of all, the server would need to keep a lot of state to prevent replay attacks. Second, attackers can still sniff connections and obtain a great deal of personal information. It'd be less effort to just bite the bullet and use SSL, which has many advantages besides preventing session hijacking. SSL isn't even all that bad for performance if configured properly.

It's really amazing to watch people jump through intellectual hoops to justify not protecting their users with SSL.

This approach would be problematic with concurrent requests.

I.e. when static file requests, ajax requests or multiple requests in separate tabs all use the same sequence number, only the first one would succeed, all other would fail, due to the sequence number already being used. For each request the browser would have to wait for the next sequence number + hash to arrive before starting the next request. That's just not feasible.

Accepting a list/range of sequence numbers or giving each one a specific validity period (i.e. 10s) could remedy that problem, but would also open the window for attackers again.

Granted, static files may be excluded from the requirement, but with the ubiquity of ajax these days and users' habit of opening several links in background tabs, this is not an acceptable workaround.

So then the attacker could just intercept the request and save the cookie plus sequence number plus digest, and send their own request with the same metadata. So rewrite a few dozen requests from one page view to do whatever you want and eat the response. The user sees it as the page timing out, so they figure the site is being slow and hit refresh, which gets them the authentic page. Yeah, it'd stop Firesheep, but it wouldn't do anything to stop a real attack.

To avoid this, you'd have to MAC the whole contents of the request. But HTTP proxies tend to rewrite the contents of non-secure requests, so your MACs will break and stuff will fail randomly. The only way around it is, yep, encrypt the request. Integrity without encryption fails if you have proxies that expect to be able to meddle with requests.

There are admittedly some practical reasons not to use TLS for everything right now, but they're not prohibitive -- look at Gmail or typical bank websites -- and they're diminishing with time.