![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
But...
Federico, self-signed certificates disproportionally affect programmers (particularly Free Software programmers) using random homebrew bugzilla instances. For a website with any kind of real user base, the hosting fees and salaries of the programmers/designers/etc. are going to dwarf (by orders of magnitude) the cost of a SSL certificate. Does it suck that you have to pay a fee to avoid a dialog? Sure. But rather than complain, some smart person needs to think of a way to make a distributed system that actually works with non-cryptographic expert people in some way; i.e. doesn't just ask you "Do you trust this hex number"?
(Anonymous)
DNS
(Anonymous)
Say no
(Anonymous)
Say yes
(Anonymous)
Re: Say yes
Key Continuity Management and/or things like TLS/SRP help leverage an initial reliable connection or credential exchange into ongoing secure communications, but in the absence of those technologies being widely deployed -- and in the absence of a secure initial credential exchange! I do not think we want to have to do the equivalent of PGP key signing parties in order to get private web communication -- the SSL CA model is the best on offer. Like many security systems, it is fragile with respect to removal of parts. Take the S-boxes out of DES, your system is weak enough to be useless. Take most of the random seed out of openssl key generation, your system is weak enough to be useless. Take the ability to verify the endpoint site's identity out of SSL, and your system is weak enough to be useless.
I wish fervently that it weren't so, but self-signed certificates are basically just security theatre: the appearance of additional security relative to naked HTTP, but nothing really gained. Arguably, security is _lost_, because it still appears as https, which means that people tend not to treat the connection as one that can be snooped or modified.
There are lots of ways to solve this problem, including a bunch of free projects sharing a common cert-signing key which is then distributed through a verified chain, but we're seeing far less energy devoted to that than to complaining that Firefox reflects the reality of SSL's limitations.
Mike Shaver
Re: Say yes
Yes, it's entirely possible for DNS to be hijacked or whatever, and you get redirected to somewhere else. So, get a certified VeriSign cert, you say. Oh shit, we just got rooted, and look, your password is just as compromised! Awesome! I'm glad we know exactly whose compromised machine is leaking our passwords!
It's a best-effort thing: I can't be 100% certain who I'm talking to (can you ever?), but at least no-one along the way will see it. Sort of like how GSM is encrypted yet provides no endpoint identity guarantee. 'But what's the point of preventing people from listening in if you can't be sure it's not just someone impersonating your boss's voice?!? If you can't be sure it's someone else from work and not some random chav or a phonejack, why not tell EVERYONE?'.
This sort of bullshit is why no-one takes security people seriously. If every call you made (but to 1-800 numbers) required you to press five buttons on your phone, everyone would just reflexively press them and add exceptions. Wham, congratulations, you feel like you've made a difference, users are merely pissed off.
I'm happy for you in your world where everything is end-to-end encrypted with identity verification (not that keysigning parties are hard to subvert or anything: do you know how to distinguish a fake Australian passport or Victorian drivers' license from a real one? but that isn't your fault, so). Really, I am. But as they say, 'perfect is the enemy of good', and your dichotomy of zero security or encryption as well as identity verification is a stupid one.
Daniel, bugs.fd.o admin, thrilled about Firefox 3's security theatre
Re: Say yes
Re: Say yes
Re: Say yes
Re: Say yes
Perhaps the problem there is indiscriminately showing https as secure, regardless of trust in the cert?
Also, there is a trivial way in which using a self-signed cert is more secure than no encryption: if the cert ever changes, the browser can notice and warn about that (much like how OpenSSH will give you "host key changed" warnings). If you saw the right cert in the first place (which is typically pretty likely) then even this minimal measure has protected you.
And even if you initially saw and the wrong cert, then you'll probably notice when the environment changes (connecting your laptop from a different network, or whatever) and you see the right cert. Either way you notice that something bad is going on, even if it's not as soon as it could be.
Basically, the "why use SSH at all" argument has this implicit assumption that you can either be totally secure, or totally insecure. In reality, you can be in between. You can be more secure than totally insecure, and there seems to be no shortage of people saying that that is good enough for them.
(Anonymous)
Re: Say yes
The complaints you're seeing are that we present that dialog at _all_, even once for a site, and that we don't make it trivial to press [whatever] whenever there's a mismatch.
Here's another case to ponder: expired certs. When someone gets an error message for the expired cert, they will often run to their twitter client/livejournal/mailing list and complain that it's just all a big scam for us to make more money for CAs (from whom we don't get a penny for our pains, to be clear). But right now, in the wild, we have thousands -- likely many thousands -- of fully verified certificates with weak keys, courtesy of Debian's OpenSSL mistake. Those certs will expire in time, and with any slight bit of luck CAs will be checking for those failkeys when issuing renewals, but guess what the _only_ thing distinguishing those new keys from the old and trivially-compromised ones is? That the old ones have expired.
(I don't understand the argument that SSL providing no useful guarantees is OK because someone could root the box. But I think the big disconnect is that I think that it's point-and-click easy to mount a MITM attack on any setup that permits passive snooping, and Daniel thinks it's a significant barrier. Given the incredible rise in the role of "professional" attackers in internet security issues, and the availability of truly trivial tools for doing full-on MITM, I think that the model of a passive attacker running tcpdump somewhere is unfortunately, naively, and dangerously outdated. I very much hope I'm wrong, and can return to my former belief that self-signed certs were a reasonable compromise; everything I hear from people who track attack characteristics is pointing the other way so far, though. :( )
Mike Shaver
(Anonymous)
zyLutMLGYpDpUo