Closed
Bug 1169149
Opened 9 years ago
Closed 8 years ago
golang.org reports sec_error_bad_der error
Categories
(Core :: Security: PSM, defect)
Core
Security: PSM
Tracking
()
RESOLVED
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)
Reporter | ||
Updated•9 years ago
|
URL: https://golang.org/
Assignee | ||
Comment 1•9 years ago
|
||
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.
Reporter | ||
Updated•9 years ago
|
status-firefox38:
--- → affected
status-firefox38.0.5:
--- → affected
status-firefox39:
--- → affected
status-firefox40:
--- → affected
status-firefox-esr31:
--- → affected
status-firefox-esr38:
--- → affected
Comment 2•9 years ago
|
||
Relevant discussion on twitter: https://twitter.com/agl__/status/604100924127117312
Comment 3•9 years ago
|
||
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
Comment 4•9 years ago
|
||
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.
Assignee | ||
Comment 5•9 years ago
|
||
This change happened in 36, so ESR31 shouldn't be affected.
Blocks: 1063281
Assignee | ||
Comment 6•9 years ago
|
||
1169149 - enforce wildcard presented DNS ID minimum label count when matching, not parsing
Attachment #8613755 -
Flags: review?(cykesiopka.bmo)
Assignee | ||
Updated•9 years ago
|
QA Contact: dkeeler
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → dkeeler
QA Contact: dkeeler
Assignee | ||
Updated•9 years ago
|
Attachment #8613755 -
Flags: review?(brian)
Comment 7•9 years ago
|
||
(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.
Updated•9 years ago
|
Attachment #8613755 -
Flags: review?(cykesiopka.bmo) → review+
Comment 8•9 years ago
|
||
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.
Assignee | ||
Comment 9•9 years ago
|
||
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+
Assignee | ||
Comment 10•9 years ago
|
||
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
Assignee | ||
Comment 11•9 years ago
|
||
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)
Assignee | ||
Updated•9 years ago
|
Attachment #8613755 -
Flags: review?(brian)
Comment 12•9 years ago
|
||
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)
Comment 13•9 years ago
|
||
Comment 14•9 years ago
|
||
(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.
Comment 15•9 years ago
|
||
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 16•9 years ago
|
||
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-
Comment 17•8 years ago
|
||
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.
Comment 18•8 years ago
|
||
(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.
Assignee | ||
Comment 19•8 years ago
|
||
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: 8 years ago
Resolution: --- → WONTFIX
Comment 20•8 years ago
|
||
>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.
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•