Closed Bug 477783 Opened 15 years ago Closed 13 years ago

Equifax not conforming to Mozilla CA Certificate Policy (7)

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: srv-net-mozilla.org-bugzilla, Assigned: hecker)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020410 Fedora/3.0.6-1.fc10 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020410 Fedora/3.0.6-1.fc10 Firefox/3.0.6

As you can see from the above URL RapidSSL verifies domain holders simply by submitting PINs via automated phone calls and then sending a verification to a more or less random email address within the domain.
With that procedure everyone with a clever account like keyman@ or sslmanager@ (aka something that *sounds* plausible) can order "trusted" SSL keys from RapidSSL.
IMHO this is not in conformance to the Mozilla CA Certificate Policy (paragraph 7).
In case of e.g. a (not so well known) Mail Service Provider this may have severe security implications when combined with pharming attacks. In combination with phishing attacks this may lead to widespread serious problems.

The Root CA signing RapidSSL Certs is
Issuer: C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
(see http://www.rapidssl.com/cps/rapidssl_01.cer)

I hereby request either demanding that RapidSSL signs their Certs with another Issuer than the above or to have the above Issuer removed from the list of builtin trusted CAs.

Reproducible: Always
Assignee: kathleen95014 → hecker
Initial thoughts:

- The telephone authentication step is so that they have a known-good phone number for you. It's not about domain control verification, and so is irrelevant to what we are doing here. The question is whether their email verification is up to scratch.

- The email verification works, it seems to me, like most DV domain control email verifications, with two possible exceptions:

1) I don't know how common it is to allow use of a non-WHOIS email
2) Of the alternative email addresses they list, perhaps three (ssladmin, admin, administrator) would not normally be reserved by the system. It could be argued that this presents a risk.

Gerv
The phone verification is basically useless when non-verified. In case of RapidSSL it has been widely known that the phone numbers are user provided, not independently validated.

Which email addresses do they allow? Any user supplied? A range of different emails? Which ones?
@Gerv.

I understand that they call me, right?. Where do they get the number from? whois? Surely not these days. So it is user/requestor supplied and totally untrusted.

It is about e.g. webserver SSL certs. So it surely is about domain control.

ad 2) The addresses they list are examples. It is "such as" and not "one from this list" (and even that would be bad habit and untrustworthy).

IMHO it is an abuse by Equifax to apply for inclusion as a CA and then allow other companies with different and untrustworthy procedures, that are different from the ones tested at the time of the inclusion, to have CSRs signed with this Issuer. Even more als RapidSSL is or at least pretends to be another company and another CA. By no way they mention they use the Equifax CA. To find out you have to download and look at "their" CER.

"CA resellers" should be removed altogether.
Markus: if Eddy is correct, then the number is user-supplied. What I am saying is that the purpose of the phone number business does _not_ seem to be to establish domain control. So it's entirely irrelevant in determining whether they have met the policy requirement to establish domain control. The only thing we need to consider is their email verification procedure.

I agree that we need to get a complete list of the email addresses they accept.

Your more general point about CA resellers is independent of this bug, and you should take that to the newsgroup.

Gerv
The issues in relation to RAs, resellers and independent Sub CAs is something which Mozilla needs to clarify soon anyway. See also https://wiki.mozilla.org/CA:Problematic_Practices .

The newsgroup Gerv referred to is mozilla.dev.tech.crypto and soon also at mozilla.dev.security.policy. Markus, I suggest that to join us there.
Gerv: If a totally stranger can setup and *verify* (with a totally untrusted and unrelated phone number) a CSR for domain control this is broken. This is where the verification process fails in the first place.

If all that stands between a wrongly assigned and *trusted* CERT is a list of email addresses this is even more broken.

If I am keymaster@gmail.com or sslmaster@gmail.com and that is an accepted address, how would Google know? Fine, so I get a Cert from Equifax for gmail.com. Totally automated.

Do you expect domain owners to keep track of all CAs and CA reseller policies and their accepted email lists, just to block each and every email address on those lists to prevent someone from stealing a "legit" cert for their domain?
Come on.

The whole process is highly untrusted. Fact.
Including the CER of Equifax thus poses high security risks for the users. So either they stop signing RapidSSL CSRs or Mozilla has to get rid of Equifax.

And I don't think this more general point is independent of this bug. The general point is a security violation by the Issuers and has to be taken care of, otherwise it poses a security violation in Mozilla products.

If you think this should get broader audience, no problem. Please tell me what newsgroup you think would be the right one to post to. Thanks (really).

\Maex
(In reply to comment #6)
> Gerv: If a totally stranger can setup and *verify* (with a totally untrusted
> and unrelated phone number) a CSR for domain control this is broken. This is
> where the verification process fails in the first place.

Right. Listen to me again: as far as I can tell, the business with the phone number, the first part of the procedure, is not about verifying domain control. So please forget the phone number stuff. It's irrelevant. If they asked you to paint your house green as a condition of getting a certificate, it would be invalid to argue "that's stupid! painting my house green doesn't establish domain control!". Exactly the same here. 

> If all that stands between a wrongly assigned and *trusted* CERT is a list of
> email addresses this is even more broken.

Now _that_ is the important question. For better or for worse, the standard method of domain control validation is by emailing an address at a domain. What we have to establish is whether they are doing it in a more dangerous manner than everyone else.

You need to read what I'm saying carefully. I am not arguing that you don't have a case. I am trying to make it very clear what the issue is.

> If you think this should get broader audience, no problem. Please tell me what
> newsgroup you think would be the right one to post to. Thanks (really).

The general point should be taken to mozilla.dev.security.policy. The specific point remains here.

Gerv
Gerv: sorry to be pedantic.

I read carefully what you say and I am not thinking that you think I have no case, btw. I think we only disagree about the meaning/intention behind that phone thingy. IMHO they use it to verify domain control. You say they don't :-)

Someone sends them a CSR for example.com and a phone number. If the PIN displayed on the phone number is entered correctly they assume you met the condition of domain control over example.com and are eligible to have your CSR signed by them (why should they otherwise accept (and sign) the CSR).

If you don't agree with that then what should this phone thing be good for otherwise? I could always tell them some broken number, claim problems and then call them and sort it out with them directly (see their page: "If you still have problems, please contact 866.795.4669 (US only) or +44 203 0240906 and we will assist you in completing the process manually.)

The email part is only about sending out the access code/link to get the already signed cert based on the already accepted domain control. Requesting that the email address is within the domain is to trick people into thinking that this is a kind of validation procedure, which it clearly is not, regardless what they request the email address to be.

Please note, there is no step 3. You click the link in the email and you get the cert.

If the validation of domain control would take place at the point where/before they accept the CSR (as it should) the mail part would be totally irrelevant, as an attacker would - e.g. by intercepting the email (DNS poisioning, weak IMAP/POP3 passwords, ...) - never have the secret key to the CSR and the signed certificate, so it would be worthless.
Then they won't even need the requirement to have an address within the domain.

But: they allow the attacker to create his own secret key, use it for his own CSR and have it signed. With the approval email intercepted this is an easy and straight forward attack vector.

And ... maybe it is a language barrier, but I really don't understand your example about the green house.
(In reply to comment #8)
> Someone sends them a CSR for example.com and a phone number. If the PIN
> displayed on the phone number is entered correctly they assume you met the
> condition of domain control over example.com and are eligible to have your CSR
> signed by them (why should they otherwise accept (and sign) the CSR).

No. They only sign it when you complete both bits - the phone bit and the email-domain-control bit.

> If you don't agree with that then what should this phone thing be good for
> otherwise?

Because they want to have a record of a valid phone number for you. That may be for their own business reasons, or because they think it provides some measure of traceability. (They'd be wrong about that, but they may think it.)

> The email part is only about sending out the access code/link to get the
> already signed cert based on the already accepted domain control. Requesting
> that the email address is within the domain is to trick people into thinking
> that this is a kind of validation procedure, which it clearly is not,
> regardless what they request the email address to be.

It is a validation procedure. The idea is (and whether it works is what we are discussing) that if you don't have control of the domain, you won't be able to get the email.

> Please note, there is no step 3. You click the link in the email and you get
> the cert.

Right. And if you don't get the email sent to the domain, you won't be able to get the cert.

> But: they allow the attacker to create his own secret key, use it for his own
> CSR and have it signed. With the approval email intercepted this is an easy and
> straight forward attack vector.

"The email might be intercepted" is a different complaint to "the email might be sent to an email address at the domain not controlled by the admin." Which is your complaint? Both?

"The email might be intercepted" is, again, for better or worse, a flaw in almost every currently-used method of domain control validation for DV certificates. This is not a problem particular to RapidSSL.

> And ... maybe it is a language barrier, but I really don't understand your
> example about the green house.

Don't worry about it :-)

Gerv
Gerv, a server certificate should be only issued after domain control is confirmed. I think what Markus is trying to say is that the phone bit is done in order to sign the certificate, the email address is used to send the certificate, ergo the certificate is already signed. Apparently it can be almost any email address within the domain. This isn't sufficient to confirm domain control.

Upon such a complaint I suggest that Mozilla immediately performs a few tests and gets a few certificates from the CA in question, except in case Mozilla already knows the answer and deems re-testing unnecessary. That's due diligence on part of Mozilla.
(In reply to comment #9)
> a flaw in
> almost every currently-used method of domain control validation for DV
> certificates. This is not a problem particular to RapidSSL.

I did some "research" and worked my way through the websites of a few SSL providers and CAs. I had to notice that none of them provided detailed and indepth (in fact not even basic) information about the rollout and identification/authorization process. GeoTrust (which almost all others seem to be resellers of) alone for their EV certs has a list of requirements they "must be able to check". In no way they write that they approve and guarantee they have really done the check. And this seems to be the best you can get currently.

I haven't bought certificates for some time now, but the days where you had to provide official (governmental) documents to establish the identity of your business/domain and verify domain ownership and all had to be consistent seem to be gone. To me it looks like CA business has turned in to a **** "make money fast" system without any reasonable checks. RapidSSL even seems to not be one of the worst of them. At least they kinda publicly document what they do. And then the "bug" is not really with RapidSSL, but with the entity behind the Equifax CA for not monitoring the validation procedures of their resellers, but signing the CSRs nevertheless.

I have learned that SSL isn't worth anything currently wrg identity and trust (except for my own private CA of course :-)
Even the SSL Cert for this website is from Equifax (the same CA that RapidSSL uses, too)

Talking about "reasonable measures" in Mozilla CA Certificate Policy (Version 1.2) without exactly defining them in detail is IMHO blurry and not really a useful method to establish trust.

From today on I will see any "trust icons" in every browser gui with totally different eyes and work through all dialogs about unsecure Certs with an ironic smile on my face.

If you feel that sounds kinda embittered you may be right.

We should probably forget about this bug report. Feel free to close it.

Oh and please don't get me wrong - I am far from blaming you for anything in this context. I only got some of my outdated idealistic views destroyed today. My enthusiasm for making Mozilla products more secure by getting rid of a untrustworthy CA turned out to result IMHO in a all or none of them "solution", so let's stick to "none of them".
(In reply to comment #10)
> Gerv, a server certificate should be only issued after domain control is
> confirmed. I think what Markus is trying to say is that the phone bit is done
> in order to sign the certificate, the email address is used to send the
> certificate, ergo the certificate is already signed.

That seems to me to be making a statement about RapidSSL's internal workflow that he has no evidence for. The procedure does not require this sort of implementation. It may well be that the certificate is signed on the fly when the URL in the email is accessed.

And even if they did sign it beforehand and store it on their servers, why is that worse? You still can't get it without receiving the email.

> Apparently it can be
> almost any email address within the domain. This isn't sufficient to confirm
> domain control.

From where do you get your "apparently"? I've emailed Verisign to find out what the actual situation is. Why not wait for facts rather than speculate?

Gerv
(In reply to comment #11)
> I did some "research" and worked my way through the websites of a few SSL
> providers and CAs. I had to notice that none of them provided detailed and
> indepth (in fact not even basic) information about the rollout and
> identification/authorization process. 

What did you expect? "Here are all the checks we do so you can figure out how to circumvent them"? Eddy, you don't provide documentation on all the checks you do, do you?

> GeoTrust (which almost all others seem to
> be resellers of) alone for their EV certs has a list of requirements they "must
> be able to check". In no way they write that they approve and guarantee they
> have really done the check. 

Apart from the fact that they are audited to make sure they do so, and if they didn't and we found out, we'd revoke their EV status, which would destroy their business. 

> I haven't bought certificates for some time now, but the days where you had to
> provide official (governmental) documents to establish the identity of your
> business/domain and verify domain ownership and all had to be consistent seem
> to be gone. 

I think you'll find that for an EV certificate, you have to do at least that.

> one of the worst of them. At least they kinda publicly document what they do.
> And then the "bug" is not really with RapidSSL, but with the entity behind the
> Equifax CA for not monitoring the validation procedures of their resellers, but
> signing the CSRs nevertheless.

What makes you think RapidSSL is a reseller for Equifax?

In fact, the Equifax root is owned by Verisign/GeoTrust, and RapidSSL is directly owned by them (as their legal page tells you).

> Talking about "reasonable measures" in Mozilla CA Certificate Policy (Version
> 1.2) without exactly defining them in detail is IMHO blurry and not really a
> useful method to establish trust.

The CA Certificate Policy is not (directly) a trust-establishing mechanism. Being prescriptive about measures would, among other things, completely break innovation, because no-one could do things a better way. You are looking to that document to provide a function it is not meant to provide.

Gerv
(In reply to comment #12)
> It may well be that the certificate is signed on the fly when
> the URL in the email is accessed.

Now I am really impressed.
Having the key of the Root online in a way that allows for automatic on-the-fly signing through a web interface.
(In reply to comment #14)
> Now I am really impressed.
> Having the key of the Root online in a way that allows for automatic on-the-fly
> signing through a web interface.

Markus: with respect, it would help if you were a little more informed about how the CA business works technically before commenting on it.

The root signs an intermediate certificate, and that certificate is what will be on the signing servers. The root will not be online.

It may well also be that there is network isolation between those servers and the web servers, with data being passed over e.g. a serial cable. That would be best practice. One would hope that's true, but of course we have no easy way of knowing. Although it may be detailed in the audit reports.

But you can't go throwing accusations around without proof. That works against any valid points you may have.

Gerv
(In reply to comment #15)
> (In reply to comment #14)
> > Now I am really impressed.
> > Having the key of the Root online in a way that allows for automatic on-the-fly
> > signing through a web interface.
> 
> The root signs an intermediate certificate, and that certificate is what will
> be on the signing servers. The root will not be online.

Gerv, you've been a bit naive here :-)

It's also well known that RapidSSL/Verisign signs directly from a root, at least that's what they openly advertise and promote. A search for this CA resulted in this:

"Get fast low-cost single-root SSL certificates" and more on their FAQ at http://www.rapidssl.com/ssl-certificate-support/ssl-faq.htm#8 :

My highlight: "Installation of chained root certificates are more complex and some web servers and applications are not compatible with chained root certificates."

My advice? Have a very good look what's going on, don't ask them but verify by yourself!
Really? OK, that does suck. It's on the Problematic Practices page, right?

Do you know of any web servers or applications which are "not compatible with chained root certificates"?

Gerv
(In reply to comment #17)
> Really? OK, that does suck.

Yes :-)

> Do you know of any web servers or applications which are "not compatible with
> chained root certificates"?

All major web servers  do covering 99% of all use cases. For the ones which don't it's usually sufficient to install the issuing, intermediate CA certificate at the server provided its issuer is the root which is included in the software (e.g. NSS).
Here is RapidSSL's list of supported email address prefixes, as supplied by them:

admin
administrator
hostmaster
root
ssladmin
sysadmin
webmaster
info
is
it
mis
ssladministrator
sslwebmaster
postmaster

Gerv
It would be better to use a set of accounts as RC 2142 suggests. This list seems to me too generous in order to clearly establish domain control. Potentially limit to:

hostmaster
postmaster
webmaster

and maybe optionally

root   (Unix,Linux)
administrator   (Windows)
abuse   (is a required mail account)

The others from the list above are in my opinion not protected enough. Offering more options highers the risk. To all of my knowledge there are no negative effects on usability by subscribers if the list is limited to the well known administrative accounts as shown above. I suggest that Verisign reconsiders their current implementation.
(In reply to comment #20)
> It would be better to use a set of accounts as RC 2142 suggests.

That's RFC 2142 of course.
I agree that it would be good for CAs to come to agreement on a limited set of addresses to be used. (If there's agreement, then a) we can require it, and b) no-one can "innovate" and be "more convenient" by dangerously expanding the list of addresses.) We are currently discussing this in the CAB Forum, and CAs are submitting data for what addresses are most used in their systems.

One tweak is that any address listed in whois should automatically be permitted. I think that's fine.

Gerv
(In reply to comment #22)
> One tweak is that any address listed in whois should automatically be
> permitted. I think that's fine.

Yes, I'm comfortable with this. Perhaps we can add it already now to the problematic practices since not all CAs are members of and committed to the decisions of the CA/Browser forum.
Give me a couple of weeks to get consensus on a list :-)

Gerv
Depends on: 556468
Also see bug 556468...
(In reply to comment #24)
> Give me a couple of weeks to get consensus on a list :-)

A year has passed :-)
In regards to Comment #19, this list was discussed during the root inclusion process for bug #484899. As a result, as of 3/3/2010 GeoTrust removed the following email addresses from their list of options for domain validated certs: is, it, mis, ssladministrator, sslwebmaster. 

I have also added a section about this to the Potentially Problematic Practices wiki page:
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs

Please let me know if you have recommendations for improving this new section of the wiki page.
I believe this bug may now be closed, as per Comment #27 and also the Mozilla policy has been updated in this regards.

http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
8. When the CA uses an email challenge-response mechanism to validate that the certificate subscriber has control of the requested domain, the CA must either use a mail system address from the technical or administrative contact information in the domain's WHOIS record, or one formed by prefacing the registered domain with one of the following local parts: admin, administrator, webmaster, hostmaster, or postmaster.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.