3 ms·
Never mind the fact that if any of the authenticated traffic goes over the wire in the clear (post-login), The Great Firewall could snarf sessionIDs and replay
by ax0n 17y ago
Never mind the fact that if any of the authenticated traffic goes over the wire in the clear (post-login), The Great Firewall could snarf sessionIDs and replay them. This is the concept used in Errata Security's Hamster/Ferret tools. You don't need a username or a password to read their gmail, update their facebook status, or anything. And if any part of the session happens without https, the whole session is at risk.
- tptacek 17y agoThis is the whole reason for the HTTP Cookie "Secure" flag: so that session IDs set over HTTPS aren't inadvertently handed out over HTTP. If you log in at https://mail.google.com https://mail.google.com, your entire session is encrypted. If you log in via http://mail.google.com http://mail.google.com, your password is safe, but your session ID isn't.
- ax0n 17y agoGood point. Also, Moxie Marlinspike's tool, SSLStrip, can break some of this stuff as well. I haven't tested it against the relatively few sites that go out of their way to set the Secure flag.