290491 - Thawte has started issuing SSL certificates without identification requirements

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Kyle Hamilton]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: ALL

Thawte Consulting Pty, Ltd has begun issuing certificates from its root CA (no 
longer even through a subordinate CA, which is what they had been doing) to 
domains which need now not have any identity verification performed more 
than "ownership of the domain".  This is a golden ticket to phishing 
attackers.  Please remove trust in the Thawte CA, until verification that a 
certificate meets an identification policy (i.e., O=, OU=, S=, L=, C= 
certificate attributes exist) can be coded into NSS or such.

I have NO idea where this bug is supposed to be submitted -- I've never seen a 
case where a root certificate started violating its own trust policies before.

Quoted from https://www.thawte.com/ssl123/index.html :

------

thawte now offers an SSL certificate, which is issued within minutes* at an 
affordable price - introducing SSL123. 

SSL123 is thawte’s response to customers’ demands for a fast turnaround, SSL 
certificate. So, here it is… a cost effective thawte digital certificate that 
can be issued quickly and still carries the thawte hallmark of trust. 

New: SSL123 certificates contents can now include Internationalized characters 
including Internationalized Domain Names. Click here to find out more about 
this great new feature. 

So, what does purchasing a thawte’s SSL123 certificate do for your business? 

A thawte SSL123 certificate provides validation that your domain is registered 
and that you have authorized the purchase of the certificate. 
Through SSL encryption, the certificate assures that information is kept 
private between your web server and your clients' web browsers. 
The certificate inspires trust in those who are considering 
communicating/transacting with you. 

It’s fast, it’s affordable… and it’s a great base from which to build an 
online business. 

Why SSL123? 

thawte’s traditional focus when issuing certificates has been on ensuring 
unrivaled authentication of company details. The feedback that we have been 
given from extensive market and customer research tells us that while these 
procedures are crucial for the security of many businesses, there is also a 
need for some customers to obtain a more affordable SSL certificate quickly. 
Enter SSL123 – an entry-level digital certificate that is also capable of 
providing industry standard 128-bit encryption. 

The result? 

Lower cost digital certificates issued within minutes* of confirmation of your 
order. 

What you still get from thawte that you won’t get elsewhere 

FREE reissues throughout the lifespan of the certificate. 
Full, FREE and uncompromised multi-lingual global support ( live online chat 
for sales and customer support). 
24x5 FREE technical support 
Highly trained support staff to cover all global time zones. 
In thawte, you are dealing with a Root Certification Authority. This means 
that thawte is not reliant on another entity’s infrastructure to deliver the 
core benefit of the product. 
The value of one of the most trusted brands in digital security. 
So, need that SSL certificate today? 

Click here to purchase a thawte SSL123 Certificate. 

-------------------------------------------------------------------------------

* Please note that delays in issuance can be caused if your domain is not 
registered with an accredited online registrar. For details on processing 
requirements, please refer to thawte's Practices Updates and Notices by 
clicking here.



Reproducible: Always

Steps to Reproduce:
1. N/A
2.
3.

Actual Results:  
N/A

Expected Results:  
N/A

Comment 1

[Frank Hecker]

This is basically the issue of CAs issuing "domain-validated" certificates,
i.e., certificates where the CA validates simply that the certificate applicant
controls the domain in question. (Thawte is by no means the only CA offering
such certificates; it's becoming fairly common in the CA business.) As it
happens, we have been discussing this issue for quite some time now in the
context of the proposed CA certificate policy:

  http://www.hecker.org/mozilla/cert-policy-submitted

The bottom line is that people disagree as to whether domain-validated certs are
a good or bad thing on balance; for examples of both sides of the debate see

  http://www.comodogroup.com/news/press_releases/28_02_05.html
  http://www.techworld.com/security/news/index.cfm?NewsID=3468

vs.

  http://geotrust.com/resources/advisory/sslorg/
  http://geotrust.com/resources/white_papers/pdfs/SSLVulnerabilityWPcds.pdf

My personal opinion is as follows:

1. Lower-cost domain-validated certs provide a potentially useful service,
particularly as a way to encourage more people to SSL-enable their web sites and
avail themselves of the protections SSL affords.

2. Domain-validated certs do not necessarily pose undue risk to users compared
to more traditionally-issued certs. No one has conclusively shown that there's
currently a security problem associated with the use of domain-validated certs
(as opposed to people speculating that there might be a problem in the future).
Also, it is not a foregone conclusion that traditional certs are in fact more
"secure" (in the sense of the verification processes making a real difference)
than domain-validated certs; see for example the arguments Geotrust makes in the
above-referenced documents regarding traditional CA verification processes being
susceptible to fraud by cert applicants.

3. As a consequence of 1 and 2, banning the use of domain-validated certs is
overkill and potentially counter-productive.

4. However, since domain-validated certs are in fact a different class of
product than traditional CA-issued certs, we should look at potential ways to
bringing the difference to the attention of users, for example by changing the
browser UI to more prominently display the CA name, cert product name (e.g.,
"SSL123"), generic class of cert ("domain-validated"), etc.

To the bug reporter: If you want to follow the Mozilla project debate on this
topic, go to

  http://groups-beta.google.com/group/netscape.public.mozilla.crypto  

and search for "domain-validated" or "certificate policy". You'll find plenty of
reading material. See also my other blog posts on the subject of our proposed CA
certificate policy:

  http://www.hecker.org/mozilla/

some of which have links to relevent discussion threads.

Finally, note that bugs relating to the inclusion or exclusion of CA
certificates can be filed against the product "mozilla.org", component "CA
certificates", and by default will be assigned to me.

To Dan: Feel free to either reassign this bug to me or to close the bug as a
duplicate of other bugs (e.g., bug 233453 regarding having a formal policy on
root CA certs).

Also, there is no point in having this bug be security-sensitive. This issue has
been discussed extensively in public forums, and I myself have posted about the
Thawte SSL123 certs. However out of courtesy I won't remove the flag myself but
will rely on one of you to do it.

Comment 2

[Kyle Hamilton]

A review of Thawte's "Certification Practice Statement" states that under the
terms which they have made public, they are not allowed to issue
"domain-validated certificates" from their roots.  The CPS is incorporated by
reference into all of their user, subscriber, and issuer agreements.  Thus,
their actions are a breach of contract.

The trust which is extended to Thawte (for financial transactions -- remember,
SSL was originally designed as a means for people to do their own due diligence
and protect their credit card information from interception or unauthorized
disclosure) is only extended if they uphold their commitments.

There is nothing stopping Thawte from creating another CA, one which is not
covered by the current CPS, and issuing domain-validated certificates from that
root.  However, the fact that they're issuing these certificates from a root
that is trusted because they committed to NOT issue domain-validated
certificates means that they are breaching trust.  They are breaching their
commitments.

The reason I marked this 'security sensitive' is because of the wonderful
opportunity of phishing.

(Domain-validated certificates are perfectly valid and wonderful things, as long
as they're not used for financial transactions.  Unfortunately, the current
Firefox/Mozilla/et al and all-other-browser UIs don't currently differentiate
between a CN=-only certificate and a CN=,C=,O=,OU=,S=,L=-present certificate.

(At the VERY least, forms submittal needs to be modified to enforce a policy of
"warn if O= isn't present".)

As for the complaints that GeoTrust makes related to fraud possibility -- it
raises the bar for fraud to be able to take place.  It requires that the fraud
be committed /to the CA/ -- and thus be actionable by the CA itself, and the
CA's reliance on the document submission be a business practice to reduce its
own risk (taking such steps as verifying with the city that the organization
exists and is properly licensed, verifying with the secretary of state that the
corporation name is valid, and getting the articles of incorporation, etc --
thus requiring that fraud be done to multiple agencies, and thus making the
penalties larger).

Contrast that to a domain-validated cert -- no fraud has to take place to the
CA, the fraud occurs to the relying party (the person who relies on the fact
that the certificate is issued by a company it trusts).  There's no UI
difference to say that the certificate presented has not given the same level of
scrutiny before issuance.

...and that entire argument is a red herring.

Since when does anyone have to wait for a fraud to occur when they can see plain
as day that there's no procedural safeguard to prevent it from happening?  This
would (IANAL) make the Mozilla organization liable, for not taking steps to
reduce the possible fraud upon advisement that the fraud can occur... and in
certain places (including California), you can't waive your right to sue for
negligence under a clickwrap license.

The bottom line: Thawte has broken the terms under which it has been trusted. 
It must thus have that trust removed.  If that would break too many things, then
the user interface itself has to be modified to notify the user that the
certificate was not issued with strong identity credentials, and to be careful
when submitting data to the site identified with that certificate.

Comment 3

[Frank Hecker]

A couple of (hopefully) quick comments:

1. I may not have made myself clear on the "security-sensitive" issue. Setting
the security-sensitive flag on a bug report marks it as a private bug that is
viewable only by a very small set of people. It's usual use is in limiting
disclosure of security vulnerabilities that are reported to the Mozilla project
but are not yet known to the world at large.

In this case phishers are already aware that they can obtain domain-validated
certs from Thawte and other CAs, and the pros and cons of CA certificates have
been extensively discussed in public forums, most notably the Mozilla forums. I
see no purpose in keeping this bug confidential; you're only denying yourself to
get a wider hearing for your views. However our policy is that the bug reporter
gets to control disclosure of the bug (within limits), so I'm not going to
remove the security-sensitive flag at this time.

2. Whether Thawte has violated contracts by adding issuance of domain-validated
certs is a legal issue. My concern is rather with potential security issues
involving our end users. In this case my opinion is that there is no clear and
imminent threat that would warrant yanking out the Thawte root cert, and I
prefer the approach of looking at a UI-based strategy. (Phishing is certainly
going on right now, but with non-SSL sites primarily AFAIK.)

There are people in the Mozilla project considering ways to change the UI to
make clear to users the distinctions between certs of different types. That
conversation is going on in the public n.p.m.security newsgroup:

http://groups-beta.google.com/group/netscape.public.mozilla.security

3. My personal recommendation is that this bug be resolved as WONTFIX, since I
don't think removal of the Thawte root cert is warranted, at least at this time.
I recommend that you participate in the discussion referenced above, and
consider filing a separate bug against the "Firefox" product requesting UI
changes relating to domain-validated certs.

Comment 4

[Kyle Hamilton]

...so why can't I unmark it "Security-Sensitive"?  The checkbox is checked, and
greyed out.  (This may be an issue with Bugzilla itself, but I can't clear the
checkbox.  If you can, please do.)

The problem with a "legal issue", as you put it, is that security can only be
maintained through a series of assurances -- Thawte was originally trusted by
Netscape (and has had its trust carried through to Mozilla and Firefox) because
of the contractual obligations they made to the certificate users that they
wouldn't do anything like this.  The fact that they violated that obligation
means that they /cannot be trusted any longer/.  (They are, as far as I can see,
committing fraud against everyone who relies on their certificates, because the
reason for that reliance -- Thawte's commitment -- has been abrogated.)

That you don't see this as a "far-reaching security hole that affects Mozilla's
customers" is in itself not necessarily a bad thing, as the world takes all
views.  However, I also must point out that Thawte's practice is not consistent
with commercial requirements, nor is it in keeping with ANY of the three
acceptable CA procedures that you set forth in the Release Candidate for the
Mozilla CA Certificate Policy.  (To whit: All three state that the terms of the
certification practices statement must be adhered to.)  I realize that this
document has not been officially ratified yet, but that the author of the
document is arguing for maintained inclusion for a CA that is in violation of
the terms of the document that he wrote is hypocritical at best and makes me
have to wonder about undisclosed connections at worst.

(And the fact of the matter is, I wouldn't have minded overmuch, if Thawte had
continued to chain those SSL123 certificates through a secondary root.  However,
when I was attempting to obtain a copy of the chained root so that I could
explicitly distrust it, Belina at Thawte mentioned that they're now issuing
those certificates directly from Thawte's Server CA, with no chaining.  So I
can't just distrust only those certs, I have to distrust ALL of Thawte's certs.)

Also: I attempted to send a message to mozilla-crypto with my thoughts on the RC
of the proposed CA policy; I got a message back saying that the moderator will
have to approve it.  I can't find a subscription address for that list on
mozilla's website, and the message didn't provide a subscription address either.
 How can I subscribe to the mozilla-crypto list?

Comment 5

[Frank Hecker]

re posting to the mozilla-crypto list, I was not aware moderation was in effect.
(I read and post to this list using the newsgroup to which it is gatewayed.) The
instructions for the mozilla mailing lists are at

http://www.mozilla.org/community/developer-forums.html

Also, I'm removing the security-sensitive flag (if I can).

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I'm moving this bug to the same product and component as the other 
bugs about CA certs.

Comment 7

[Gervase Markham [:gerv]]

As suggested by Frank in comment #3, I am marking this bug WONTFIX. Domain validated certs are now, for better or worse, an established part of the certificate landscape.

A discussion is about to begin in the newsgroup mozilla.dev.apps.firefox about security UI in Firefox 3, led by UI lead, Mike Beltzner. This would be a very good place for people to discuss how best to express the current situation to users in an understandable way.

Gerv