1428877 - SwissSign: Invalid DNSName in SAN

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Reinhard Dietrich reported the following certificate containing an invalid SAN entry to the mozilla.dev.security.policy forum: https://crt.sh/?id=295437114&opt=cablint

Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Reinhard Dietrich]

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We became aware due to our cablint checker which checks automatically all issued SSL certificates again after issuance. Due to the weekend, the problem was analyzed in detail on Monday morning, January the 7th.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

Jan. 7th. 8.28am : information of the customer and certificate owner.
Jan. 7th 12.58am: certificate revoked by certificate owner

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

We check in the moment the reports of our cablint checker if there are other certificates issued with this problem. The problem itself could be identified in the software (insufficient regex check) and will be solved in our next release, Jan. 13th, 2018. 

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

The following certificates are affected by this problem:: 
- https://crt.sh/?id=295437114&opt=cablint 
- https://crt.sh/?id=254676135
- https://crt.sh/?id=267225756

The applicant revoked all three certificates since it was clear that the certificate did not work with the mismatched SAN. Our internal cablint checker gives only a report on valid certificates.. We will in future keep also an eye on revoked certificates.

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

- https://crt.sh/?id=295437114&opt=cablint. 
- https://crt.sh/?id=254676135&opt=cablint
- https://crt.sh/?id=267225756&opt=cablint

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

As announced in earlier reports, we implemented the International Guidelines for the implementation of IDNs (2008) and forbid by this the use of Unicode domain names. The implementation took place in November 2019 release. These examples give now evidence that the regex treatment for checking the correctness of FQDN names was insufficient in some cases. A repair of this functionality is now in test and will be released Saturday this week 01/13/2018). Until then we will have an eye on all issued SSL certificates. 

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

in near Future we will apply a SW-fix that solves this error.

Comment 2

[Ryan Sleevi]

The previous bug regarding SwissSign's handling of DNS names is Bug 1391066.

The level of detail provided in the past merely indicated that issues with inconsistency were resolved (c.f. https://bugzilla.mozilla.org/show_bug.cgi?id=1391066#c22 and additional test cases https://bugzilla.mozilla.org/show_bug.cgi?id=1391066#c20 )

At the time of this incident, there was active discussion in the mozilla.dev.security.policy mailing list regarding invalid DNS names, as summarized at https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/ek2CJD1KCQAJ , and for which other CAs were affected by such issues. Similarly, this was following the April 2017 CA communications ( https://wiki.mozilla.org/CA/Communications#April_2017 ) which required CAs to follow discussions around mozilla.dev.security.policy.

In those discussions, a number of CAs were admonished for not ensuring RFC1034 compliance for their domains.

Given this, I'm hoping SwissSign can share additional details about both the root cause and their proposed mitigations:

1) What was your existing regular expression?
2) What is your analysis of why it failed to be sufficient.
3) What is your proposed new regular expression?
4) What test cases have you developed to test both positive/valid and negative/invalid domains?
5) What is your precise timeline for these changes, as proposed.
6) Did you follow the discussions of other CA's non-compliance of domain names, particularly given the past issue of non-compliance within SwissSign's domain names representations?
7) What analysis did you perform at the time to determine if SwissSign was affected by the same issues as other CAs?
8) What is your timeline to linting your entire issued certificate database, regardless of validity status?

Comment 3

[Firefox Bug Husbandry Bot]

Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254

Comment 4

[Reinhard Dietrich]

Question 1) What was your existing regular expression?

Answer to Q1:
The previous code checked that there was an appropriate domain at the end of the domain name, but did not check that any earlier labels were well formed.  This was the root of the problem.

Question 2) What is your analysis of why it failed to be sufficient.
Answer to Q2:
The previous code was insufficient in that it simply failed to make some necessary checks.  We believe that the current code makes all the checks necessary to ensure the validity of the domain name.


Question 3) What is your proposed new regular expression?
Answer to Q3:
The new code, implemented in the 4.10 release, performs the following additional check:
- the domain name is split into labels
- for each label
  - if the label is a single character it must match the RE ^[0-9A-Za-z]$
  - if the label is between one and 63 characters it must match the RE ^[0-9A-Za-z][0-9A-Za-z-]*[0-9A-Za-z]$
  - otherwise the check fails
 
This could be made into a single regular expression but we have chosen not to implement it as such.
 
Question 4) What test cases have you developed to test both positive/valid and negative/invalid domains?
Answer to Q4:

Our test suite includes the following tests:
Positive cases:
- test-swisssign.com
- swisssign1.com
- mandatoryswisssign1.com
- empty.basic.caatestsuite.com
- www.neely.cx
- neely.cx
- test-neely.cx
- aa.com
- A-A.com
- co.uk
- domain.com
- a.domain.co
- foo--bar.com
- xn--froschgrn-x9a.com
- rebecca.blackfriday
 
Negative cases:
- www,swisssigntestform.ch
- swisssigntestform.ch;www.swisssigntestform.ch
- 1#swisssigntestform.ch
- ?swisssigntestform.ch
- .swisssigntestform.ch
- swisssigntestform..ch
- www.neely.cx...
- www.neely.lkj
- 216.17.184.1
- test_neely.cx
- .neely.cx
- -www.neely.cx
- abc
- 256.0.0.0
- _.com
- *.some.com
- s!ome.com
- domain.com/
- /more.com
- a
- .
- com.
- com
- net
- uk
- neely
- swisssigntestform.ch,www.swisssigntestform.ch
- https://www.swisssigntestform.ch
- http://swisssigntestform.ch
- swisssigntestform.ch/index.html

Question 5) What is your precise timeline for these changes, as proposed.
Answer to Q5:
These changes went live on 13th January 2018. From that time forward, according to CABlint, there have been no further problems

Question 6) Did you follow the discussions of other CA's non-compliance of domain names, particularly given the past issue of non-compliance within SwissSign's domain names representations?
Answer to Q6:
Yes, we have followed the previous discussions and will continue to do so.  We also make sure that the appropriate information is made available to our development team.

Question 7) What analysis did you perform at the time to determine if SwissSign was  affected by the same issues as other CAs?
Answer to Q7:
We manually checked that we were not affected by the problems described, and we added appropriate tests to our test suite to ensure we would never have such problems.

Questions 8) What is your timeline to linting your entire issued certificate database, regardless of validity status?
Answer to Q7:
We have developed software to check the validity of the domain names in all SwissSign issued certificates.  This will be run within the next month and the results will be analysed.  We will take any appropriate action based on those results.

Comment 5

[Ryan Sleevi]

(In reply to Reinhard Dietrich from comment #4)
> Question 3) What is your proposed new regular expression?
> Answer to Q3:
> The new code, implemented in the 4.10 release, performs the following
> additional check:
> - the domain name is split into labels
> - for each label
>   - if the label is a single character it must match the RE ^[0-9A-Za-z]$
>   - if the label is between one and 63 characters it must match the RE
> ^[0-9A-Za-z][0-9A-Za-z-]*[0-9A-Za-z]$
>   - otherwise the check fails
>  
> This could be made into a single regular expression but we have chosen not
> to implement it as such.

Note: This still allows potentially-invalid labels through, particularly those of the R-LDH subset defined as part of IDNA. See the discussion in https://tools.ietf.org/html/rfc5890#section-2.3.1 for the terminology, but if the third-and-fourth character contain hyphens, it's a tagged domain name / R-LDH and should be validated to the syntax of that tag (e.g. xn-- being permissable for IDNA)

You can see this in your positive case for the xn-- encoded labels. Given that other tagged-labels may have semantic meaning not understood by the CA, it would seem you should blacklist any tagged label for which you're not validating, or semantics of new forms of tags being introduced for which your CA is not complying with. It would be better to whitelist (e.g. permit xn--, blacklist all other R-LDHs) to ensure no future issues.

Note: It would be good to consider covering the label separators called out in https://tools.ietf.org/html/rfc3490#section-3.1 if you allow users to provide U-Labels as part of the validation entry.

Comment 6

[Wayne Thayer]

Reinhard:
- please state if you have, or are planning to take any additional actions based on comment #5.
- please confirm that the lint run of the entire certificate database described in question #4 has been completed and share the results of your analysis.

Comment 7

[Reinhard Dietrich]

Feedback to comment #5
Thank you for your analysis and detailed reply.You are, indeed, correct that the additional tests we have implemented are still weak in the area you have identified.
We will extend the checks from question three to ensure that if the label is an R-LDH label it must also be an XN-label, as you suggest.  We will further check that no labels are fake A-labels. In addition we will add appropriate tests to those mentioned in the answer to question four.
With regards to the label separators you mention, we are already compatible with RFC 3490 which you cite.

Thank you again for your helpful analysis.

Feedback to question#4
We confirm that the lint run of the entire public trusted SSL-certificate database has been completed. 

We found no issues in certificates intended to be used for authenticating servers accessible through the Internet.

Comment 8

[Wayne Thayer]

(In reply to Reinhard Dietrich from comment #7)
> Feedback to comment #5
> We will extend the checks from question three to ensure that if the label is
> an R-LDH label it must also be an XN-label, as you suggest.  We will further
> check that no labels are fake A-labels. In addition we will add appropriate
> tests to those mentioned in the answer to question four.

Reinhard: please update this bug when these improvements have been completed.

Comment 9

[Reinhard Dietrich]

yes, we will update as soon as These improvements have been completed

Comment 10

[Wayne Thayer]

Michael: please provide an update.

Comment 11

[Mike Guenther]

Sorry for the late reply. After talking to all involved parties I can confirm that all points discussed in this thread are implemented (as Reinhard already posted) with one exception. The fix discussed in comment 7 by Reinhard is working in our staging area and is part of the next release. I will make a final update of this ticket as soon as the release is in production.

Comment 12

[Wayne Thayer]

Mike: any update on this?

Comment 13

[Mike Guenther]

Wayne: Just verified with the release manager. He confirmed that the fix is part of the next release. The release is planned for the weekend of January 12. Should any unexpected problems arise the release would be moved to January 19. I'll update the ticket after go-live.

Comment 14

[Mike Guenther]

As planned the release was implemented on Saturday and the additional code as described in comment 5 is now life. Therefore I ask that the status is changed to resolved.