views:

179

answers:

4

So you've performed the login using https to prevent man in the middle attacks and make sure your password isn't sent in the clear. Good call. But many sites then switch back to http for the rest of the session.

Once you're exchanging everything in the clear can't a man in the middle begin hijacking your session again? Okay, so they don't have your password but they don't need it! For as long as you stay logged in the man in the middle can just hijack your session and send whatever requests they want. Can't they?

What measures are put in place to prevent this? Or is it not actually a problem because of something I have overlooked? Or, is this just an acceptable risk to take?

A: 

If your https handshake included the exchange of a secret key, a man in the middle can be theoretically prevented from doing any harm, by transferring the security considerations from the transport layer to the application layer.

For example, the parties might include a message sequence number, and a digital signature using the shared key. That would prevent replaying messages, tampering with existing message and creating false messages.

Aviad P.
I don't see how, if everything else is done over plaintext?
ZoFreX
agreed. there's not much you can do with a secret key once you're back in the cleartext world of http.
Matt
Theoretically: once you've left secure communications, you've left secure communications.
Justice
Nope, since http is unsecured, unauthenticated, and not integrity protected. The attacker has free reign.
GregS
No, you're all wrong, if you have a shared secret key you can transfer the encryption (authentication and authorization) from the transport layer to the application layer.
Aviad P.
Yes, but that would be an answer to a different question than was asked.
GregS
A: 

You could enforce that all requests come from the same IP address that the authentication was done from. This would make hijacking a lot harder, I think. Quite a few sites do this, or have the option.

ZoFreX
a man in the middle could spoof his ip address. granted, he wouldn't get any replies but he could still send his requests.
Matt
actually, if he really is "in the middle" he can get the replies too.
SpliFF
I took from the question that the aim of the attack was to take control of the session, as in perform actions, not simply view what is going on which is obviously trivial.
ZoFreX
by spoofing the ip he can do exactly that
Matt
no, that cannot be enforced.
GregS
if you're behind the same NAT, IP restriction won't help a lot since the site will be seeing the same global IP. This would includes lots of schools, workplaces, intruded WLANs etc.
snemarch
GregS: Why not?I didn't say it was a good idea or that it would fix the problem, just that it makes hijacking harder, and it does. Before, you could sniff the session cookie and use it. Now, you have to do that *and* present the same IP, either by being on the same network or by spoofing it somehow.
ZoFreX
+2  A: 

It depends on what you mean by pointless. :) You are correct that in a standard setup, where you're creating a session over HTTPS, and then reverting to HTTP but passing a session cookie (say) around with your requests, that the theoretical "guy in the coffee shop" can in fact see your data and/or take actions on your behalf.

The downside of using all-SSL (HTTPS) is traditionally that it is expensive from a server-side computation standpoint as well as incurring computation the client side. (Dollars and servers for the site, slower-loading pages for you.)

Therefore running most of a site in the clear has traditionally been considered an "acceptable risk" for most uses of the web.

The two risks you face are having your data be visible to others, and having others be able to act as you (by using your cookies, which they can steal). When designing a new site, you should think about the relative risks of both of these things. Notice that financial institutions will always serve all of their pages over HTTPS because the risk is not acceptable-- every page contains sensitive data, and even eavesdropping is bad. Gmail provides an opt-in option to get HTTPS for all sessions, too. (Facebook doesn't, though, nor does e.g. Yahoo! Mail).

You've probably noticed that many sites that run primarily over HTTP will protect critical settings changes with password re-authentication. This is one reason why they do this: even if the guy in the coffee shop can read your Facebook posts going by, he can't change your password and lock you out without knowing your current password.

Philosophically, my guess is that over time an increasing number of services with private user data will be pressured to move to (or offer) all-HTTPS as people become aware of the risks and as use of public Wifi networks increases.

quixoto
A: 

Sites which care so little about security as to not use SSL consistently are likely to be insecure in multiple ways. For example, they probably have the login form itself delivered on an unencrypted page. The attacker can simply change the https form post destination to an unencrypted on and he now has your password.

Once you're exchanging everything in the clear can't a man in the middle begin hijacking your session again?

Yes.

It's like locking the front door of a house without exterior walls.

even if the guy in the coffee shop can read your Facebook posts going by, he can't change your password and lock you out without knowing your current password

Can he take over your session cookie? Can he change your email address? Can he request a password reset email? Can he make you say dumb stuff in public forums? Probably.

He certainly can replace every https link on every page with http. Google for "SSLStrip". More than likely, the victim is never going to end up on an https page again. So when the victim clicks on the "change my password" link, the attacker gets the old (and new) passwords in clear text.

  • Marsh
Marsh Ray