Control of domain certs: an example
Frank Hecker
particular so-called "control of domain" certs. What we've lacked is any
informed discussion of real-world examples of such certs.
So in order to correct that I went off this morning and attempted to
obtain "control of domain" certs from two CAs: Thawte's SSL123 service
and Go Daddy's TurboSSL service, for my personal domain www.hecker.org.
Here are my experiences:
Thawte SSL123:
This service requires generating a CSR with at least CN, coutry, and
state filled in; CN is used for the server domain name.
Verification is done by sending an email to either the domain contact
address (as supplied by the customer and presumably verified against the
whois database) or to a webmaster@domain-style address. I chose the
latter option.
(Note that in my case I actually use my ISP-provided email address for
the whois contact, to protect against someone hacking my site and using
my email account to hijack my domain; the Thawte process allows an
attacker to bypass this protection.)
I wasn't actually able to complete the Thawte process, because they
wouldn't accept any of my credit cards, so my cert application is in
limbo until/unless that gets straightened out. However it appears that
the cert would look something like the following (pasted from the Thawte
certificate application status page):
Organization: www.hecker.org
OrgUnit: Domain Validated
OrgUnit: Go to https://www.thawte.com/repository/index.html
OrgUnit: Thawte SSL123 certificate
Common: www.hecker.org
Total cost: $149 (or it would be if/when my card gets charged).
Go Daddy TurboSSL:
I used the same CSR as I generated for Thawte, just for consistency;
thus I don't know if I could have omitted the country and state. Again,
CN is used for the server name. Verification is done by sending an email
to the address listed in whois; the applicant does *not* have the option
of specifying an alternate address, so the verification email went to my
ISP email account (as I would prefer). My first credit card wouldn't
work again (have to check that card out!) but a second card did; note
that Go Daddy (unlike Thawte) requires entering your verification code
(or whatever it's called) that's printed on the physical card, a nice
touch. Go Daddy also uses those image-based authentication codes where
you have to enter the text on the image ("captchas" or whatever they're
called) to discourage automated submission of applications (another nice
touch).
Cert approval was fairly quick; I was emailed a ZIP file containing the
issued cert, an intermediate CA cert required for proper chaining, and
installation instructions for a variety of web servers. I installed the
certs into Apache, and you can see the results at
Note that Go Daddy stuffs the domain name and "domain control validated"
into the O and OU fields I had left empty.
Downsides: I was confused by Go Daddy's account mechanism. I got a login
id and password (for a new customer account) at the time I bought the
cert, logged in under that id, and then had to enter another password to
manage my SSL certs. (In the Go Daddy scheme you pay first, then go
through the process of submitting your CSR and other info; this is the
reverse of the Thawte procedure.)
I also had problems when my first credit card wouldn't work; the error
page had a link to go back and reenter the information, but instead of
sending me back to such a page I got into an endless loop of "captcha"
pages. I eventually had to go back to the beginning and go through
checkout again.
Total cost: $29.95 (on sale, regularly $49.95).
Final note: The Go Daddy cert appears to be accepted with no problems in
Firefox 1.0.1, MS Internet Explorer 5.2 for Mac, and Safari. I presume
it would work fine in IE for Windows as well (somebody tell me if it
doesn't) and that Thawte's cert (if I ever get it :-) would work in all
these browsers as well.
Frank
--
Frank Hecker
hec...@hecker.org
Ian G
> We've been discussing the issue of "lower assurance" certs, and in
> particular so-called "control of domain" certs. What we've lacked is any
> informed discussion of real-world examples of such certs.
Excellent stuff!
> So in order to correct that I went off this morning and attempted to
> obtain "control of domain" certs from two CAs: Thawte's SSL123 service
> and Go Daddy's TurboSSL service, for my personal domain www.hecker.org.
> Here are my experiences:
I would like to challenge your methodology slightly,
but I don't think it matters much and if you or
someone else wants to try they can fix this.
By using a credit card you have identified yourself.
If your credit cards are in the name of "Frank H"
then that represents a reasonable low grade identity
check.
Now, I don't think it matters that much as the certs
you purchased would almost certainly not have checked
that the name of the card matches the domain name (it
was just a coincidence that in this case it might
have)
*BUT* there is still one further issue: You have
placed an identity token on their files.
This means they have some way to come back to you.
(Or, hypothetically, if your CC charge gets chargebacked,
they can revoce ;)
The sum total of this is that all of these certs are
more or less sold on the same foundation as those of
CACert, with the sum total of difference being that
the CACert checks are much more authoritive than say
Thwarte, GoDaddy, etc etc.
Now, *another* furfy in this is that I know that it
is possible to purchase the certs from Equifax and
other places for less-identity craving monies like
e-gold, so no identity token is needed there. What
I'm not sure of is whether one can do it without
being known to the vendors, as I acquired mine from
mates.
Still, all in all, a great experiment. If anyone
wants to repeat this experiment, I suggest using the
credit card of a friend and seeing what happens.
Unfortunately, to experiment with chargeback and
seeing if this resulted in a revocation result
would mean fraud, so that's more difficult to do,
we will have to await some friendly phisher to
help us with that experiment.
> Thawte SSL123:
>
> This service requires generating a CSR with at least CN, coutry, and
> state filled in; CN is used for the server domain name.
>
> Verification is done by sending an email to either the domain contact
> address (as supplied by the customer and presumably verified against the
> whois database) or to a webmaster@domain-style address. I chose the
> latter option.
Wow. It should go to both! How dumb.
> (Note that in my case I actually use my ISP-provided email address for
> the whois contact, to protect against someone hacking my site and using
> my email account to hijack my domain; the Thawte process allows an
> attacker to bypass this protection.)
Right.
> Final note: The Go Daddy cert appears to be accepted with no problems in
> Firefox 1.0.1, MS Internet Explorer 5.2 for Mac, and Safari. I presume
> it would work fine in IE for Windows as well (somebody tell me if it
> doesn't) and that Thawte's cert (if I ever get it :-) would work in all
> these browsers as well.
Works fine on Konqueror as well. (My firefox has
too many bugs for primary use, I only use it for
blog posting, where it works better :-/ Hopefully
the 1.0.1 upgrade for FreeBSD will fix the bugs.)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Ram A M
Frank Hecker wrote:
> We've been discussing the issue of "lower assurance" certs, and in
> particular so-called "control of domain" certs. What we've lacked is
any
> informed discussion of real-world examples of such certs.
>
> So in order to correct that I went off this morning and attempted to
> obtain "control of domain" certs from two CAs: Thawte's SSL123
service
> and Go Daddy's TurboSSL service, for my personal domain
www.hecker.org.
> Here are my experiences:
<details of experience including CC and whois or @domainofinterest
email round trip for Thawte SSL123 and the same with the addition of
CCv2 validation for Go Daddy TurboSSL>
> Final note: The Go Daddy cert appears to be accepted with no problems
in
> Firefox 1.0.1, MS Internet Explorer 5.2 for Mac, and Safari. I
presume
> it would work fine in IE for Windows as well (somebody tell me if it
> doesn't) and that Thawte's cert (if I ever get it :-) would work in
all
> these browsers as well.
Seems like if you had preferred to get a more sinister name you
could've done so. This seems to support a policy of requiring
programmatic revocation checking for higher risk activities.
Gervase Markham
> Final note: The Go Daddy cert appears to be accepted with no problems in
> Firefox 1.0.1, MS Internet Explorer 5.2 for Mac, and Safari. I presume
> it would work fine in IE for Windows as well (somebody tell me if it
> doesn't)
More comment on the rest to come but: it does work in IE on Windows.
Gerv
Nelson B
> Frank Hecker wrote:
>> https://www.hecker.org/
>
> </me visits domain and inspects cert>
>
> Blimey, our cert examination UI sucks rocks. <sigh>
Yeah, PSM-related UI has stood still for ~2 years. :(
> This whole situation is an disaster waiting to happen, isn't it?
Well, Let's consider your remarks in another message, that we're in the
judgement business, and your grandmother doesn't want tools to decide,
she wants to be safe.
If we admit only CAs to the list who are worthy of your grandmother's
trust, then I'm not so sure it's a disaster waiting to happen. OTOH,
if we admit CAs that necessitate tools, and do not supply them, then
yes, disaster waiting to happen.
With respect to the tool users vs. Grandmothers debate, it seems that
the mozilla developer community is heavy on tool users, but the mozilla
user community is heavy on mothers and grandmothers. A single product
with only a single mode of security operation cannot satisfy both groups,
IMO. IMO, mozilla products need "grandmother" mode, and "advanced mode"
(or maybe "geek mode"), and out-of-the-box should run in "grandmother" mode.
--
Nelson B
Gervase Markham
> Thawte SSL123:
>
> This service requires generating a CSR with at least CN, coutry, and
> state filled in; CN is used for the server domain name.
It seems (not that it's important) that there's no checking of the
Country and State values you give?
> Go Daddy TurboSSL:
>
...
> that Go Daddy (unlike Thawte) requires entering your verification code
> (or whatever it's called) that's printed on the physical card, a nice
> touch.
Well, it makes it less likely a stolen card number can be used - you
need the card, or access to a database with the verification code.
> Cert approval was fairly quick; I was emailed a ZIP file containing the
> issued cert, an intermediate CA cert required for proper chaining, and
> installation instructions for a variety of web servers. I installed the
> certs into Apache, and you can see the results at
>
> https://www.hecker.org/
</me visits domain and inspects cert>
Blimey, our cert examination UI sucks rocks. <sigh>
This whole situation is an disaster waiting to happen, isn't it? The
only reason phishers aren't exploiting this is because they don't need
to yet - there's enough dumb people out there who are happy to type all
their details into an insecure form.
Gerv
Ian G
>> This whole situation is an disaster waiting to happen, isn't it?
>
>
> Well, Let's consider your remarks in another message, that we're in the
> judgement business, and your grandmother doesn't want tools to decide,
> she wants to be safe.
>
> If we admit only CAs to the list who are worthy of your grandmother's
> trust, then I'm not so sure it's a disaster waiting to happen. OTOH,
> if we admit CAs that necessitate tools, and do not supply them, then
> yes, disaster waiting to happen.
Your first case is still a "disaster waiting to happen,"
as we have no good way of predicting how to stop
grannie losing her house. All we can essentially do
is increase the "quality" of the CAs, according to
some definition of quality, which doesn't solve the
problem. In fact, it may make it worse, because it
makes it more valuable, and thus there will be more
reward in trying. So the fall, when it comes, will
be harder and more painful.
This is essentially the difference between the Visa
model and the Barings model. Barings was perfect,
until it fell and died within a weekend. Visa is
imperfect, and loses a little each time. But no
loss in its normal business is capable of killing it.
> With respect to the tool users vs. Grandmothers debate, it seems that
> the mozilla developer community is heavy on tool users, but the mozilla
> user community is heavy on mothers and grandmothers. A single product
> with only a single mode of security operation cannot satisfy both groups,
> IMO. IMO, mozilla products need "grandmother" mode, and "advanced mode"
> (or maybe "geek mode"), and out-of-the-box should run in "grandmother"
> mode.
That's something that might be suggested to the wider
community. Certainly, if the group feels it has hit
a stumbling block in delivering the tools and/or trust
to grannie, then it needs to debate the "average user"
policy. And let everyone know so not to many grannies
get signed up.
Ram A M
requires a multi-modal UI. I think I've posted my approach before
(brief 2-3 question interview at first launch of a profile "geek,
adult, grandmother" & "paranoid, sane, wild-west").
Gervase Markham
> If we admit only CAs to the list who are worthy of your grandmother's
> trust, then I'm not so sure it's a disaster waiting to happen. OTOH,
> if we admit CAs that necessitate tools, and do not supply them, then
> yes, disaster waiting to happen.
We already have CAs that necessitate tools, in that we have CAs who
issue certs with enough checking to make them fairly safe for CC
numbers, and CAs who issue certs without such checks.
> With respect to the tool users vs. Grandmothers debate, it seems that
> the mozilla developer community is heavy on tool users, but the mozilla
> user community is heavy on mothers and grandmothers. A single product
> with only a single mode of security operation cannot satisfy both groups,
> IMO. IMO, mozilla products need "grandmother" mode, and "advanced mode"
> (or maybe "geek mode"), and out-of-the-box should run in "grandmother"
> mode.
The approach Firefox has been taking has been to make Firefox itself
grandmother mode, and to provide an extension architecture for geeks to
add an advanced mode of their choice. This reasoning has worked well in
other areas of the UI.
My target audience in my thinking is certainly grandmother (or would be
if either were still alive ;-). She's not stupid, but she just wants to
use the computer as as tool, and so has limited brain space for learning
things.
Gerv
Hendrik Weimer
> Verification is done by sending an email to either the domain contact
> address (as supplied by the customer and presumably verified against
> the whois database) or to a webmaster@domain-style address. I chose
> the latter option.
I looked at InstantSSL's verification process recently. They even
propose some addresses which are not mandatory role accounts
(e.g. sysadmin). So if you can get one of these localpart from your
mail provider, you will be able to get a valid cert for the domain as
well.
Some comments on http://www.hecker.org/mozilla/ca-certificate-policy
(if these issues have been discussed already, pointers would be
appreciated):
It is obvious that a domain control cert has a different level of
trust than a cert where the organization has been verified using real
world methods. The draft does not distinguish between these, which
will mean that the latter will offer no benefits but will be more
expensive. A related issue is that a cert for www.pay-pal.com with
O=PayPal Inc. is acceptable according to the draft.
Domain control is a tricky thing. Obtaining control over a domain for
a short time is probably not too difficult and the time could be
enough to complete the certificate verification process. To avoid this
it would be possible to require domain control for a period of, say,
five business days. I don't know if any CA has implemented something
like that.
Hendrik
Nelson B
> Domain control is a tricky thing. Obtaining control over a domain for
> a short time is probably not too difficult and the time could be
> enough to complete the certificate verification process.
Indeed. The article shown at http://files.juraj.bednar.sk/CA documents a
case where that was easily done. Seems whois registry info was easily
altered.
Concerning the CA that he easily tricked, the author of that article wrote:
> They have quite low prices and even issue free 6-months certificates. They
> are in MS Trust Root (happily not in Mozilla),
Sadly, that is no longer true.
--
Nelson B
Frank Hecker
> Indeed. The article shown at http://files.juraj.bednar.sk/CA documents a
> case where that was easily done. Seems whois registry info was easily
> altered.
And as the author of the article also points out, faxed documentation
can easily be faked as well.
Peter Gutmann
>This whole situation is an disaster waiting to happen, isn't it? The
>only reason phishers aren't exploiting this is because they don't need
>to yet - there's enough dumb people out there who are happy to type all
>their details into an insecure form.
That's what's been amusing me about this whole high-assurance CA debate, you
can have any assurance level you want (a CA located under 30m of reinforced
concrete at the bottom of a surplus ICBM silo who only issues certs to people
who turn up in person and provide blood and DNA samples) and it won't matter a
bit because browser UI and site spoofing makes the whole thing irrelevant.
The only (known) time in which anyone has ever bothered attacking the
assurance of the PKI was the proof-of-concept "Microsoft" code-signing certs
from Verisign, because anyone who really wants to attack the system goes for
the UI or the wetware. As I mentioned in a previous post, doing any more work
on the PKI is irrelevant unless the UI issues are addressed - plugging the
mouseholes in the corner of the barn (PKI) isn't anything more than a
diversion as long as several of the barn walls (UI issues) are missing.
Peter.
Hendrik Weimer
> Hendrik Weimer wrote:
>
> > Domain control is a tricky thing. Obtaining control over a domain for
> > a short time is probably not too difficult and the time could be
> > enough to complete the certificate verification process.
>
> Indeed. The article shown at http://files.juraj.bednar.sk/CA documents a
> case where that was easily done. Seems whois registry info was easily
> altered.
Thanks for the interesting link. I think whois data was never meant to
be a reliable source of information and should not be abused as
such. Probably the only way to make sure that only the domain owner
receives the mail is to send it to postm...@domain.tld. However, the
other problems (MITM, password sniffing) mentioned in Juraj Bednar's
article still persist. It seems to me that it is a really bad idea if
domain control certs are included in browsers the same way as certs
with proper verification.
Another problem that came to my mind is how to deal with malicious
CAs. One way would be to make the costs of getting included in the
browsers higher than the possible profits out of malicious use of the
CA. But this is not really desirable and probably only a short-term
solution since the possible profits are increasing over time.
Hendrik
Ian G
> Nelson B <NOnels...@NObolyardSPAM.com> writes:
>
>
>>Hendrik Weimer wrote:
>>
>>
>>>Domain control is a tricky thing. Obtaining control over a domain for
>>>a short time is probably not too difficult and the time could be
>>>enough to complete the certificate verification process.
>>
>>Indeed. The article shown at http://files.juraj.bednar.sk/CA documents a
>>case where that was easily done. Seems whois registry info was easily
>>altered.
>
>
> be a reliable source of information and should not be abused as
> such.
The way identity and control tests fundamentally work
is that they take as many pieces of information as
they can get economically and confirm each one as being
consistent. So for identity and control purposes,
looking at the whois registry quite a reasonable idea.
It's when the number of tests sink down to 1 that it
gets a bit silly, but unfortunately, it's very hard to
say where the line is to be drawn. In some countries,
looking at the whois will be quite authoritive.
> Probably the only way to make sure that only the domain owner
> receives the mail is to send it to postm...@domain.tld.
How does that make you sure? Speaking as an ordinary
domain owner, I don't receive email at postmaster@me...
The only reason I know this is that there is about one
and only one place on the Internet that tells me my mail
is not being accepted because I don't receive email to
postmaster! I've never bothered to change this because
it isn't obvious - and all the other domains I know of
(across about 6-10 different administrations) probably
don't have it set either.
> However, the
> other problems (MITM, password sniffing) mentioned in Juraj Bednar's
> article still persist. It seems to me that it is a really bad idea if
> domain control certs are included in browsers the same way as certs
> with proper verification.
They are already there, aren't they? One would need to
propose that they be taken out.
> Another problem that came to my mind is how to deal with malicious
> CAs. One way would be to make the costs of getting included in the
> browsers higher than the possible profits out of malicious use of the
> CA. But this is not really desirable and probably only a short-term
> solution since the possible profits are increasing over time.
Yes, that whole area is a bit of a deal killer. The
cost of a CA is in the order of 100k, more and less.
(Anybody got any figures on that?)
The profits from phishing exceed the millions, so an
economic approach is not likely to be more than just
another cost for phsihers. That is, we might succeed
in raising the quality of our phishers.
Gervase Markham
> That's what's been amusing me about this whole high-assurance CA debate, you
> can have any assurance level you want (a CA located under 30m of reinforced
> concrete at the bottom of a surplus ICBM silo who only issues certs to people
> who turn up in person and provide blood and DNA samples) and it won't matter a
> bit because browser UI and site spoofing makes the whole thing irrelevant.
Don't assume this is the only thing we're doing. Read n.p.m.security and
my blog, and see recently-filed bugs for more ideas.
This will become a problem in the future, and we need to tackle it now.
Gerv
Nelson B
> The profits from phishing exceed the millions, so an
> economic approach is not likely to be more than just
> another cost for phsihers. That is, we might succeed
> in raising the quality of our phishers.
Give a man a fish and he eats for a day.
Teach a man to phish, and his net worth quickly exceeds your own!
Peter Gutmann
>Peter Gutmann wrote:
>> That's what's been amusing me about this whole high-assurance CA debate, you
>> can have any assurance level you want (a CA located under 30m of reinforced
>> concrete at the bottom of a surplus ICBM silo who only issues certs to people
>> who turn up in person and provide blood and DNA samples) and it won't matter a
>> bit because browser UI and site spoofing makes the whole thing irrelevant.
>Don't assume this is the only thing we're doing. Read n.p.m.security and
>my blog, and see recently-filed bugs for more ideas.
Right, and in one of my earlier posts I'd already suggested that the Firefox
folks go to your plan-for-scams page and implement the entire list :-).
Peter.
Hendrik Weimer
> The way identity and control tests fundamentally work
> is that they take as many pieces of information as
> they can get economically and confirm each one as being
> consistent.
This only works if an attacker is unable to fake a consistent picture.
> So for identity and control purposes, looking at the whois registry
> quite a reasonable idea.
It may be a good idea in some cases, and in other cases it is
not. Therefore I think that looking at whois information does not
provide a generally reliable way to increase the security of the
identification process.
> It's when the number of tests sink down to 1 that it
> gets a bit silly, but unfortunately, it's very hard to
> say where the line is to be drawn. In some countries,
> looking at the whois will be quite authoritive.
Maybe. But it is definitely out of the scope of a browser's CA policy
to address such issues.
> > Probably the only way to make sure that only the domain owner
> > receives the mail is to send it to postm...@domain.tld.
>
> How does that make you sure?
RFC 2821.
> Speaking as an ordinary domain owner, I don't receive email at
> postmaster@me... The only reason I know this is that there is about
> one and only one place on the Internet that tells me my mail is not
> being accepted because I don't receive email to postmaster! I've
> never bothered to change this because it isn't obvious - and all the
> other domains I know of (across about 6-10 different
> administrations) probably don't have it set either.
Well, if you have misconfigured your system, you cannot participate in
such an authentication process. Doesn't seem to be too harsh to me.
> > However, the other problems (MITM, password sniffing) mentioned in
> > Juraj Bednar's article still persist. It seems to me that it is a
> > really bad idea if domain control certs are included in browsers
> > the same way as certs with proper verification.
>
> They are already there, aren't they? One would need to
> propose that they be taken out.
I have already thrown out some, but I don't have a complete list.
> > Another problem that came to my mind is how to deal with malicious
> > CAs. One way would be to make the costs of getting included in the
> > browsers higher than the possible profits out of malicious use of the
> > CA. But this is not really desirable and probably only a short-term
> > solution since the possible profits are increasing over time.
>
> Yes, that whole area is a bit of a deal killer. The
> cost of a CA is in the order of 100k, more and less.
> (Anybody got any figures on that?)
The cost to implement and run a CA that meets the requirements set in
the policy draft is probably lower by one order of magnitude.
Hendrik
Ian G
in a lot of the below, you are disagreeing in
the detail of what I wrote, but agreeing in
the big picture. What I was trying to say
was that looking at whois is a roughly bad
test, like all the others, and ruling it out
isn't going to be a useful addition to the
policy.
On the specific issue of RFC 2821, my point
was to show that RFC 2821 may be a written
down document that you all abide by, but in
the real world it means nothing much more
or better than anything else. Looking at
the postmaster address is just another 'bad
test' among dozens of others.
Literally, all these tests are bad. They
are all fakeable in some sense or other. So
the only thing that a CA can do is do more
and more of the tests, and hope that this
raises the barrier - the cost - enough such
that it isn't worth it to an attacker.
In such a world, Frank's policy really has a
lot of trouble deciding what to rule out and
what to rule in.
iang
> the policy draft is probably lower by one order of magnitude.
>
> Hendrik