The danger of the trailing dot in the domain name
saynt2day.blogspot.ru
The danger of the trailing dot in the domain name
1–10 of 75 posts
Re: The danger of the trailing dot in the domain name
#2What 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.
Re: The danger of the trailing dot in the domain name
#3D'oh. It would seem to me that for the purposes of X.509/CORS/server config/etc. equality, domains which seem to be rooted in any of the TLD registries should be canonicalized first to add the dot on both sides (along with doing the IRI -> URI conversion and so forth that should happen either way.) Is there any reason that would be a bad idea?
Re: The danger of the trailing dot in the domain name
#4I use RequestPolicy to whitelist access to other domains' resources. Usually most sites that have CSS on external resources show up as black-and-white, which is perfectly readable. But this one is displayed as blue text on red background... WTF?
Re: The danger of the trailing dot in the domain name
#5What 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.
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.]
Re: The danger of the trailing dot in the domain name
#6I use RequestPolicy to whitelist access to other domains' resources. Usually most sites that have CSS on external resources show up as black-and-white, which is perfectly readable. But this one is displayed as blue text on red background... WTF?
It's something I see a lot over slow connections--more commonly, black text on a black background, where eventually a white "content-layer background" image will load behind the text, making it readable.
Re: The danger of the trailing dot in the domain name
#7What 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.
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).
Re: The danger of the trailing dot in the domain name
#8[deleted]
Re: The danger of the trailing dot in the domain name
#9I wouldn't call it a 'danger' more like an 'annoyance', unless someone is MITM you with a certificate for the name ending in dot or something like that
Maybe redirect, but I'd go for making it not work, period. (I don't mean 'broken', I mean blank page or forbidden)
Re: The danger of the trailing dot in the domain name
#10The fact that the two IIS based sites (Microsoft, Stack overflow) both fail with an outright error 400 complaining about a bad host name makes me wonder whether this might actually be a bug in IIS to overzealously validate the hostname.
The trailing dot is totally valid and there's no need to complain.