Gathering session cookies with Firesheep
Posted Nov 4, 2010 16:06 UTC (Thu) by gerv
In reply to: Gathering session cookies with Firesheep
Parent article: Gathering session cookies with Firesheep
I am saying that neither the security of telnet nor the security of SSH (when you don't bother to check the key fingerprints) is sufficient for people to do online banking or shopping. At the moment, "secure UI and no warnings" in a web browser means "safe to do online shopping and banking".
If we switched to an SSH-style key change detection model for web site security, then "secure UI and no warnings" (it is the warnings you want to get rid of, isn't it?) would no longer give that safety.
If that's the case, then it's clearly a bug. These situations are entirely orthogonal.
Not so. Say you run a website which uses a self-signed cert. Your website gets compromised. You clean it up and start it up again, with a new cert (the old private key is known to the attacker, after all). Or perhaps your cert just expires. Either way, you change the cert. The user gets a warning saying "the cert has changed". What do they conclude? "Someone is trying to MITM me" or "the site admin just updated the cert"? Which would you tell them to conclude? How would you tell them to decide?
In the CA model, as long as both certs were signed by a trusted CA, the user gets no warning in the safe case, and a warning in the unsafe case (because the attacker can't get a CA-signed cert for the domain).
I don't really care,
If you don't really care that Joe Public gets MITMed, then I don't think we are working from the same base set of assumptions, and it's unlikely this discussion will be fruitful. For me, I'm trying to stop Joe getting MITMed, as are the rest of the Mozilla security team. If you don't care, then we clearly have different security goals. Feel free to create your own browser which meets them.
to post comments)