4 ms·

You can cd to /home/user or /home/user/ as well. The dot's in DNS are equivalent to the slashes in your Unix file system. / is root . is root I'm shocked tha

by 16s 14y ago

You can cd to /home/user or /home/user/ as well. The dot's in DNS are equivalent to the slashes in your Unix file system. / is root . is root I'm shocked that many people on HN don't seem to understand this.

harshreality 14y ago
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.
- AnthonyMouse 14y ago
  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.
  - harshreality 14y ago
    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?
    - AnthonyMouse 14y ago
      >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 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.
      - harshreality 14y ago
        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?
        AnthonyMouse 14y ago
        >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.
- TazeTSchnitzel 14y ago
  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.
  - __david__ 14y ago
    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.
    - TazeTSchnitzel 14y ago
      Of course they should only have the FQDN, but in practise they need to have the normal one too for compatibility :/
Cushman 14y ago
Not the same thing, really, since domains are reversed compared to file paths. In domains, the root token is optional and assumed; like if 'home/user' meant the same thing as '/home/user'.
- TazeTSchnitzel 14y ago
  Well, reverse the path then. "news.ycombinator.com." is equivalent to "/com/ycombinator/news", but more commonly we use "news.ycombinator.com", equivalent to "com/ycombinator/news". The root token is not optional and assumed at all. Instead, there are multiple "search paths", like with binaries on *nix and Windows/DOS. Now, usually, it will check "." ("/") somewhere along the way, but people often have intranet domains which are also checked, so what you expected to resolve to "news.ycombinator.com." might resolve to "news.ycombinator.com.mycompany.com."
  - Cushman 14y ago
    That's what the spec says. In practice, no one uses fully-qualified domains, and users who generally do not even know they exist rightly assume any domain name ending in a TLD should take them to the site indicated by that root, and it's surprising and confusing if it does not. Which is why it's pretty different from relative vs. absolute paths, which is a much-used and generally well-understood distinction.
    - TazeTSchnitzel 14y ago
      This is really going to blow up with the new gTLDs though, there is so much more room for conflict between root DNS and local DNS with so many more TLDs.
      - Cushman 14y ago
        Not the only problem gTLDs are going to cause, either. I'm still hoping they pull the plug on the whole concept.
  - kelnos 14y ago
deleted 14y ago
[deleted]

by 16s 14y ago

harshreality 14y ago

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.

AnthonyMouse 14y ago
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.
- harshreality 14y ago
  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?
  - AnthonyMouse 14y ago
    >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 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.
    - harshreality 14y ago
      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?
      - AnthonyMouse 14y ago
        >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.
TazeTSchnitzel 14y ago
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.
- __david__ 14y ago
  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.
  - TazeTSchnitzel 14y ago
    Of course they should only have the FQDN, but in practise they need to have the normal one too for compatibility :/

Cushman 14y ago

Not the same thing, really, since domains are reversed compared to file paths. In domains, the root token is optional and assumed; like if 'home/user' meant the same thing as '/home/user'.

TazeTSchnitzel 14y ago
Well, reverse the path then. "news.ycombinator.com." is equivalent to "/com/ycombinator/news", but more commonly we use "news.ycombinator.com", equivalent to "com/ycombinator/news". The root token is not optional and assumed at all. Instead, there are multiple "search paths", like with binaries on *nix and Windows/DOS. Now, usually, it will check "." ("/") somewhere along the way, but people often have intranet domains which are also checked, so what you expected to resolve to "news.ycombinator.com." might resolve to "news.ycombinator.com.mycompany.com."
- Cushman 14y ago
  That's what the spec says. In practice, no one uses fully-qualified domains, and users who generally do not even know they exist rightly assume any domain name ending in a TLD should take them to the site indicated by that root, and it's surprising and confusing if it does not. Which is why it's pretty different from relative vs. absolute paths, which is a much-used and generally well-understood distinction.
  - TazeTSchnitzel 14y ago
    This is really going to blow up with the new gTLDs though, there is so much more room for conflict between root DNS and local DNS with so many more TLDs.
    - Cushman 14y ago
      Not the only problem gTLDs are going to cause, either. I'm still hoping they pull the plug on the whole concept.
- kelnos 14y ago

deleted 14y ago

[deleted]