3 ms·

What is the rationale for web browsers to consider "example.com." different from "example.com" when validating SSL certificates? At first blush this seems sill

What is the rationale for web browsers to consider "example.com." different from "example.com" when validating SSL certificates? At first blush this seems silly, but I may not have thought through the security consequences thoroughly.

derefr 14y ago
Well, for the purposes of SSL verification, or any of these other tests, "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost [theoretically, the A record for a TLD called "localhost"]. Same with "foo.local" and "foo.local." Any non-rooted domain actually has the potential to have what is called a "search domain" applied to it: if your own host's FQDN is bob.example.com, going to "foo.com" can actually take you to "foo.com.example.com.", just like going to "foo" can take you to "foo.example.com." It's just that, conventionally, although it was always an option to use weird TLD-lookin' subdomain hierarchies within domains like that, nobody does it, because it's so confusing. I don't think much at all would break if we enforced a "if your non-rooted domain ends in a known TLD, canonicalize it to a rooted domain before comparison" rule in browsers, the OpenSSL and OpenSSH libraries, etc., and then require that going forward, all X.509 certs, CORS policies, and so forth which are meant to refer to an FQDN are issued only for the rooted version. [If you're curious, DNS zone records themselves are always already canonicalized into rooted form whenever you edit them through any sensible interface.]
- __david__ 14y ago
  > "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost I don't think this is correct. Check out RFC 2606--it implies that .localhost (the TLD) is localhost, which means "localhost" and "localhost." are the same (one will definitely not have a search domain added to it though). I suspect the same applies to .local—I just checked and the multicast DNS draft RFC [1] refers to ".local." everywhere. [1] https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15 https://tools.ietf.org/html/draft-cheshire-dnsext-multicastd...
  - derefr 14y ago
    Hrm, you're right--that's what I get for using any specific examples :) Any other TLD--besides the special-cased "private virtual" ones (localhost., local.)--will still have this problem, though.
gingerlime 14y ago
It's a very good question. I particularly wonder if one can set "www.example.com" to point to a different address from "www.example.com." (globally, not via changing /etc/hosts or your local dns server...)? If they are practically equivalent, then I can't think of much security benefit from treating them differently. Even if changing the behaviour won't cause any security risk, I can't imagine this being a simple change to make. The SSL certificate contains a digital signature that is performed on a hash of many details, including the CN which is typically the FQDN (without the trailing dot). The `CN==requested-server-name?' matching can be performed at different layers and is probably deeply embedded within the specification and in different implementations. Add this to the practicality of needing to use both www.example.com and www.example.com. - it seems that the balance is in favour of keeping things simple and as the post suggested, use a redirect (or buying an extra certificate).
hkolk 14y ago
From the looks of it, Safari ignores the trailing dot when validating (as you can see when going to https://www.facebook.com./ https://www.facebook.com./ ). Curl on the other hand doesn't
- mfwoods 14y ago
  Firefox (nightly) and chromium don't ignore the trailing dot either and both display an invalid certificate error.
zmb_ 14y ago
Because technically speaking they are different things. "example.com." refers to a domain name in a system with a nameless root (like the Internet DNS namespace managed by ICANN). "example.com" would refer to some different (non existent) domain name system with a root called "com". The problem is that in practice many implementations that use DNS names display "example.com" to the user when they really mean "example.com." and many certificates are signed for "example.com" when they really mean to be signing for "example.com." A proper implementation would use "example.com." everywhere, but might choose to display "exmample.com" in the GUI if they consistently translate between the two.

derefr 14y ago

Well, for the purposes of SSL verification, or any of these other tests, "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost [theoretically, the A record for a TLD called "localhost"]. Same with "foo.local" and "foo.local." Any non-rooted domain actually has the potential to have what is called a "search domain" applied to it: if your own host's FQDN is bob.example.com, going to "foo.com" can actually take you to "foo.com.example.com.", just like going to "foo" can take you to "foo.example.com." It's just that, conventionally, although it was always an option to use weird TLD-lookin' subdomain hierarchies within domains like that, nobody does it, because it's so confusing. I don't think much at all would break if we enforced a "if your non-rooted domain ends in a known TLD, canonicalize it to a rooted domain before comparison" rule in browsers, the OpenSSL and OpenSSH libraries, etc., and then require that going forward, all X.509 certs, CORS policies, and so forth which are meant to refer to an FQDN are issued only for the rooted version. [If you're curious, DNS zone records themselves are always already canonicalized into rooted form whenever you edit them through any sensible interface.]

__david__ 14y ago
> "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost I don't think this is correct. Check out RFC 2606--it implies that .localhost (the TLD) is localhost, which means "localhost" and "localhost." are the same (one will definitely not have a search domain added to it though). I suspect the same applies to .local—I just checked and the multicast DNS draft RFC [1] refers to ".local." everywhere. [1] https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-15 https://tools.ietf.org/html/draft-cheshire-dnsext-multicastd...
- derefr 14y ago
  Hrm, you're right--that's what I get for using any specific examples :) Any other TLD--besides the special-cased "private virtual" ones (localhost., local.)--will still have this problem, though.

gingerlime 14y ago

It's a very good question. I particularly wonder if one can set "www.example.com" to point to a different address from "www.example.com." (globally, not via changing /etc/hosts or your local dns server...)? If they are practically equivalent, then I can't think of much security benefit from treating them differently. Even if changing the behaviour won't cause any security risk, I can't imagine this being a simple change to make. The SSL certificate contains a digital signature that is performed on a hash of many details, including the CN which is typically the FQDN (without the trailing dot). The `CN==requested-server-name?' matching can be performed at different layers and is probably deeply embedded within the specification and in different implementations. Add this to the practicality of needing to use both www.example.com and www.example.com. - it seems that the balance is in favour of keeping things simple and as the post suggested, use a redirect (or buying an extra certificate).

hkolk 14y ago

From the looks of it, Safari ignores the trailing dot when validating (as you can see when going to https://www.facebook.com./ https://www.facebook.com./ ). Curl on the other hand doesn't

mfwoods 14y ago
Firefox (nightly) and chromium don't ignore the trailing dot either and both display an invalid certificate error.

zmb_ 14y ago

Because technically speaking they are different things. "example.com." refers to a domain name in a system with a nameless root (like the Internet DNS namespace managed by ICANN). "example.com" would refer to some different (non existent) domain name system with a root called "com". The problem is that in practice many implementations that use DNS names display "example.com" to the user when they really mean "example.com." and many certificates are signed for "example.com" when they really mean to be signing for "example.com." A proper implementation would use "example.com." everywhere, but might choose to display "exmample.com" in the GUI if they consistently translate between the two.