134402 - URLs with trailing dots in host names (FQDN) produce cert name mismatches

Status: RESOLVED WORKSFORME

(NSS :: Libraries, defect)

Description

[Ed Avis]

I went to https://www.paypal.com/ and chose to permanently accept that site's
certificate.  But then one day I typed an extra period at the end of the
hostname - www.paypal.com. - and Mozilla thought this was a different host and
asked me to accept the certificate all over again.  This was a bit worrying at
first, you might suspect a man-in-the-middle attack!

Suggest that DNS names get normalized when making certificates - this will
mostly be stripping off excess dots.  Alternatively the browser could do this
when a URL is typed in.

Sorry I was unable to report what version of PSM: the About Mozilla information
doesn't say.  In fact it doesn't say the version of Mozilla either :-(.  I am
using a milestone build of Moz 0.9.9.

Comment 1

[John Unruh]

Browser:General. You can also reach a non-secure website when typing a dot at 
the end of the URL.

Comment 2

[Matthias Versen [:Matti]]

-> Networking:http

Comment 3

[Darin Fisher]

-> PSM

Comment 4

[Bradley Baetz (:bbaetz)]

Isn't this invalid? foo.com != foo.com., because foo.com could resolve to
foo.com.mycompany.net.au.

Although anyone who does have their network set up that way probably has other
problems....

Comment 5

[Kai Engert [:KaiE:]]

Do we know whether the notation 
  www.host.domain.
is allowed and is defined as being the same as
  www.host.domain
?

And if it is defined, is the application required to preserve that dot, or is it
allowed to strip it off?

I would prefer that we strip off that character as early as possible. I suspect
it makes sense to include that dot when querying DNS. But I'd say, as soon as we
found a match, let's strip it off. That way we don't need special handling in
the rest of the application logic.

For example, when I type
  ping www.host.domain.
on Linux, the status line says it is trying to ping a host which does not
include the dot at the end.

Comment 6

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 8

[Martin Sch]

What happens if I'm in the domain mycompany.com and I go to https://www and the
certificate belongs to www.mycompany.com?

The point is not: do we manipulate the URL in some way that it fits our old software.

The point is: how do I correctly check if a certificate belongs to a host name? For this we have to ask the nameserver for the complete name of the host. Then we check the name from the nameserver against the name in the certificate.

Comment 9

[Kai Engert [:KaiE:]]

I'd appreciate some guidance/pointers on how applications are supposed to deal with names that end with a dot.

Is a.b.com equivalent to a.b.com. ?

If they are equivalent, should the network engine normalize the name, preventing the mismatch?

Comment 10

[Martin Sch]

>Is a.b.com equivalent to a.b.com. ?

If you are working in a company with a big intranet, it could well be that they have a intranet site "a.b.com.mybigcompany.com." and it is sufficient to enter "a.b.com" to get "a.b.com.mybigcompany.com.".

Whereas if you are a private internet user, "a.b.com" will give you ""a.b.com." in most cases! I had the case where there was a host "localhost.provider.com." so when I entered "localhost" this was resolved to "localhost.provider.com." and not to 127.0.0.1!

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 9, and for the benefit of all participants in this
discussion, here is some discussion about the interpretation of host names
from https URLs.  

RFC 2818 defines the matching rules for host names in https URLs to certs.

The BSD Unix implementation of the name resolver established numerous
conventions that have become defacto standards for Unix and Linux, but are
not formally Internet standards, and are not commonly found on other 
platforms, such as Windows.  These include such things as:

a) a dotted decimal IP address with only 2 or 3 components is interpreted
as if some of the components are not merely 8-bit values, but may be 16-bit
or 24 bit values.  For example, 127.1 is interpreted on BSD as 127.0.0.1
because the .1 is interpreted as a 24-bit value.  This is not an internet
standard.

b) a trailing dot tells BSD's DNS name resolver not to try appending domain 
name suffixes.  E.g. for a client in the mozilla.com domain, the DNS name 
foo.bar can be interpreted as foo.bar.mozilla.com as well as foo.bar, but 
foo.bar. is only interpreted as foo.bar and not as foo.bar.mozilla.com.  
These are only conventions of some OSes, and not Internet standards.  

As you probably know, DNS host name resolution plays NO ROLE WHATEVER in 
matching of host names from URLs to host names in certificates.  An SSL 
client in mozilla.com domain NEVER tries to append .mozilla.com to the
host name in a URL to see if it matches the host name in a cert.  If it 
did attempt to do that, it would be vulnerable to attacks to which it is 
NOT vulerable today.  DNS names in certs are always FQDNs, and clients
must always treat the DNS names in URLs as FQDNs, or else they will be
vulnerable to attacks.  Therefore, a host name in a URL is always 
interpreted as if it had a trailing dot.  

The questions then become: 
1) If a URL has a trailing dot in its host name, should libSSL ignore that 
dot for purposes of host name matching to certs?
2) Should it do so even on OSes that do NOT normally interpret trailing
DOTs as suppressing the trial of other DNS suffixes?  

3) Given that libSSL does not ignore trailing dots, should PSM do so?  
4) Should PSM do so on all platforms, or only on those platforms whose DNS
resolvers follow the BSD conventions?

Perhaps we should look to see if RFC 2818 sheds any light on these questions,
and if not, perhaps we should ask its author, who is now the TLS WG chair.
We might also ask: what does IE do? 

Personally, I think we should NOT ignore trailing dots in URLs because it 
encourages the use of trailing dots in URLs that are found in web page 
links.  IOW, it encourages non-standard behavior.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

I will answer my rhetorical questions from comment 11.
- NSS will not ignore trailing dots in the name string it is given to match
against the name(s) in the cert.
- PSM may choose, if it wishes, to strip out a trailing dot from a dns name
before it passes that name to NSS for cert name matching.  
- PSM may also wish to strip trailing dots from dotted decimal IP addresses
given as host identifiers in URLs.  See bug 380543.

Comment 17

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

In addition to what Nelson pointed out, the various equivalent forms of an IPv6 address have similar considerations.

Comment 18

[Wan-Teh Chang]

It is best to specify an IPv6 address in an iPAddress name form in the
subjectAltName extension.  If an IPv6 address literal is specified in
the subject common name, NSS currently does a straightforward case-insensitive
string comparison, without considering equivalent address literals:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.c&rev=1.123&mark=1763,1788-1792#1762

Comment 19

[Jakob Bohm]

This IS an RFC compliance issue.

http://tools.ietf.org/html/rfc2396#section-3.2.2  explicitly allows the "." notation and relative host names in the host field of URLs.

The meaning of this notation is based on
   http://tools.ietf.org/html/rfc1035#section-5.1
with further clarification in RFC1535.

From these it is clear that the correct, RFC-compliant procedure is:
 1. Let Necky (with the help of system resolver libraries) map host identifiers to their absolute forms: IPv4 and IPv6 literals are mapped to their binary equivalent and back to the canonical form of that address (omitting any scope part in IPv6 literals).  Dns names that end with a "." map to themselves.  Dns names that do not end with a "." are subject to an OS specific search list of potential DNS domains to append, plus the fallback option of implying a trailing "."
 2. Even if this involved some DNS lookups to detect domain existence, no CNAMES or other such mechanims apply.
 3. These cleaned up host names or literals is the proper input to the certificate checking code, but no longer using the trailing "." in absolute DNS names.
 4. For clarity the URL visible in the address bar should match this clarification.

Comment 20

[Martin Sch]

sounds perfect....

Comment 21

[bjoern]

after fqdn handling is about to be fixed in firefox like in bug #913785 it would be great if the certificate matching would also be fixed.

Helpfull to answer the question from comment #5 might be this:
https://bugzilla.mozilla.org/show_bug.cgi?id=913785#c4

The trailing dot needs to be preserved for the DNS lookup but it needs to be stripped for the certificate name matching.

Comment 22

[Ryan Sleevi]

FWIW, OS X / Safari and Chrome (all platforms) support this. IE / CryptoAPI does not.

When considering RFC 6125, the goal is to always use reference identifier for name matching. That is, regardless of whether "foo" resolves to "foo.com", "foo.corp.example", or "foo.", the reference identifier is always treated as if it was fully qualified ("foo."). Thus, both "foo" and "foo." are equivalent, from a security perspective.

Equally, we treat presented identifiers (things within the certs) as equally *fully* qualified names. We do not assume some CA is using some implicit DNS suffix search - indeed, they should not, they should only be certifying fully qualified names. As such, a "foo.example" DNS entry in a cert is equivalent to "foo.example." (that is, two fully qualified DNS A labels).

Comment 23

[Ryan Sleevi]

This is NSS, not PSM, per http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/SSLServerCertVerification.cpp#673 , since http://mxr.mozilla.org/mozilla-central/ident?i=CERT_VerifyCertName should be handling the normalization

Comment 24

[Jakob Bohm]

In reply to comment 22:

First of all I will have to note that the authors of RFC 6125 appear at times to be pushing "unusual" agendas on top of the primary job of consolidating name to certificate matching rules, thus it may be occasionally necessary for a sane implementation to override its rules in various minor ways.

Secondly, RFC 6125 makes clear that there is a clear two-part structure to the proper way of doing this.

Part 1: Given the URL being accessed, produce a list of "identities" any of which may match a valid certificate for this URL.  This step belongs closer to the main application logic (not NSS or PSM).  For most cases in Mozilla SSL/TLS scenarios, this will produce the following 2 to 6 names (later changes may produce fewer or more):

 - A DNS name with all IDNA names mapped to their pure ASCII lowercase form and with no trailing period, OR an explicit IP address (IPv4 or IPv6).  IPv6 addresses omit the %adapterId part.
 - A DNS name with all IDNA parts from the pure ASCII form mapped back to their canonical UNICODE form, OR zero to two explicit IP address(es) mapped to the other protocol (regular IPv4 maps to IPv6 ::ffff:x.y.z.w and ::x.y.z.w in IPv6,  IPV4 127.0.0.1 maps to IPv6 ::1, and the reverse of these if the original was IPv6 and has one of these forms.
 - 1 to 3 URL strings formed by reinserting each of the above in the host name field, removing the user name/password field and converting the protocol name field ("HTTPS") to lowercase.

Part 2: Matching these identities against a server provided certificate to determine if they match or not.  This is NSS work and needs to recognize the cases listed in RFC 6125, plus the following:

- Match on a DNS-form CN in the subject, even if SubjectAltName is present (for compatibility with some existing certificates that place only ALTERNATE names in the SubjectAltName).
- Treating Subject Distinguished name elements of type DC ("domain name component") as hierarchically constraining the valid part of the DNS tree for all match types that use DNS names (including those in SubjectAltName).  For instance a certificate issued to CN=Haxor,DC=baz,DC=example,CN=US cannot match the DNS name foo.bar.example via a SubjectAltName, because the DC path constrains it to baz.example and below.  This additional rule allows X.509 intermediary CA path constraints to actually restrict which DNS names it can issue certs for.
- If a SubjectAltName IP address entry specifies an RFC1918 intranet address, this is OK, because the CA is probably an intranet CA for that same intranet.
- Wildcard certificates are NOT deprecated, a security flaw in a current Google initiative may make them even more necessary.

Comment 25

[Ryan Sleevi]

Respectfully, every aspect of Part 2 is insecure and not necessary. Neither IE, Safari, Chrome, nor Opera have performed any step of what has been described, nor are CAs required to check the legitimacy of such a requests. I'm not sure how you have reached these conclusions, but they are wrong and insecure. A scan of the public Internet's certificates will also show such hacks are not needed. Nor has any HTTPS client that I have ever seen - both browser and command-line tool - ever supported matching URI-ID, nor do the Baseline Requirements (as required by Mozilla's Root Program) permit them, so it seems counterproductive to suggest they should be used as reference identifiers.

Additionally, the 'no trailing period' is not only neither stated nor implied in RFC 6125, but the exact opposite is. Ensuring both presented and reference domains are identically normalized (eg: U-LABELS to A-LABELS, case normalization) also includes having both names fully qualified - that is, with the trailing period.

Comment 26

[Jakob Bohm]

Your comment about my part 2 (which is a reference to the structural code organization assumed by RFC 6125) needs to be qualified.  Please state separately for each thing I said, why you think it is insecure.

I am not trying to make a flame war here, but let me at least try to explain the basis for my previous comment (#25).

Here is why I think these are NOT insecure:

General:

Any requirement on Mozilla pre-trusted CAs has no bearing on manually added CAs, such as intranet CAs that are trusted only within a given organization.

In part 1:

- My "no trailing dot" text in Part 1 (not 2) is completely equivalent to your "always add trailing dot" requirement.  Either rule should have the same effect on matching.  The choice is arbitrary and not important.

- Matching both the IDNA converted and UNICODE form of IDNA domain names is intended to avoid the overhead of having to add such names twice in SubjectAltName extensions, the rule is a canonicalization rule to avoid the need for error prone locale- or TLD- specific case mapping rules.  Which rule would you use for matching IDNA host names to certificates?

- URL SubjectAltNames, while not currently issued by public CAs could be considered as more restricted (not less restricted) DNS SubjectAltNames.  I cannot see how implementing that (in accordance with RFC6125) would be a security problem, provided the implementation also reports back that URL was matched and each subsequent URL on the same connection needs to be checked if it is still a match.  This is not that different from a DNS name match when multiple DNS names map to the same IP, but only some of those names are permitted by the certificate on an a reused TLS connection to that IP.

In part 2:

- Match on CN in the presence of SubjectAltName is secure unless a CA issues a certificate which would also cause insecurity in any old client that ignores SubjectAltName completely (I have encountered one such client once, I think it was a version of wget).  Please provide a citation (other than the text of RFC6512) to back up any assertion that no other mainstream client accepts CN matches on the Subject, where that CN is not repeated as a DNS name in a present SubjectAltName extension.

- My additional restriction in the presence of DC= subject name components, cannot cause insecurity, as it is a rule to reject some matches.  Currently, I have only seen such subject names on internal networks where the CAs and DNS are both integrated with Microsoft's LDAP implementation (AD), and the DC= attributes represent zone-like delegations amongst organizational subdivisions.

- The rule not to filter out RFC1918 addresses in certificates assumes that sane public CA's will not issue such certificates, while private intranet CAs frequently will.  I am aware that at least one public CA recently changed their rules to not issue such certificates, and I don't know how widespread or problematic rogue public RFC1918 certs are.

My point is that at least once any such problem with default trusted CAs have been solved and affected leaf certs have expired, there should be no code in NSS preventing the use of IP address certificates internally on intranets.  For instance a certificate (issued by a local CA) for the web interface of a DNS server at https://10.0.0.2 should be allowed to work when fixing a DNS problem using a Mozilla browser.  I don't think the current NSS code blocks such certificate matches, actually.

- The rule not to deprecate wildcard certificates is a matter of reality.  As long as most public CAs overcharge for SubjectAltNames, many multi-name servers will just have to use wildcard certs.  Also, at least google.com uses a *.google.com certificate for some of its servers.  Thus I think I can safely say that most, if not all, mainstream browsers implement this.

Comment 27

[Ryan Sleevi]

(In reply to Jakob Bohm from comment #26)
> Your comment about my part 2 (which is a reference to the structural code
> organization assumed by RFC 6125) needs to be qualified.  Please state
> separately for each thing I said, why you think it is insecure.
> 
> I am not trying to make a flame war here, but let me at least try to explain
> the basis for my previous comment (#25).
> 
> Here is why I think these are NOT insecure:
> 
> General:
> 
> Any requirement on Mozilla pre-trusted CAs has no bearing on manually added
> CAs, such as intranet CAs that are trusted only within a given organization.

I strongly disagree with this, but bugzilla isn't the best place for it. If you feel this way, https://lists.mozilla.org/listinfo/dev-security-policy is the best place to discuss this.

> 
> In part 1:
> 
> - My "no trailing dot" text in Part 1 (not 2) is completely equivalent to
> your "always add trailing dot" requirement.  Either rule should have the
> same effect on matching.  The choice is arbitrary and not important.

The point is to normalize. Strictly speaking, normalizing to strip a trailing dot implies the semantics described in comment #11.

> 
> - Matching both the IDNA converted and UNICODE form of IDNA domain names is
> intended to avoid the overhead of having to add such names twice in
> SubjectAltName extensions, the rule is a canonicalization rule to avoid the
> need for error prone locale- or TLD- specific case mapping rules.  Which
> rule would you use for matching IDNA host names to certificates?

Please read RFC 5280 (and it's preceding versions). A SubjectAltName of type DNSName contains an IA5String, which means it can *only* contain the A-LABEL IDNA forms. It is impossible to match the U-LABEL form against a subjectAltName. This is not about "avoiding overhead", this is about one method being technically impossible.

> 
> - URL SubjectAltNames, while not currently issued by public CAs could be
> considered as more restricted (not less restricted) DNS SubjectAltNames.  I
> cannot see how implementing that (in accordance with RFC6125) would be a
> security problem, provided the implementation also reports back that URL was
> matched and each subsequent URL on the same connection needs to be checked
> if it is still a match.  This is not that different from a DNS name match
> when multiple DNS names map to the same IP, but only some of those names are
> permitted by the certificate on an a reused TLS connection to that IP.

RFC 6125 is *not* meant to describe how *only* HTTPS works, but to support a variety of forms.

RFC 2818, as well as the Mozilla Root CA Security Policy, prohibit these forms. As such, implementing the feature makes no sense, will undergo little real-world use, and will open a practical attack vector to slip in additional (unvalidated) names. This is no different than arguing support for the Logotype extension - simply because it exists does not mean it is good or useful.

> 
> In part 2:
> 
> - Match on CN in the presence of SubjectAltName is secure unless a CA issues
> a certificate which would also cause insecurity in any old client that
> ignores SubjectAltName completely (I have encountered one such client once,
> I think it was a version of wget).  Please provide a citation (other than
> the text of RFC6512) to back up any assertion that no other mainstream
> client accepts CN matches on the Subject, where that CN is not repeated as a
> DNS name in a present SubjectAltName extension.

RFC 2818, the very FIRST HTTPS RFC, has always indicated that CN is deprecated and should ONLY be checked if and only if no subjectAltNames are present. The Mozilla Root CA Security Policy equally requires conformance with the Baseline Requirements, which requires that all registered domain names be present in the subjectAltName, and IF a domain is to be included in the CN field, then it MUST also be present in the SAN.

Any client that fails this check is a buggy client, and does not argue that Mozilla should support or encourage such buggy behaviour. Certainly, NSS has not and will not.

> 
> - My additional restriction in the presence of DC= subject name components,
> cannot cause insecurity, as it is a rule to reject some matches.  Currently,
> I have only seen such subject names on internal networks where the CAs and
> DNS are both integrated with Microsoft's LDAP implementation (AD), and the
> DC= attributes represent zone-like delegations amongst organizational
> subdivisions.

Again, the fact that they exist on internal networks does not make it the responsibility of NSS to support such names. Mozilla and NSS have always set reasonable security goals, and that includes using name types as they were designed (per RFC 2818, RFC 5280, and yes, RFC 6125), in ways that are completely unambiguous as to the hierarchy.

I have seen many such certificates, and they're almost always certainly wrong. For example, they use a SET of AttributeTypeAndValue to represent the domain components - but a SET contains no logical hierarchy (that is, it should be a SEQUENCE of SETs, with 1 AttributeTypeAndValue per SET). Likewise, I have seen implementations that misorder the name components in reverse order, due to misunderstandings about the hierarchal delegation of name.

Regardless, however, you're asking for a new feature to be supported, with is entirely irrelevant to this bug.

> 
> - The rule not to filter out RFC1918 addresses in certificates assumes that
> sane public CA's will not issue such certificates, while private intranet
> CAs frequently will.  I am aware that at least one public CA recently
> changed their rules to not issue such certificates, and I don't know how
> widespread or problematic rogue public RFC1918 certs are.

Mozilla's Root CA Certificate Policy prohibits such internal names, as per the Baseline Requirements, beginning in 2015.

Again, however, you're talking about something completely separate than this bug, and would be better served discussing policy matters on https://lists.mozilla.org/listinfo/dev-security-policy about how such names should be handled.

I never suggested filtering them out - although Chrome intentionally does so for *public* CAs, and which I would encourage Mozilla to do

> 
> My point is that at least once any such problem with default trusted CAs
> have been solved and affected leaf certs have expired, there should be no
> code in NSS preventing the use of IP address certificates internally on
> intranets.  For instance a certificate (issued by a local CA) for the web
> interface of a DNS server at https://10.0.0.2 should be allowed to work when
> fixing a DNS problem using a Mozilla browser.  I don't think the current NSS
> code blocks such certificate matches, actually.

Again, unrelated to the bug.

NSS does indeed respect the iPAddress subjectAltName, does indeed name constrain it, and so there's no action required at all.

Using an iPAddress in a CN is ambiguous, and this is why it's been discouraged for nearly 15 years.

> 
> - The rule not to deprecate wildcard certificates is a matter of reality. 
> As long as most public CAs overcharge for SubjectAltNames, many multi-name
> servers will just have to use wildcard certs.  Also, at least google.com
> uses a *.google.com certificate for some of its servers.  Thus I think I can
> safely say that most, if not all, mainstream browsers implement this.

I said nothing about wildcard certs, this bug says nothing about wildcard certs, it's not suitable to discuss wildcard certs here. Please see https://lists.mozilla.org/listinfo/dev-security-policy

That said, I would encourage you to read such pages as http://security.stackexchange.com/questions/8210/what-vulnerabilities-could-be-caused-by-a-wildcard-ssl-cert to understand why wildcard certs pose risks. For EV certificates, they are prohibited. For DV certificates, they are *permitted*.

Comment 28

[Ben Reser]

RFC 6125 [2] says that DNS-IDs should be fully qualified domain names and points you at RFC 1034 [3] for a definition (which doesn't have a definition sadly).

RFC 1034 does specify the difference between complete (or absolute) domain name and a incomplete (or relative) domain name, with complete domain names including the trailing dot. As best as I can tell the first use of Fully Qualified Domain Names (FQDN) came from RFC 1535 [4]. It doesn't really define the term either but proceeds to use it and mentions "absolute 'rooted' FQDN" in such a way that it implies that absolute is adjective. Finally, we get to RFC 1594 section 5.2 [5] which tries to clear up the matter and describes a FQDN in a way that would seem to require the trailing dot, while giving examples that omit the trailing dot. The Wikipedia article on FQDN [6] says otherwise that the trailing dot is necessary. So at best the definition of FQDN is ambiguous in my opinion which means the RFCs don't help us much here with determining the proper way of handling the trailing dot with respect to PKIX certificate validation.

However, I think that there are some conclusions we can draw using some common sense and thinking about the implications of the behavior.

1) Hostnames are commonly used without the trailing dot. As long as they only are missing the trailing dot they are still fully qualified. Without the trailing dot are not be absolute and are still relative to the root.

2) Nobody issues certificates with the trailing dot in the common name. It doesn't make much sense for the RFC to be defined in a way that is entirely incompatible with the existing certificates. Especially since it went to such an effort to define how to deal with the old Common Name sytle and not only the newer SubjectAltName style.

Maybe they should have been using absolute hostnames in order to allow everyone to distinguish between certificates that were issued for relative domains but they don't. In general I don't think CAs should be issuing certificates for relative domains.

Mozilla's own CA Certificate Inclusion Policy [7] disallows certificates being issued that are not absolute domains. It does so by saying "the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate." I can't fathom how issuing a certificate based on a relative domain say "www" could ever be compliant with that.

3) What's the worst that could happen if you allow a match on "www.example.com." to the certificate with "www.example.com" in the CN or SNA? Well not much because the trailing dot forces you to the absolute hostname which happens to be what the CA issued the certificate for.

You can't (assuming a search domain of "example.org") ever end up at "www.example.com.example.org" and therefor be matching the wrong domain because of the trailing dot tells the resolver not to do that.

Unless someone can point to a platform where the resolver doesn't behave this way I just don't see any downsides from a security perspective of ignoring the trailing dot.

On the other hand I do see some negatives.  Users that accidentally type a trailing dot and are not knowledgeable about the DNS system such that they know what the trailing dot means are likely to be confused by the security warning.  Considering, they have actually reached the real host the certificate is for it may encourage people to click through certificate warnings.  Granted, this is probably not happening very often.

Comment 29

[Ben Reser]

Left off my references on accident in the previous post:

[2] http://tools.ietf.org/html/rfc6125
[3] http://tools.ietf.org/html/rfc1034
[4] http://tools.ietf.org/html/rfc1535
[5] https://tools.ietf.org/html/rfc1594#section-5
[6] http://en.wikipedia.org/wiki/Fully_qualified_domain_name
[7] http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Comment 32

[Daniel Jackson]

This causes cookie problems (and probably other issues), for example:

   http://www.bbc.co.uk
   http://www.bbc.co.uk.

...don't seem to share cookies -- this could cause quite a bit of user confusion (or data loss?).

I would guess this could well affect other site-specific settings (such as security/cookie settings) and/or have same-origin issues?

Incidentally, the link that made me find this:
  https://l10n.mozilla.org./
...while causing a certificate error on Firefox, weirdly causes an internal server error on Chrome/Windows (I guess its maybe sending "." as the path? Or no path at all?)

Comment 33

[Martin Sch]

Bug 1065909 seems to be secret?
"You are not authorized to access bug #1065909."

Comment 34

[Martin Sch]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=393973

Comment 35

[Martin Sch]

(In reply to Ben Reser from comment #28)
> 3) What's the worst that could happen if you allow a match on
> "www.example.com." to the certificate with "www.example.com" in the CN or
> SNA? Well not much because the trailing dot forces you to the absolute
> hostname which happens to be what the CA issued the certificate for.
> You can't (assuming a search domain of "example.org") ever end up at
> "www.example.com.example.org" and therefor be matching the wrong domain
> because of the trailing dot tells the resolver not to do that.

Yes, its is perfectly ok to match  "www.example.com." to the certificate with "www.example.com"
But it is not ok to match "www.example.com" to the certificate with "www.example.com", this is the tricky thing.
Because entering "mybank.com" may resolve to "mybank.com.mycompany.com" (assuming a search domain of "mycompany.com"). For some network guys working at mycompany.com it is easy to set up a server with the name "mybank.com" and all employees entering mybank.com end up at mybank.com.mycompany.com.

Comment 36

[Ryan Sleevi]

(In reply to Jens Martin Schlatter from comment #35)
> (In reply to Ben Reser from comment #28)
> > 3) What's the worst that could happen if you allow a match on
> > "www.example.com." to the certificate with "www.example.com" in the CN or
> > SNA? Well not much because the trailing dot forces you to the absolute
> > hostname which happens to be what the CA issued the certificate for.
> > You can't (assuming a search domain of "example.org") ever end up at
> > "www.example.com.example.org" and therefor be matching the wrong domain
> > because of the trailing dot tells the resolver not to do that.
> 
> Yes, its is perfectly ok to match  "www.example.com." to the certificate
> with "www.example.com"
> But it is not ok to match "www.example.com" to the certificate with
> "www.example.com", this is the tricky thing.
> Because entering "mybank.com" may resolve to "mybank.com.mycompany.com"
> (assuming a search domain of "mycompany.com"). For some network guys working
> at mycompany.com it is easy to set up a server with the name "mybank.com"
> and all employees entering mybank.com end up at mybank.com.mycompany.com.

I think you may be confused.

Yes, it's ok to match "www.example.com." (trailing) to the cert with "www.example.com" (no trailing)
It's also OK to match "www.example.com" (no trailing) to the cert with "www.example.com." (trailing)

It's NOT OK to match "mybank.com" (as entered in the URL bar) to "mybank.com.mycompany.com" (as resolved by DNS), for the reasons you pointed out. This is why "https://foo" will throw an error, but "https://foo.mycompany.com" will work. Just because the DNS name "foo" resolves to the DNS suffix search of "foo.mycompany.com" doesn't mean you should match certs (since DNS is itself unauthenticated, and DNSSEC doesn't help that particular problem).

In either event, Chrome and Safari have been shipping this for years. It's perfectly fine, it's correct from an RFC 6125 point of view, and it's correct in RFC 1034 terms.

Comment 37

[Anne (:annevk)]

Ryan, can you explain why https://annevankesteren.nl./ gives a certificate error in Chrome then? Also, if once you use HTTPS the domains "x.example" and "x.example." are equivalent, why not redirect to the former?

Comment 38

[Ryan Sleevi]

(In reply to Anne (:annevk) from comment #37)
> Ryan, can you explain why https://annevankesteren.nl./ gives a certificate
> error in Chrome then?

Because Chrome sends "annevankestern.nl." in the SNI (and Host header, but that's not why), which causes Dreamhost to crap over and server sni.dreamhost.com cert, which is expired.

> Also, if once you use HTTPS the domains "x.example" and "x.example." are equivalent, why not redirect to the former?

I'm not sure I follow your argument? Are you saying once a user has been to https://x.example. and received a valid cert, and been to https://x.example, and seen a valid cert, treat them as equal? There's still ways for them to end up unequal:

* https://x.example. resolves to a publicly delegated TLD, and terminates in CA A
* https://x.example could resolve to https://x.example.mycorp.com, and has a cert 'valid' for x.example certified by an internally administered CA

And then you've got issues like DreamHost's, where either based on SNI or on the Host header (both which presently, in Chrome, supply the URL as written+canonicalized), could vary content or behaviour.

Even changing the Host header is questionable; some servers and language frameworks use the Host from the client and echo it back out in href's (yes, making them fully absolute rather than relative), and linking to http://x.example from http://x.example. could lead to different results.

Comment 39

[Anne (:annevk)]

Thank you. So the only change we can (and have to) make is that for certificate host equality checks "host" and "host." are identical, but otherwise they're not.

Comment 40

[Martin Sch]

"host" and "host." MAY be the same.

But if I'm in a company, emp.info may resolve to emp.info.company.org., whereas at home emp.info may resolve to emp.info.

So emp.info may point to a host inside a domain.

Comment 42

[O. Atsushi (Torisugari)]

jfyi, taking advantage of this, reddit users seem to cancel paywalls.
https://gigazine.net/gsc_news/en/20200611-dot-host-error/
https://www.reddit.com/r/webdev/comments/gzr3cq/fyi_you_can_bypass_youtube_ads_by_adding_a_dot/

WONTFIX is ok, but if this is not our bug any longer, YouTube, New York Times, Washington Post etc. have to fix their bug.

Comment 43

[riedel]

I think it is a really strange attitude of the dev-team to just close a bug with at least some security implications without a comment. Particularly strange to me is that Mozilla now stops implementing relevant RFCs. From day to day there seem to be less reasons to support a non-chrome browser if Mozilla's aim is just to mimick broken Chrome behaviour...

Comment 44

[Dana Keeler (she/her) [:keeler]]

Perhaps "worksforme" would be more accurate. https://example.com. works just fine.

Comment 45

[J.C. Jones [:jcj] (he/they)]

(In reply to riedel from comment #43)

I think it is a really strange attitude of the dev-team to just close a bug with at least some security implications without a comment.

You're right, sorry, I should have closed this as WORKSFORME with a comment: We were closing out bugs filed more than ten years ago that were obviously fixed, and NSS has no shortage of >15-year-old long-since-relevant bugs.

As I understand it, the purpose of this bug to normalize dNSName labels to ignore trailing dots/label separators, which mozilla::pkix has done since 2014, as a step before doing certificate matching (see MatchPresentedDNSIDWithReferenceDNSID from https://searchfox.org/nss/rev/3f6454c9f55d56d56ebdb035ab8e0fcb0883472c/lib/mozpkix/lib/pkixnames.cpp#1056).

Reverting that long-standing behavior certainly can lead to additional breakage. At this point we'd need to try and fall-back to the host without the trailing dot, when one is requested. If we want to consider that, it should be its own bug in Security: PSM rather than NSS.

Comment 46

[riedel]

Thx for commenting so quickly: Makes at least more sense!!

I remember it was far more broken some time ago and it works now for most sites. So actually I am quite happy with that fact. I was just irritated how bugs are closed without comments.

However, to be clear: the original reported bug is not yet handled: Exceptions for https://self-signed.badssl.com/and https://self-signed.badssl.com./ are still handled differently. But to be fair, this is not what the title of the bug suggests and this is really an edge case.

I also would leave it like this after rethinking it: Cookie handling etc is also "broken" so it is not really a NSS bug anymore (many webserver configurations like bugzilla are also broken wrt)