Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The danger of the trailing dot in the domain name

saynt2day.blogspot.ru

Post reply on HN
Print view View original

61–70 of 75 posts

Re: The danger of the trailing dot in the domain name

#61

Post by __david__ »

TazeTSchnitzel wrote: post #53
harshreality wrote: post #43

Earlier quoted context omitted.

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?…

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.

Actually shouldn't they only have the fully qualified domain name in the cert?

If I get a cert for example.com nobody expects it to also be valid for example.com.apple.com which means that the dot is implied...

The fact that browsers give cert errors for the dotted name seems like a bug to me.

Re: The danger of the trailing dot in the domain name

#62

Post by heartbreak »

martinced wrote: post #45
kostya-kow wrote: post #24

Earlier quoted context omitted.

Stack overflow uses IIS??

Yes and it really showed in the beginning: they had lots of issues and you could constantly see the cat saying "sorry, i am wurkin' on fixin' yer problem" (don't remember the exact msg but it was a lolzcat message). SO is also hardly something impressive from a UI point of view: it is a very simple UI really not doing much. Usenet readers from 20 years ago were way more capable than SO...

What does IIS have to do with the UI, exactly? It's just a web server.

Re: The danger of the trailing dot in the domain name

#63

Post by AnthonyMouse »

harshreality wrote: post #56
AnthonyMouse wrote: post #50

Earlier quoted context omitted.

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…

>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.

Re: The danger of the trailing dot in the domain name

#64

Post by TazeTSchnitzel »

__david__ wrote: post #61
TazeTSchnitzel wrote: post #53

Earlier quoted context omitted.

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.

Actually shouldn't they only have the fully qualified domain name in the cert? If I get a cert for example.com nobody expects it to also be valid for example.com.apple.com which means that the dot is implied... The fact that browsers give cert errors for the dotted name seems like a bug to me.

Of course they should only have the FQDN, but in practise they need to have the normal one too for compatibility :/

Re: The danger of the trailing dot in the domain name

#65

Post by pmorici »

heartbreak wrote: post #62
martinced wrote: post #45

Earlier quoted context omitted.

Yes and it really showed in the beginning: they had lots of issues and you could constantly see the cat saying "sorry, i am wurkin' on fixin' yer problem" (don't remember the exact msg but it was a lolzcat message). SO is also hardly something impressive from a UI point of view: it is a very simple UI really not doing much. Usenet readers from 20 years ago were way more capable than SO...

What does IIS have to do with the UI, exactly? It's just a web server.

The site's UI is simple and yet the server still can't handle it perhaps was the implication.

Re: The danger of the trailing dot in the domain name

#66

Post by zimbatm »

AnthonyMouse wrote: post #54
zimbatm wrote: post #21

Earlier quoted context omitted.

The search path spoofing argument is weak. If you depend on a DNS resolver that spoofs domain searches, what guaranteed that it wouldn't simply spoof the full resolution as well ? In practice nobody uses the dot at the end except when writing BIND files.

>If you depend on a DNS resolver that spoofs domain searches, what guaranteed that it wouldn't simply spoof the full resolution as well ? A lot of DHCP servers do DDNS. That allows you to change your computername and get your computer registered in the local DNS as whatever-you-want followed by the local domain which is usually in the search domains list. You can't get registered as "google.com" but you can get regis…

Yeah agreed but what's the most likely outcome. You rewriting your urls or you fixing your network / kicking the offending user ? You're not only impacting browsing experience but also all the scripts that are trying to connect to the domain like your google drive sync agent.

Re: The danger of the trailing dot in the domain name

#67

Post by harshreality »

AnthonyMouse wrote: post #63
harshreality wrote: post #56

Earlier quoted context omitted.

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…

>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…

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?

Re: The danger of the trailing dot in the domain name

#68

Post by vyrotek »

martinced wrote: post #45
kostya-kow wrote: post #24

Earlier quoted context omitted.

Stack overflow uses IIS??

Yes and it really showed in the beginning: they had lots of issues and you could constantly see the cat saying "sorry, i am wurkin' on fixin' yer problem" (don't remember the exact msg but it was a lolzcat message). SO is also hardly something impressive from a UI point of view: it is a very simple UI really not doing much. Usenet readers from 20 years ago were way more capable than SO...

Other sites built with IIS & MVC - http://stackoverflow.com/a/12006474/10941

monster.com, break.com, ancestry.com, wildtangent.com, kbb.com, redbox.com , nordstrom.com , townhall.com, tunein.com, g4tv.com

Don't blame the framework, blame the developers.

Re: The danger of the trailing dot in the domain name

#69

Post by AnthonyMouse »

zimbatm wrote: post #66
AnthonyMouse wrote: post #54

Earlier quoted context omitted.

>If you depend on a DNS resolver that spoofs domain searches, what guaranteed that it wouldn't simply spoof the full resolution as well ? A lot of DHCP servers do DDNS. That allows you to change your computername and get your computer registered in the local DNS as whatever-you-want followed by the local domain which is usually in the search domains list. You can't get registered as "google.com" but you can get regis…

Yeah agreed but what's the most likely outcome. You rewriting your urls or you fixing your network / kicking the offending user ? You're not only impacting browsing experience but also all the scripts that are trying to connect to the domain like your google drive sync agent.

>Yeah agreed but what's the most likely outcome. You rewriting your urls or you fixing your network / kicking the offending user ?

Who is "you"? The person who can fix the URLs is rarely the same person who can kick the offending user off the local network. If the latter person is not doing their job (or is about to but hasn't yet), you're still better off fixing your URLs.

>You're not only impacting browsing experience but also all the scripts that are trying to connect to the domain like your google drive sync agent.

You don't have to break the old stuff, just start using the final dot for new stuff.

Re: The danger of the trailing dot in the domain name

#70

Post by AnthonyMouse »

harshreality wrote: post #67
AnthonyMouse wrote: post #63

Earlier quoted context omitted.

>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…

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.

Post reply on HN