My shock is that some webservers don't remove an ending dot before trying to match a virtual host (any besides IIS?), and that web browsers don't assume equivalence, for website SSL cert CN purposes, between "fqdn." and "fqdn".
I'm also shocked that chrome and firefox send a relative domain in Host: headers if that's what's typed into the url bar. Why wouldn't they send the fqdn? Is it specified this way in some RFC? What does this browser "feature" do other than require webservers in orgs with corpdomain.com search paths to add additional vhost aliases to ensure all the requests get to the right place? Switching vhosts to an intranet website based on the request's Host header does not provide any security in an intranet/dns-search-path setup.
It's because it makes the attacker's job easier. "fqdn." and "fqdn" are not the same thing. They may not resolve to the same machine. If one of them resolves to the attacker's machine, you certainly don't want them to be equivalent.
They're not equivalent, but most or all major CAs issue certs without terminating dots, apparently. So I fail to see how distinguishing them during browser checks for cert validity accomplishes anything.
If an attacker controls "fqdn.localsite.com." when the client's (Alice's) intended destination is "fqdn.", isn't the client fooled when Alice has a localsite.com dns search path, if the attacker (Mallory) manages to get a cert for "fqdn"? (Let's suppose Mallory has access to email for "hostmaster@fqdn." but can't get access to the actual "fqdn." webserver to do the attack that way; Mallory sets up "fqdn.localsite.com." to fool Alice's browser which is subject to a "localsite.com." search path.)
If it's the reverse, where Mallory is external and controls "fqdn." and Alice is expecting to get to "fqdn.localsite.com." because of dns search rules, but the dns search rules are broken and Alice gets sent to "fqdn." instead, Mallory wins because the CA-issued cert for the "fqdn." site won't have the terminating dot, right?
>Let's suppose Mallory has access to email for "hostmaster@fqdn." but can't get access to the actual "fqdn." webserver to do the attack that way; Mallory sets up "fqdn.localsite.com." to fool Alice's browser which is subject to a "localsite.com." search path.
Then you're probably still in trouble either way. But suppose the key for the actual cert for "fqdn." was generated with a bad random number generator like what happened with Debian a while back, or the attacker at one point broke into the webserver for "fqdn." and copied the private key and has since been locked but without revoking the compromised certificate, or it was revoked but the client isn't checking CRLs. Now the fact that you used "fqdn." and not "fqdn" in your cert saves you from Mallory's attack using "fqdn.localsite.com".
>They're not equivalent, but most or all major CAs issue certs without terminating dots, apparently.
The CAs will issue a cert for whatever you ask them to issue it for. The issue is that people ask them for certs without the trailing dot.
The real trouble is that we've basically trained the whole world to type "example.com" and not "example.com." and then when it comes to HTTPS, if you type " https://example.com " then the cert has to have "example.com" at least in addition to if not instead of "example.com." or it isn't going to work. But that's no excuse for not allowing the distinction in cases where it can be made, e.g. for subdomains that serve cookies but are never typed by the user, so that the cert for those can contain only the dot-terminated name and the attacker then has a harder time impersonating the subdomain to pilfer the cookie.
SSL libraries seem to treat CNs as fully-qualified, even without the dot. Do we really want a global ssl PKI where non-fqdn CNs are allowed? If not, why should anyone care about trailing dots for ssl cert validation purposes?
>Do we really want a global ssl PKI where non-fqdn CNs are allowed?
It might not have been a bad idea to prohibit it twenty years ago, but at this point it seems unlikely because everybody expects the contrary.
> If not, why should anyone care about trailing dots for ssl cert validation purposes?
Because if the cert has the dot and the address the client is connecting to doesn't, you may not be connected to the right machine.
If I was writing a piece of client software, what I would do sooner than just allowing them to be considered identical is to do a name lookup for "example.com." if that's what's in the cert presented by "example.com" and make sure the IP address is identical to the one for the "example.com" I'm connected to, and then be OK if they are and fail validation if they aren't.
They shouldn't assume equivalence. What should happen is SSl certificates should have both fully-qualified and non-fully-qualified hostnames in them, not just the latter.
I'm also shocked that chrome and firefox send a relative domain in Host: headers if that's what's typed into the url bar. Why wouldn't they send the fqdn? Is it specified this way in some RFC? What does this browser "feature" do other than require webservers in orgs with corpdomain.com search paths to add additional vhost aliases to ensure all the requests get to the right place? Switching vhosts to an intranet website based on the request's Host header does not provide any security in an intranet/dns-search-path setup.