Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
This is the only coherent argument of this point that I've ever seen, and I thank you for it.
Gathering session cookies with Firesheep
Posted Nov 11, 2010 2:49 UTC (Thu) by filteredperception (guest, #5692)
>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'.
Posted Nov 11, 2010 3:10 UTC (Thu) by filteredperception (guest, #5692)
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...
Posted Nov 11, 2010 3:57 UTC (Thu) by foom (subscriber, #14868)
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.
Posted Nov 11, 2010 5:24 UTC (Thu) by dlang (✭ supporter ✭, #313)
but if you watch out for the cert changing, as opposed to just the cert existing, you cover most of that problem
Posted Nov 11, 2010 5:43 UTC (Thu) by filteredperception (guest, #5692)
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.
Posted Nov 13, 2010 10:31 UTC (Sat) by gerv (subscriber, #3376)
Posted Nov 13, 2010 23:40 UTC (Sat) by Simetrical (guest, #53439)
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.
Posted Nov 14, 2010 11:59 UTC (Sun) by anselm (subscriber, #2796)
[…] 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.
Posted Nov 14, 2010 12:11 UTC (Sun) by gerv (subscriber, #3376)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds