Gathering session cookies with Firesheep

Posted Nov 9, 2010 17:25 UTC (Tue) by nye (subscriber, #51576)
In reply to: Gathering session cookies with Firesheep by gerv
Parent article: Gathering session cookies with Firesheep

>I am saying that neither the security of telnet nor the security of SSH ... is sufficient for people to do online banking or shopping

Nobody claimed it was. Stop making things up.

>Not so. ... 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 think I understand what you mean by this now, and it's really the same as the next point.

>If you don't really care that Joe Public gets MITMed

I was very upset to read this, and nearly responded in a very inflammatory manner, but fortunately I gave myself time to cool off.

It appears that you have deliberately and in bad faith removed the important part of that sentence in order to change its meaning entirely. In fact your entire argument against anyone who disagrees with you seems to be based around the use of ridiculous straw men, so I see that there is no point in attempting rational discourse with you.

Gathering session cookies with Firesheep

Posted Nov 9, 2010 17:44 UTC (Tue) by gerv (guest, #3376) [Link] (3 responses)

Nobody claimed it was. Stop making things up.

With a small allowance for shorthand, yes they were. People are claiming that the SSH "notify on key-change" model, a.k.a. the self-signed cert model of security, is sufficiently secure to build into web browsers. And if it's built in, Joe Public will be using it, because he's using a tool which supports it. And having a security mode in a consumer product, used for banking or shopping, which does not have sufficient security for those activities is foolish.

I have not "changed the meaning of your sentence entirely". You said you didn't care if Joe Public could tell the difference between two situations, one of which involved them being MITMed, and the other of them involved them not being MITMed. I interpreted this as you not caring if Joe was MITMed. That does not seem like an unreasonable inference. If you don't care if he can tell if he's being MITMed, then you must not care if it happens to him.

I'm sorry you don't rate the quality of my argument. All I can say is that I and a large number of fairly bright people at Mozilla have spent quite a long time thinking about this, and come under regular pressure to make these sort of changes, with people advocating all sorts of reasons. We have heard and considered all the arguments, pretty much. And the case for making this change in consumer-facing browsers just doesn't stack up.

Gerv

Gathering session cookies with Firesheep

Posted Nov 10, 2010 6:21 UTC (Wed) by ekj (guest, #1524) [Link] (2 responses)

The thing is, it's a strawman, because an ordinary https-certificate, even one that's signed by a CA, is *also* not considered good enough for a bank, and infact, atleast where I live (Norway) I'm fairly sure no bank goes without extended validation or whatever it's named.

That causes significant and clear gui-changes, namely a large green bar stating the name of the institution.

In contrast, https causes a tiny grey padlock to appear in the bottom-right corner, next to the Sync-icon, which is pretty close to totally nonvisible.

Yes, I get the point that https:-self-signed has an identical url to https:-with-certificate and that thus users with bookmarks is at risk. (few users enter the url with https: Joe Public has by this time LONG gotten used to not typing http(s):// instead if they enter the address at all, they go for "www.mybank.com". That often redirects to https://www.mybank.com/ but I don't think a large fraction of users would notice if it stopped doing that.

AND - and that's my most significant point: The question isn't if a change would cause harm. The question is if the benefits would outweigh the harm, or vice versa. One practical consequence of the current situation, is that self-signed, is essentially not-usable. And encryption of any sort whatsoever is, essentially, not available for everyone hosting a simple website on a shared-ip-address which means probably 95% of the websites in the world.

The practical result of this decision, despite being made for reasons of security -- is that nearly all websites have no encryption whatsoever.

Gathering session cookies with Firesheep

Posted Nov 10, 2010 7:32 UTC (Wed) by dlang (guest, #313) [Link]

you would be surprised at how many banks don't use EV certs.

and frankly, I don't blame them. In many ways the EV certs are a way for a cartel of cert providers to be able to charge $1500/cert and cut outtheir competition that has ruined their prior scam of $900 for a 128 bit cert and $250 for a cert that would drop to 40 bits if a export browser connected to it (not that there are any of those around anyway)

the amount of real checking done is still not that much.

Gathering session cookies with Firesheep

Posted Nov 10, 2010 8:29 UTC (Wed) by anselm (subscriber, #2796) [Link]

There is nothing special about EV certificates except their extortionate price tag and the fact that they have a magic flag set which will cause the site name to show up on a green background in the browser. You don't get to produce your own EV certificates the way you can produce ordinary certificates (e.g., using OpenSSL) because the magic flag is CA-specific, and browsers that support EV certificates contain a hard-coded list of the CAs which are part of the EV certificate cartel and their corresponding magic flags.

Basically, for EV certificates, the CAs that are in on the game promise that they will actually do the sort of checking they should have been doing for all certificates in the first place. That is, somebody applying for an EV certificate for an entity will have to prove that the entity really exists at the specified address. This is then used to justify a vastly increased price for the certificate.