Why is Firesheep unable to session hijack when a user is using SSL?
2 Answers
It needs to read the content of the HTTP transactions between the victim's computer and the remote server. SSL features point-to-point encryption using a key that's negotiated by the two systems, so a third system passively eavesdropping cannot read the content.
Note that it is possible to inspect SSL content by interposing the attacking system between the two parties. This is called man-in-the-middle, and is used by corporate content filters so that they can filter both HTTP and HTTPS communication.
-
2"Note that it is possible to inspect SSL content by interposing the attacking system between the two parties. This is called man-in-the-middle, " - This should be reworded since SSL is supposed to, and indeed can, prevent this. The corporate content filters described work by breaking SSL using a horrible kludge that involves a self-inflicted compromise of SSL's trust model :-) – frankodwyer Apr 20 '11 at 14:06
-
1@frankodwyer: which still means it's possible ;-) – Apr 21 '11 at 09:38
-
1@graham - not in the firesheep 'coffee shop' scenario though, or at least it is possible for the user to detect it (granted, this doesn't mean the average user will, I'd fully expect most of them to dismiss the browser warning and carry on regardless - indeed if I hadn't had my coffee yet I might myself :-) – frankodwyer Apr 21 '11 at 09:45
-
@frankodwyer your parenthesis expresses almost everything that is wrong with SSL. "Dear user, here's some stuff that I, a developer, understand and you do not. However, I have decided that you should be the person to decide what we do here." The remaining stuff that is wrong is brought to you by the letters C and A. – Apr 21 '11 at 10:50
The web browser and the web server establish an encrypted connection before any HTTP communication, so when the session data is exchanged it is within the encrypted tunnel and is protected from man-in-the-middle attacks or eavesdropping.
For details, check out the SSL sequence diagram from: http://www.eventhelix.com/RealtimeMantra/Networking/
Technically Firesheep could session hijack SSL connections, but then you would likely get a warning from the browser about establishing an untrusted connection, for example:
If this:
you <--- SSL ---> attacker <--- SSL ---> bank.com
then:
![](../../users/profiles/22.webp)
- 13,714
- 3
- 40
- 83
-
In my opinion the warning is not explicit enough for users. There are no good scenarios where end user should probably continue ahead. The we "can't confirm" the connection is secure = "it might be secure" in the eyes of most non-technical users. The biggest problem with SSL is the assumption that the user knows what to do when something goes wrong. The reality is they don't and while 100% of users may not click "I understand the risks" some significant portion will. – Gerald Davis Mar 06 '14 at 20:09