User: Password:
|
|
Subscribe / Log in / New account

Gathering session cookies with Firesheep

Gathering session cookies with Firesheep

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

>Am I clear now?

This is the only coherent argument of this point that I've ever seen, and I thank you for it.


(Log in to post comments)

Gathering session cookies with Firesheep

Posted Nov 11, 2010 2:49 UTC (Thu) by filteredperception (guest, #5692) [Link]

>>Am I clear now?

>This is the only coherent argument of this point that I've ever seen, and I thank you for it.

+1. I'm glad my eyes didn't glaze over this long thread and I kept skimming till that explanation. I too required that explanation before I finally 'got it'.

Gathering session cookies with Firesheep

Posted Nov 11, 2010 3:10 UTC (Thu) by filteredperception (guest, #5692) [Link]

>>Am I clear now?

>This is the only coherent argument of this point that I've ever seen, and I thank you for it.

Ok, I too value that explanation, because it is the essence of the counterargument against the argument that allowing self-signed certs without warnings would be a net improvement.

But after a couple minutes of hopefully actually grokking this explanation of subsequent potential net-banking mitm attack vectors, this thought occurred to me-

Isn't the only added hurdle to pulling off this attack the need to get a non-self-signed cert? Which sure, is a bit of a relative pain and cost compared to a self-signed cert, but if you were mitm attacking peoples bank accounts, wouldn't getting a valid (effectively disposable) cert be just a 'cost of doing criminal business?'. Sure in the process of getting the cert, you have to leave some identity information, use a credit card, but in my estimation of current global security, I tend to imagine that the criminals could do those things effectively anonymously.

And if in the unlikely event that both my understanding of the issue, and that subsequent analysis are correct, then the question is- which is the bigger net gain for society- the benefits of facilitating easy https encryption with self-signed certs, or the benefits of adding the go-buy-or-steal-a-real-cert hurdle to bank attackers? And I think I'd lean towards the former. But odds are I'm still misunderstanding various aspects of this...

Gathering session cookies with Firesheep

Posted Nov 11, 2010 3:57 UTC (Thu) by foom (subscriber, #14868) [Link]

> Isn't the only added hurdle to pulling off this attack the need to get a non-self-signed cert?

You can't get just *any* non-self-signed cert. It has to be a cert valid for the domain name the user is trying to access, signed by one of the certification authorities trusted by the browser.

And that's not a completely trivial thing to do with just a small application of money.

It's only trivial if you happen to run one of the ~500 trusted root or intermediate CAs (e.g. most major governments in the world, and a few companies besides), or have enough money to infiltrate one.

Gathering session cookies with Firesheep

Posted Nov 11, 2010 5:24 UTC (Thu) by dlang (subscriber, #313) [Link]

that sort of thing has happened. it's been documented to happen to www.microsoft.com and there's no reason to believe that it can't happen with a bank as well.

but if you watch out for the cert changing, as opposed to just the cert existing, you cover most of that problem

Gathering session cookies with Firesheep

Posted Nov 11, 2010 5:43 UTC (Thu) by filteredperception (guest, #5692) [Link]

> You can't get just *any* non-self-signed cert. It has to be a cert valid for the domain name the user is trying to access, signed by one of the certification authorities trusted by the browser.

duh, OK, I figured I was missing something. Hmmm... Maybe the real issue is that certs cost $$ for no good reason, and that is the central issue impeding much more widespread use of https.

Gathering session cookies with Firesheep

Posted Nov 13, 2010 10:31 UTC (Sat) by gerv (subscriber, #3376) [Link]

Certs don't "cost $$ for no good reason". If all you want is a Domain Verified cert, get one from StartCom for free. And if you want an EV cert, the CA has to do a load of checks (see cabforum.org for the document listing them all) and that costs money, so you should expect to pay. Any CA can sign up to issue them, with the relevant audits, so it's not a closed market and there is competition.

Gerv

Gathering session cookies with Firesheep

Posted Nov 13, 2010 23:40 UTC (Sat) by Simetrical (guest, #53439) [Link]

You're right that if you can get an illegitimate cert, the entire PKI falls apart. However, the cert has to match the domain, and certificate authorities will have their trust revoked by browsers (making their certs useless) if they're found to be giving certs away to people who don't actually control the domains they're for. Typically you have to at least control the e-mail for a domain to be able to get a cert for it. Large governments could probably get hold of illegitimate certs easily enough, but it's quite nontrivial for anyone else. And even for governments, a forged cert is inherently detectable, so any complicit CAs could be eventually found out and get removed from browsers' trusted lists.

This problem will potentially go away in the medium term with DNSSEC. Once sites can deploy certificates through DNSSEC, there's no reason we couldn't also devise a DNS record that says "only accept certificates from DNSSEC, not certificates that claim to be signed by CAs". Then the only way to publish a false certificate for the site would be to compromise their DNS, which gives you many fewer attack vectors than now, when you can compromise (or trick or bully) any one of hundreds of CAs.

There's been discussion about adding a feature like this to Strict-Transport-Security, so you can say "only accept a cert signed by this root CA". Then an attacker has to compromise a *specific* CA to compromise the site instead of being able to compromise *any* CA, making their job much harder.

Gathering session cookies with Firesheep

Posted Nov 14, 2010 11:59 UTC (Sun) by anselm (subscriber, #2796) [Link]

[…] and certificate authorities will have their trust revoked by browsers (making their certs useless) if they're found to be giving certs away to people who don't actually control the domains they're for.

Yeah right. Like this happened to VeriSign in March, 2001.

Gathering session cookies with Firesheep

Posted Nov 14, 2010 12:11 UTC (Sun) by gerv (subscriber, #3376) [Link]

Is it your contention that a single mistake by a CA should mean they are thereafter disqualified from being included in browsers until the end of time?

There's a difference between a mistake (which happen to the best of us) and wilfully ignoring the necessary rules and safeguards, or a history of mistakes which leads to a diagnosis of institutional incompetence. I suggest that Verisign is guilty of neither of the latter two things.

In addition, the certificate(s) in the incident you reference were digital code-signing certificates, not web server certificates. Very occasionally, web server certs do fall into the wrong hands (which can be via hacking and theft as much as misissuance - how many SSL-running web servers do you think were rooted in the past year?) but I'd be impressed if you can show me a single reported incident where a fraudulently-acquired web server cert was used for spoofing.

Gerv


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds