Closed Bug 1461391 Opened Last year Closed 8 months ago

Comodo: Misissuance using "CNAME CSR Hash 2" method of domain control validation

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: agwa-bugs, Assigned: Robin.Alden)

Details

(Keywords: sec-other, Whiteboard: [ca-compliance])

Attachments

(1 file)

4.30 KB, application/x-x509-ca-cert
Details
Attached file dcv.party.crt
I just reported the following to sslabuse@comodoca.com:

I was able to obtain a certificate from Comodo that was not properly
validated under the Baseline Requirements, as follows:

1. Visit https://www.positivessl.com/ and click "Try Now" under "Free
SSL Certificate".

2. Provide a CSR for the FQDN dcv.party.

3. On the next page, select "CNAME CSR Hash 2" as the method of Domain
Control Validation.

4. Publish the following DNS record:

ae104fe977c36b235260d331c949b8ca.dcv.party. CNAME 7b4c2cd1009045dc12d3e8b0c3d02912.406b5877e3a9f1eda4b7d8253ac1eb18.comodoca.com.

5. Complete the form and submit the order.

6. Receive a valid certificate for dcv.party and www.dcv.party (attached).

Section 3.2.2.4.7 ("DNS Change") of the BRs says:

"Confirming the Applicant's control over the FQDN by confirming the
presence of a Random Value or Request Token for either in a DNS CNAME,
TXT or CAA record for either 1) an Authorization Domain Name; or 2)
an Authorization Domain Name that is prefixed with a label that begins
with an underscore character."

Since ae104fe977c36b235260d331c949b8ca.dcv.party is not an Authorization
Domain Name for (www.)dcv.party, nor is it an Authorization Domain Name
that is prefixed with a label that begins with an underscore character,
this certificate was not properly validated.
Assignee: wthayer → Rob.Stradling
Whiteboard: [ca-compliance]
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Incident report:

1) How Comodo CA first became aware of the problem
We were informed by an email from Andrew Ayer to our abuse email address sslabuse@comodoca.com at 18:50 BST (UTC + 1) on Monday 14th May.

2) A timeline of the actions Comodo CA took in response. 

2017 July 11 - We introduced our new implementations of DCV methods designed to meet the requirements of the CA/B Forums BR's version 1.4.1 section 3.2.2.4, as required by Mozilla.
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a05o000003WrzBC
(See Action #1 in that link)

2017 July 13 - We reviewed version 1.4.1 of the BRs along with the then in-process ballots in the CA/B Forum.
We determined that the underscore at the start of the CNAME LValue in 3.2.2.4.7 was optional.  This now appears to have been a mistake.

2017 July 20 - We withdrew our old DCV methods that consciously relied on the 'Any Other Method'. 

2017 July 20 - In response to complaints from some EU operators who found that their DNS web portals would not let them specify a leading underscore in a CNAME LValue, we introduced a new DCV variant that permitted the underscore to be omitted.

2018 May 14 - Initial problem report received from Andrew Ayer.

2018 May 15 – Code changes prepared to remove the option for the leading underscore to be omitted from the CNAME LValue in 3.2.2.4.7 domain validation.
QA begins.

2018 May 18 17:20 (UTC+1) – QA completed.  Code released to live.  No further domains will be validated using the flawed method.

3) A summary of the problematic certificates. 
A total of 11099 TLS/SSL certificates were issued that used the variant of 3.2.2.4.7 that omitted the leading underscore.
The earliest such certificate was issued on 2017 July 20.
10993 of those TLS/SSL certificates remain unexpired and unrevoked.

4) The complete certificate data for the problematic certificates. 
This is a list of all of the unexpired certificates:
https://docs.google.com/spreadsheets/d/1ZW-YdrjeoUsMpTY0CW3f2D59Bl188K398oda7qTUM1Q/edit?usp=sharing

5) How and why we came to issue these certificates
When implemented code to remove our reliance on the old 'Any other method' domain validation section 3.2.2.4.11 in May, June, and July 2017, the then-current version of the BRs did not actually contain any of the new DCV methods.  Mozilla had requested compliance with 3.2.2.4 from version 1.4.1 which was issued in September 2016.  That version including the 'blessed' methods - albeit somewhat out of date.
In 2017 July we misinterpreted the words 
"for an Authorization Domain Name 
  or an Authorization Domain Name that is prefixed with a label that begins with an underscore character" to mean
"for an Authorization Domain Name prefixed with a label 
  or an Authorization Domain Name that is prefixed with a label that begins with an underscore character".
With hindsight we agree that this interpretation of the BRs was incorrect.

We added the variant of 3.2.2.4.7 without the underscore in response to customer requests and mistakenly believed it to be a permitted variation when we implemented it.

Our implementation of 3.2.2.4.7 (with or without underscore) has always required that a request-specific label is prefixed to the Authorization Domain Name as part of the Request Token.
Our syntax for constructing the CNAME to pass validation is documented in
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf, but in brief is this:
"When using DNS CNAME based DCV, the Request Token should appear as successive labels in the CNAME RDATA (i.e. the right hand side of the DNS CNAME definition).
The format is always of the form:
‘_’ <MD5 hash>.<Authorization Domain Name> CNAME <SHA-256 hash>.[<uniqueValue>.]comodoca.com."
The 'hashes' there, both MD5 and SHA-256, are of the PKCS#10 certificate request.

The variant without the underscore differed only in the omission of the initial underscore.
While this was not strictly compliant with the BRs, certificates issued using this method do not pose an urgent security concern as the DCV method used provides as high a degree of certainty that the applicant controlled the certified domain as it would have done had the underscore been included.

6) Why we didn't spot it until now.
One of the individuals involved in originally misinterpreting this portion of the BRs in Q2 and Q3 2017 was also responsible for our 2018 BR compliance review and repeated the original interpretation.

7) Resolution steps

2018 May 18 17:20 (UTC+1)  – Code released to live.
 We have removed the implementation variant of the DCV check under 3.2.2.4.7 that permitted the underscore to be omitted.

Some of our websites and documentation still present the "CNAME CSR Hash 2" validation method – but this cannot now lead to validation of the domain unless the underscore is present.
We will remove all mentions of "CNAME CSR Hash 2" from our public facing systems over the next few days.

Within the next 30 days we will have different Comodo CA staff perform a fresh BR compliance review to help ensure that no other misunderstandings of the BRs persist.

We are grateful to Andrew Ayer for the problem report.

Regards

Robin Alden
CTO for SSL
ComodoCA.com
Thanks, Robin.

Wayne: could you lift the security restriction since the issue is resolved now?
Dan: will you please remove the security-sensitive flag from this bug?
Flags: needinfo?(dveditz)
Group: crypto-core-security
Flags: needinfo?(dveditz)
Robin: please update this bug with your findings when the compliance review mentioned in comment #1 has been completed.
Flags: needinfo?(robin)
Robin: any update here?
Assignee: Rob.Stradling → Robin.Alden
Robin: the lack of timely response here is concerning. Please answer the question posed in comment #4.
from comment #1
> Within the next 30 days we will have different Comodo CA staff perform a
> fresh BR compliance review to help ensure that no other misunderstandings of
> the BRs persist.
> 

(In reply to Wayne Thayer [:wayne] from comment #4)
> Robin: please update this bug with your findings when the compliance review
> mentioned in comment #1 has been completed.

First, I apologize for the extremely slow response. 

By 15th June 2018 we had completed a fresh review of our Domain Control Validation implementation against version 1.5.8 of the BRs and found it to be compliant.
Flags: needinfo?(Robin.Alden)
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.