Your assertion that using "bought" certificates provides any security benefit whatsoever assumes facts not in evidence.
Given recent failures in this space I would posit that the requirement to use certificates purchased from entities "under the thumb" of government control, clearly motivated only by profit, and with highly questionable moral and ethical standards represents a huge increase in risk of passive attack and confidentiality failure where such rosk did not previously exist.
backing up some, I think the problem trying to be solved by requiring
'legitimate' certificates is stopping the obvious problems of mitm
attacks, ala mallory-proxy.
in the longer term, if the client can know that the server was
supposed to present a cert with fingerprint XFOOBYFOOB and it can see
that fingerprint for the cert presented in the session we all win,
right?
I would say those claiming certificates from a public CA provide no
assurance of authentication of server identity greater than that of a
self-signed one would have the burden of proof to show that it is no
less likely for an attempted forger to be able to obtain a false
"bought" certificate from a public trusted CA that has audited
certification practices statement, a certificate improperly issued
contrary to their CPS, than to have created a self-issued false
self-signed certificate.
It is certainly contrary to some basis on which web browser
implementations of HTTPS and TLS in practice rely upon.
While there have been failure in that area, regarding some particular
CAs, and some particular certificates, the reported occurrences of
this were sufficiently rare, that one doubts "obtaining an
improperly issued certificate from a widely trusted CA" is an easy
feat for the most likely attackers to accomplish.
So I would be very interested in any data you had to show that a CA
signature provides no additional assurance; Especially, when
combined with a policy of requiring manual human verification of the
certificate fingerprint, and manual human agreement that the CA's
CPS is strict enough for this certificate usage, after all the
automatic checks that it was properly signed by a well-known CA with
an audited CPS statement,
with the usage of the certificate key matching an allowed usage
declared by the Type/EKU/CA attributes of the subject and issuer
certs.
I would say those claiming certificates from a public CA provide no
assurance of authentication of server identity greater than that of a
self-signed one would have the burden of proof to show that it is no
less likely for an attempted forger to be able to obtain a false
"bought" certificate from a public trusted CA that has audited
certification practices statement, a certificate improperly issued
contrary to their CPS, than to have created a self-issued false
self-signed certificate.
Do you ever buy SSL certificates? For cheap certificates ($9
Geotrust, $8 Comodo, free Startcom, all accepted by Gmail), the
entirety of the identity validation is to send an email message to an
address associated with the domain, typically one of the WHOIS
addresses, or hostmaster@domain, and look for a click on an embedded
URL. Sometimes they flag names that look particularly funky, such as
typos of famous names, but usually they don't.
So the only assurance a signed cert provides is that the person who
got the cert has some authority over a name that points to the mail
client, which need have no connection to any email address used in
mail sent from that server. That doesn't sound like "authentication
of server identity" to me.
R's,
John
Do you ever buy SSL certificates? For cheap certificates ($9
Geotrust, $8 Comodo, free Startcom, all accepted by Gmail), the
entirety of the identity validation is to send an email message to an
address associated with the domain, typically one of the WHOIS
addresses, or hostmaster@domain, and look for a click on an embedded
These CA's will normally require interactions be done through a web
site, there will often be captchas or other methods involved in
applying for a certificate that are difficult to automate.
They require payment, which requires a credit card, and obtaining a
massive number of certificates is not a practical thing for malware to
perform, unless they also possess a mass amount of stolen credit
cards, and stolen WHOIS e-mail address contacts; on the other hand,
self-signed certificates can be generated on the fly by malware, using
a simple command or series of CryptoAPI calls.
I am aware of the procedure the CAs follow, and I am well aware that
there are significant theoretical weaknesses inherent to the
procedures that are followed to authenticate such "Turbo", "Domain
auth" based SSL certificates. (They use an unencrypted e-mail
message to send the equivalent of a PIN number, for getting a
certificate signed, in reliance of WHOIS information downloaded over
unencrypted connection: WHOIS data may be tampered with, a MITM may
be used to alter WHOIS response in transit to the CA --- the PIN
number in confirmation e-mail can be sniffed in transit, or the
contact e-mail address may be hosted by a 3rd party insecure service
provider and/or no longer belong to the authorized contact).
All of these practices have considerable risks, and the risk that
_some_ fraudulent requests are approved is signicant.
The very e-mail server the certificate is to be issued to, might be
the one that receives the e-mail, and a passive sniffer there may
capture the PIN required to authorize the certificate.
However, the procedures required to exploit these weaknesses are
slightly more complicated than simply producing a self-signed
certificate on the fly for man in the middle use -- they require
planning, a waiting period, because CAs do not typically issue
immediately.
And the use of credit card numbers; either legitimate ones, which
provide a trail to trace the attacker, or stolen ones, which is a
requirement, that reduces the possible size of an attack (since a
worm, or other malware infection, won't have an infinite supply of
those to apply for certificates).
But "Does the CA's signature actually represent a guaranteed
authentication" wasn't the question.
The only question is... Does it provide an assurance that is at all
stronger than a self-signed certificate that can be made on the fly?
And it does... not a strong one, but a slightly stronger one.
You're kidding, right? Captchas have been quite, quite thoroughly beaten
for some time now. See, among others:
http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html
http://cintruder.sourceforge.net/
http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/
http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html
http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html
http://it.slashdot.org/article.pl?sid=08/10/14/1442213
---rsk
However, the procedures required to exploit these weaknesses are
slightly more complicated than simply producing a self-signed
certificate on the fly for man in the middle use -- they require
planning, a waiting period, because CAs do not typically issue
immediately.
Hmmn, I guess I was right, you haven't bought any certs lately. Startcom typically issues on the spot, Comodo and Geotrust mail them to you within 15 minutes. I agree that 15 minutes is not exactly the same as immediately, but so what?
And the use of credit card numbers; either legitimate ones, which
provide a trail to trace the attacker, or stolen ones, ...
or a prepaid card bought for cash at a convenience or grocery store.
Really, this isn't hard to understand. Current SSL signers do no more than tie the identity of the cert to the identity of a domain name. Anyone who's been following the endless crisis at ICANN about bogus WHOIS knows that domain names do not reliably identify anyone.
The only question is... Does it provide an assurance that is at all
stronger than a self-signed certificate that can be made on the fly?And it does... not a strong one, but a slightly stronger one.
I supose to the extent that 0.2% is greater than 0.1%, perhaps. But not enough for any sensible person to care.
Also keep in mind that this particular argument is about the certs used to submit mail to Gmail, which requires a separate SMTP AUTH within the SSL session before you can send any mail. This isn't belt and suspenders, this is belt and a 1/16" inch piece of duct tape.
R's,
John
wait, no... this was gmail's pop crawlers gathering mail from remote
pop services wasn't it? (or that was my impression at least).
so this is, I think, an attempt by gmail/google to protect their users
from intermediaries presenting a certificate for 'floof' self-signed
instead of iecc.com ...
-chris
Really, this isn't hard to understand. Current SSL signers do no more
than tie the identity of the cert to the identity of a domain name. Anyone
who's been following the endless crisis at ICANN about bogus WHOIS knows
that domain names do not reliably identify anyone.
So you're saying that you'd have no problems getting a well-known-CA signed
certificate for, say, pop.mail.yahoo.com? If you can't, then it would seem
that the current process provides (at least) a better mechanism than just
blindly accepting self-signed certificates, no?
Also keep in mind that this particular argument is about the certs used to
submit mail to Gmail, which requires a separate SMTP AUTH within the SSL
session before you can send any mail. This isn't belt and suspenders, this
is belt and a 1/16" inch piece of duct tape.
Err.. no it's not. It's about the certs used when Gmail connects to a
3rd-party host to collect mail. ie, Google is the client, not the server.
Scott
There's a bit more trust (not much, but a bit) to be attached to a
cert signed by a reputable CA over and above that you should attach
to a self-signed cert you've never seen before.
However, if you trust a CA-signed cert more than you trust a self-signed
cert *that you yourself created*, there's probably a problem there someplace.
(In other words, you should be able to tell Gmail "yes, you should expect
to see a self-signed cert with fingerprint 'foo' - only complain if you
see some *other* fingerprint". To the best of my knowledge, there's no
currently known attack that allows the forging of a certificate with a
pre-specified fingerprint. Though I'm sure Steve Bellovin will correct
me if I'm wrong... 
No, you're quite correct. Depending on what you assume, that would take
a preimage or second preimage attack. None are known for any current hash
functions, even MD5.
I think, though, that that isn't the real issue. We're talking about a
feature that would be used by about .0001% of gmail users. Apart from
code development and database maintenance by Google -- and even for Google,
neither is free -- it requires a UI that is comprehensible, robust, and
doesn't confuse the 99.9999% of people who think that a certificate is
something you hang on the wall. (Aside: do you remember how Netscape
displayed certs -- in a frame with a curlicue border? These are *certificates*;
they should look the part, right? I'm just glad that the signature wasn't
denoted by 3-D shadowing on a "raised" seal....) Furthermore, the UI has
to have a gentle way of telling people that the cert has changed, which
may be correct. (Recall that for some of these users, they didn't create
the cert; it was done by the admin of a site they use.) Do you run Cert
Patrol (a Firefox extension) in your browser? It's amazing how much churn
there is among certificates used by big sites (including Google itself).
Certificate pinning is a great idea for experts, but it requires expert
maintenance. I haven't yet seen a scalable, comprehensible version.
I wish Google did support this, but I don't think it's unreasonable of
them not to. Recall that they've been targeted by governments around the
world, precisely the sort of adversary who can launch active attacks. Now,
if you want to say that these adversaries can also corrupt CAs, whether
they do it technically, procedurally, financially, or by sending around
several large visitors who know where the CEO's kids go to school -- well,
I won't argue; I certainly remember the Diginotar case. There may even
be a lesser threat from using self-signed certs, since these large
individuals operate on a human time frame, so it's more scalable to hit
a few large CAs than a few thousand dissidents or other targets of
interest. I think, though, that there are arguments on both sides.
(The issue of you yourself accepting your own certs is quite different, of
course.)
--Steve Bellovin, https://www.cs.columbia.edu/~smb
What other assurance are you looking for?
The only point of a signed server certificate, the ONLY point, is to
prevent a man-in-the-middle attack where someone who doesn't control
the name decrypts the traffic from the server, reads it, and then
re-encrypts it with his own self-signed key before sending it to you.
If the signature accomplishes that goal, it has done 100% of what it's
designed to do.
In theory a signature can mean anything the signing authority defines
it to mean. In practice, that also requires special handling from the
users... behavior web browser users don't engage in.
As for Google (and anyone else) it escapes me why you would require a
signed certificate for any connection that you're willing to also
permit completely unencrypted. Encryption stops nearly every purely
passive packet capture attack, with or without a signed certificate.
Even without a signed cert an encrypted data flow is much more secure
than an unencrypted one. It's not an all-or-nothing deal. Encrypted
with a signed or otherwise verified cert is more secure than merely
encrypted which is more secure than unencrypted on a switched path
which is more secure than unencrypted on a hub. None of these things
is wholly insecure and none are 100% secure.
Regards,
Bill Herrin
As for Google (and anyone else) it escapes me why you would require a
signed certificate for any connection that you're willing to also
permit completely unencrypted. Encryption stops nearly every purely
raising the bar for observers is potentially a goal, no?
making it simple for people to get 'more secure' email isn't a bad
thing. (admittedly, requiring a signed cert now is more painful,
though startssl.com makes it less so).
passive packet capture attack, with or without a signed certificate.
Even without a signed cert an encrypted data flow is much more secure
than an unencrypted one. It's not an all-or-nothing deal. Encrypted
with a signed or otherwise verified cert is more secure than merely
encrypted which is more secure than unencrypted on a switched path
which is more secure than unencrypted on a hub. None of these things
is wholly insecure and none are 100% secure.
boiling down the above you mean:
goodness-scale (goodness to the left)
signed > self-signed > unsigned
I don't think there's much disagreement about that... the sticky
wicket though is 'how much better is 'signed' vs 'self-signed' ? and I
think the feeling is that:
'if we can verify that the cert is proper/signed, we have more
assurance that the end user meant for this cert to be presented. A
self-signed cert could be any intermediary between me/you... we have
no way to verify who is presenting the cert.'
-chris
(note the use of 'we' here is the 'royal we', I have no idea what the
real reason is, but the above makes some sense to me, at least.)
goodness-scale (goodness to the left)
signed > self-signed > unsigned
Hi Chris,
Self-signed and unsigned are identical. The "goodness" scale is:
Encrypted & Verified (signed) > Encrypted Unsigned (or self-signed,
same difference) > Unencrypted but physically protected > Unprotected
I don't think there's much disagreement about that... the sticky
wicket though is 'how much better is 'signed' vs 'self-signed' ? and I
think the feeling is that:
I don't see how "feeling" plays into it.
Communications using an unverified public key are trivially vulnerable
to a man-in-the-middle attack where the connection is decrypted,
captured in its unencrypted form and then undetectably re-encrypted
with a different key. Communications using a key signed by a trusted
third party suffer such attacks only with extraordinary difficulty on
the part of the attacker. It's purely a technical matter.
The information you're trying to protect is either sensitive enough
that this risk is unacceptable or it isn't. That's purely a question
for the information owner. No one else's opinion matters for squat.
Regards,
Bill Herrin
While I agree with your general characterization of MIIM, the
"extraordinary difficulty" here is not supported.
As has been demonstrated, the bar for getting certs from some trusted
CAs is in some cases low enough that it's not even difficult, much
less extraordinarily difficult. Getting certs to a well known domain
may be somewhat harder, it might be useful to see how far someone got
trying to get a "mail.google.com" cert from all the commonly trusted
vendors without resorting to illegal penetrations or layer 8+ hacking
/ social engineering / threats / intimidation / politics, but even if
we exclude those threats the general envelope for not-well-known
domains seems risky.
Google is setting a higher bar here, which may be sufficient to deter
a lot of bots and script kiddies for the next few years, but it's not
enough against nation-state or serious professional level attacks.
The advantage for the deterrence it can give may well be worth it
anyways, for the near future. Every measure in security that does not
involve the off switch is a half-measure, at least in the long term,
even very large key crypto, but enough incremental steps form a useful
cushion.
I think we're talking past eachother 
I also think we're mostly saying the same thing...
I think though that the 'a question for the information owner' is
great, except that I doubt most of them are equipped with enough
information to make the judgement themselves.
-chris
AFAICT someone finds a way to get themselves a certificate for a
domain they don't control every couple years or so. The hole is
promptly plugged (and the certs revoked) before much actually happens
as a result. Has your experience been different?
Are you, at this moment, able to acquire a falsely signed certificate
for www.herrin.us that my web browser will accept?
You're right that false certificates have been issued in the past.
You're right that false certificates will be issued again in the
future. No security apparatus is 100% effective. But if despite your
resources you in particular can't make it happen in a timely manner,
that's a meaningful barrier to mounting a man-in-the-middle attack
against someone using properly signed certificates.
Regards,
Bill Herrin
Much of the evil in the world starts with the presumption that
otherwise competent individuals can't make good decisions for
themselves.
Regards,
Bill Herrin
Are you, at this moment, able to acquire a falsely signed certificate
for www.herrin.us that my web browser will accept?
Me, no, although I have read credible reports that otherwise reputable SSL signers have issued MITM certs to governments for their filtering firewalls.
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
There are three vectors of attack:
One, asking a CA for a cert in someone else's name and it gets issued.
As you noted, generally discovered pretty quickly and shut down, but
there's no robust external verification for the discovery process.
Also, the verifications the CAs perform to validate the user could be
subverted, as noted earlier in conversation, so they could receive
false assurances that it was the right entity asking for the keys.
That subversion could happen via registrar account hacking (known
problem) among other places, along with technical measures to monitor
unencrypted validation emails sent to proper authoritative domain
contact emails.
Two, a CA's keys can go walking (either due to technical penetration
or human corruption), and then external parties can issue their own
certs as if they were the CA. If identified the CA can revoke its own
key and re-issue all the client certs from a new one, but someone
needs to identify that it happened. This is alleged to have happened
at least twice, once of which the CA was shut down over, the other one
of which became opaque and ambiguous, and therefore untrustworthy.
Three, there may be crypto flaws we don't know about still lingering,
or a CA could choose easily factored numbers by bad luck and someone
could luck out grinding them. Not a high risk (anyone SHOULD grind
their own keys some to check them for that) but nonzero.
Can I go get a key for your site right now? I'm not going to spend
the afternoon trying (I'm working for a living) but I am reasonably
sure I could do so. Lax checks by CAs are well described elsewhere.
If push came to shove and minor legalities were not restraining me, I
recall (without checking) your domain's emails come to your home, and
your DSL or cable line is sniffable, so any of the CA who email URL
validators out could be trivially temporarily spoofed (until you read
your email and responded) by tapping your data lines. BGP games to
snarf your traffic are another venue, possibly not yet even covered by
wiretap laws that I know of, though I'm not currently an ISP in a
position to personally do that to you.
The same is possible but slightly harder for midsized corporate
entities. Still possible but much harder for large ones.
If you're going to argue that that's cheating, that IS the threat envelope...