Closed Bug 1169149 Opened 6 years ago Closed 5 years ago

golang.org reports sec_error_bad_der error

Categories

(Core :: Security: PSM, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox38 --- wontfix
firefox38.0.5 --- wontfix
firefox39 --- wontfix
firefox40 --- wontfix
firefox41 --- wontfix
firefox-esr31 --- unaffected
firefox-esr38 --- wontfix

People

(Reporter: xidorn, Assigned: keeler)

References

(Depends on 1 open bug, )

Details

Attachments

(3 files)

Go to https://golang.org/ it shows:

Secure Connection Failed

An error occurred during a connection to golang.org. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)
Attached file golang.org.pem
Looks like the certificate being served includes a subject alternative name entry for '*.google'. Currently mozilla::pkix requires at least two labels after a wildcard in SAN entries.
As agl__ (Google) mentions on Twitter, the certificate has been rolled back and the affected Google sites are accessible again using Firefox.

He also points out this is a valid bug report and Firefox should handle wildcard names on private gTLDs just like wildcard domains; referring to section 3.2.2.6 in https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf
In the short term, the check for the number of components after the "*" should be removed from the parsing of names so that "*.google" parses correctly. The part of the code that *matches* names needs to do that check instead.

In the long term, there needs to be a smarter mechanism for determining which eTLDs allow wildcards and which don't. That should be a separate bug.
This change happened in 36, so ESR31 shouldn't be affected.
1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing
Attachment #8613755 - Flags: review?(cykesiopka.bmo)
QA Contact: dkeeler
Assignee: nobody → dkeeler
QA Contact: dkeeler
(In reply to David Keeler [:keeler] (use needinfo?) from comment #6)
> Created attachment 8613755 [details]
> MozReview Request: 1169149 - enforce wildcard presented DNS ID minimum label
> count when matching, not parsing
> 
> 1169149 - enforce wildcard presented DNS ID minimum label count when
> matching, not parsing

Just as a heads up, I probably won't get to reviewing this until the end of this week at the earliest. I am completely unfamiliar with the code involved, so I will have to take some time to stare at the existing code.
Attachment #8613755 - Flags: review?(cykesiopka.bmo) → review+
Comment on attachment 8613755 [details]
MozReview Request: bug 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka

https://reviewboard.mozilla.org/r/9785/#review9143

LGTM, but I wouldn't be surprised if I missed something. Let's see what comments Brian has.

Minor nit: the word "Bug" is missing at the front of the commit message.

::: security/pkix/lib/pkixnames.cpp:1166
(Diff revision 1)
>      if (LocaleInsensitveToLower(presentedByte) !=

Completely optional, but it would be nice to correct the LocaleInsensitveToLower() function name typo.

::: security/pkix/test/gtest/pkixnames_tests.cpp:486
(Diff revision 1)
> -  I("*.a", false, false),
> +  // The restriction that the wildcard have enough labels is enforced when

"the wildcard have enough labels" reads a bit weird to me - s/wildcard/wildcard presented name/ maybe?

::: security/pkix/test/gtest/pkixnames_tests.cpp:1535
(Diff revision 1)
> +  // A wildcard without at least 3 labels is not considered a match.

Same as above.
Comment on attachment 8613755 [details]
MozReview Request: bug 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka

1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka
Attachment #8613755 - Attachment description: MozReview Request: 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing → MozReview Request: 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka
Attachment #8613755 - Flags: review?(brian)
Attachment #8613755 - Flags: review+
Comment on attachment 8613755 [details]
MozReview Request: bug 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka

bug 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka
Attachment #8613755 - Attachment description: MozReview Request: 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka → MozReview Request: bug 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka
Thanks for the review.

Brian - I don't know if you saw the original review request (since it was in mozreview as opposed to splinter). If you have time to take a look, that would be great. Otherwise, I'll move forward with this sometime next week.
Flags: needinfo?(brian)
firefox 38.1ESR, firefox 37
Go to https://telew4f.bull.fr/W4Public/ it shows also:

Secure Connection Failed

An error occurred during a connection to golang.org. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)

The main difference with golang.org is the format of the generic name in the SAN: 
DNS: tele*.bull.net, DNS:teleportail.bull.fr, DNS:telescript.bull.fr

with firefox 39 (windows), I got a security alert and I have to add an exception
With firefox before 37 all is correct (no SSL error nor security alert)
(In reply to jean-etienne.schwartz from comment #12)
> The main difference with golang.org is the format of the generic name in the
> SAN: 
> DNS: tele*.bull.net, DNS:teleportail.bull.fr, DNS:telescript.bull.fr
> 

This is working as intended. Wildcards in anywhere but the leftmost label are explicitly rejected by Firefox and Chrome, and implicitly rejected by IE. Discouraged by RFC6125 and forbidden by the CA/Browser Forum Baseline Requirements.
David, I think there should be a broader discussion of what to do about *.tld wildcards. Adding support for wildcards like *.google seems like it would put a huge burden on implementations to track the public suffix list. I don't think that mozilla::pkix's behavior is the best, because it shouldn't allow *.co.uk. Maybe we need to use a subset of the PSL to improve that. But, I'd like to keep the subset of the PSL, and the frequency with which an implementation would need to sync it, to a minimum. So, my current thinking is that we should require two domain components after any country-code TLD. Then an implementation would only need to keep track of country code TLDs, the set of which very rarely expands.

Also, keep in mind that almost nobody can afford ~US$200,000 to buy a domain name like *.tld. If they can afford to spend $200,000 on a TLD then they can also probably afford to find a way to make sure there are two components in before the * in every wildcard name.
Flags: needinfo?(brian)
Comment on attachment 8613755 [details]
MozReview Request: bug 1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing r=Cykesiopka

Clearing review. I think it is better for Mozilla to continue to discourage *.tld wildcards until there is a clear consensus as to how to deal with them. Until then, the current behavior is better than the proposed behavior.

Note that there is already another bug on file, bug 1196364, about rejecting things like *.co.uk: .
Attachment #8613755 - Flags: review?(brian) → feedback-
With FF 44.0.2, I am getting error "sec_error_bad_der" when trying to use https://www.portokalkulator.de/ ,
which is a legitimate page from Deutsche Post for calculating mailing costs (i.e. the required stamps).

This is the full error text as displayed (German):
----
Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit www.portokalkulator.de aufgetreten. Sicherheitsbibliothek: Fehlerhaft formatierte DER-verschlüsselte Nachricht. (Fehlercode: sec_error_bad_der)

    Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
    Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.
----

I do not see a way to get at the certificate in question, the built-in network analyzer only shows the second error message paragraph (the one with the error code).

I have tried:
* Firefox 44.0.2 for Android (fails in same fashion),
* Chrome 49.0.2623.87 for Windows (shows the page),
* IE 11 (shows the page),
* and two older browsers on Android (both show the page).

Using Chrome, I have looked at the portokalkulator.de certificate.
I did not see any wildcards, but am not sure where to look (which field).

I have looked at http://keyserver.dhl.com/certificates and tried to find the CA certificate there, but have not found a full match.

I have no idea whether the problem with this connection is due to FF or due to the server.
If FF displayed the rejected certificate, that might help narrow down who is to blame, the server or the browser.
(In reply to Rainer Blome from comment #17)
> With FF 44.0.2, I am getting error "sec_error_bad_der" when trying to use
> https://www.portokalkulator.de/ ,
>
> I have no idea whether the problem with this connection is due to FF or due
> to the server.
> If FF displayed the rejected certificate, that might help narrow down who is
> to blame, the server or the browser.

You should probably file a separate bug, I see no indication the problem is that same as with golang (I'm not sure why this bug is open - Google fixed the site and we decided it's a WONTFIX for Firefox?). There are at least 2 problems with that site a) the certificate chain contains the root b) it's using SHA-1.

You will notice that even if you use Chrome the site will not get a green lock.

I also noticed:
Common names 	www.portokalkulator.de
Alternative names 	www.portokalkulator.de

But I'm not sure if that's disallowed.
Yeah, this bug is a wontfix, at least for now. Any work related to wildcards and tlds will go in bug 1196364.
Rainer - it looks like one of the intermediates that site is sending has malformed DNSName entries in its name constraints extension: https://crt.sh/?id=2472155&opt=cablint (for example, the entry for leserservice-sicherheitsabo.de has a trailing space, which isn't valid). Basically, that site needs to update that intermediate.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
>Basically, that site needs to update that intermediate.

I filed bug 1255093 for this. You may be right that the intermediate is wrong, but we're the *only* browser to break on it and that with an error message that's hardly understandable, so the solution for users will be to just switch to another browser.
You need to log in before you can comment on or make changes to this bug.