

Comodo will just issue you an SSL cert for anyone - tptacek
https://blog.startcom.org/?p=145

======
tptacek
Ben Laurie is right though; the fact that shoddy CAs will cut you a cert for
MOZILLA.COM (or presumably anyone else) without verifying who you are does
kind of steal some of the thunder from today's announcement.

What's really fucked up here is that Verisign will _never hear the end of it_
about mistakenly issuing a Microsoft certificate in 2001 --- it was just
mentioned again in the New York Times --- but in 2008 Comodo can just mint
certificates for random companies without checking, and all it merits is a
blog post.

------
mechanical_fish
Let me ask some basic questions, that I might someday know what I'm talking
about on this topic.

I can self-sign certs. The problem is that no browser recognizes my self-
signed certs, so they put up dialog boxes filled with warnings. (Which many
users will just dismiss without a second thought, since they are very used to
their machines crying wolf. But let's ignore that big problem for now.)

So the problem is that some of the CAs whose credentials are pre-installed and
pre-trusted in various browsers or clients turn out to have shoddy
verification practices. Does the answer to this involve Mozilla, Webkit,
Microsoft _et al._ decertifying these CAs, which would turn them into the
equivalent of someone like me, signing certificates in his basement?

I guess the problem with that is that all the existing paying customers of
these CAs would wake up one day to find that their certs don't work anymore
and that their money was wasted.

What _is_ the answer to this problem? What kind of contract do you have to
sign to become a CA, and with whom?

~~~
tptacek
Yes, that's just about the nut of it.

If you ask me, the biggest problem is that we've acclimated the whole user
population of the Internet to ignorance and a cavalier attitude towards
security. Companies like Comodo "get away" with stuff like this because people
see certificates as a nuisance --- they're a pain to request, a pain to
install, and they make browsers complain.

The fact is that SSL simply doesn't work without the PKI component. The PKI
component is _most_ of the actual security in SSL. But because technical
people get away with saying "even if you're not authenticated, you're at least
encrypted", it isn't the end of the world when Comodo (or RapidSSL) screws up.

As for "what kind of contract do you need to sign", what you need to do is
convince Microsoft and Mozilla to add you to their root CA store; both
organizations have standards and practices, and both incur an audit, and
neither are particularly inclined to add more CA's (there's a bit of
grandfathering that appears to happen here).

~~~
jerf
"But because technical people get away with saying "even if you're not
authenticated, you're at least encrypted", it isn't the end of the world when
Comodo (or RapidSSL) screws up."

Speaking for myself, the causality flows in the other direction. Because there
will always be somebody like Comodo who will issue certs with insufficient
verification (Comodo being an _extreme_ but there's been a long history of
merely _insufficient_ verification; ISTR a lot of "fax me a letter on official
letterhead", which is just total BS), the PKI component of SSL, being
basically a binary yes/no system, is fundamentally flawed. Market forces
compel a race to the bottom in this situation and there's just no way around
it. (Not even moving it to a government function; _nobody_ is immune to having
money waved under their nose.) So _all you get_ from SSL is encryption, not
authentication. Whether you like it or not.

If you really insist on the dichotomy of "SSL provides either perfect security
or no security", then the answer is, it provides no security, because it is
impossible to use it properly.* The legitimate owner can do everything right
and still get CA-rooted with non-zero (and significant-in-practice)
probability.

If that's a problem, get designing and implementing.

* Or, even more precisely, the _only_ proper use is to use a separate communications channel with the website to verify the key they are sending out, regardless of who putatively signed the cert. And this use is a myth in the general case, because I can't imagine more than the barest fraction of SSL sites have ever gotten this query and I bet the majority of organizations would either have no idea what to tell you since you can't talk to the guy who knows (if any), or would even think you were a hacker or something trying to get something from them you shouldn't.

~~~
tptacek
Everything you put in the footnote there? That's how SSL actually works. Your
computer shipped with a browser (a seperate communications channel) with
trusted anchor keys.

~~~
jerf
No. I'm saying, the trusted anchor keys aren't trusted. You _think_ they're
trusted, but they aren't. The trust necessary for SSL to be truly secure can't
exist in the real world. If you're not checking the site's key directly with
no reference to the trusted keys, you don't have "security".

------
cscott
And this isn't even the first blog post to mention the fact that a CA gave out
a cert to unauthorized person...

Mike Zusman tested a group of CA issuers and received a cert for Microsoft's
live.com and talked about it at Blackhat this year:
[http://schmoil.blogspot.com/2008/08/domain-validated-ssl-
cer...](http://schmoil.blogspot.com/2008/08/domain-validated-ssl-
certificates.html)

Additional information at:
[http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=1...](http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=1202423911432)

------
vaksel
do average people even care about a lack of SSL? Do they even notice if a site
doesn't have one? I honestly don't see an average user being savvy enough to
look for one.

Seems to me, that for most people the presence of SSL is completely
meaningless.

Does anyone have any concrete data on the effects of SSLs on sales that comes
from a neutral source?

~~~
cscott
If you accept credit card payment without SSL protecting the entry of the card
and CVV2, you are in violation of PCI DSS standard 4.1. Depending on your
relationship with your acquiring bank or payment processor, that will result
in a passthrough of fines and any fraudulent charges that are incurred, along
with possible termination of your account.

Now, for the research on SSL and UI, there is good research on this. My
favorite is The Emperor's New Security Indicators -
<http://www.usablesecurity.org/emperor/>

"We confirm prior findings that users ignore HTTPS indicators: no participants
withheld their passwords when these indicators were removed. We present the
first empirical investigation of site-authentication images, and we find them
to be ineffective: even when we removed them, 92% participants who used their
own accounts entered their passwords. We also contribute the first empirical
evidence that role playing affects participants' security behavior: role-
playing participants behaved significantly less securely than those using
their own passwords."

~~~
graemep
Users will be happy with no encryption than with a self signed cert.

Personally i think the best solution would be SSH style for most sites (the
certificate is stored on first visit and changes are flagged as suspicious),
with physical distribution of public keys for sites that really needed
security (e.g. banks).

