 |
 |
Hi, I think the interpretation of `isHostName` is correct - it's meant to detect and handle the case where the user provides a raw IP address. In such a case, we rely on reverse DNS. If we want to copy what the rest of the world does, we would fail the particular use case mentioned by @simonmichal . For example, `curl` does _not_ expand a hostname provided by the user to a FQDN: ``` $ curl https://www/ curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate. ``` This is because DNS is typically considered insecure and `curl` doesn't want to rely on DNS to bootstrap the TLS security. On this host, the DNS search domain is set to `unl.edu`, meaning that `www` expands to `www.unl.edu`; the latter matches the server certificate. Ways forward: 1. At the GSI layer, additionally detect non-qualified hostnames and qualify them. * From what I can tell, this would continue to make GSI "unique" -- KRB5 doesn't do this currently. * This means GSI is reliant on DNS still, which is bad from the security standpoint. But this occurs anyway in order to not break EOS support. 2. At the client layer (`xrdfs`, `xrdcp`) detect non-qualified hostnames and qualify them. 3. Have a backward compat break. I'd lean toward (1) (maybe adding a security warning or a config flag to allow folks to turn off the reliance on DNS?). Thoughts? Brian PS - @simonmichal - you may want to let the CMS EOS be aware of the fact that they don't have SANs setup correctly. That's very fixable but would cause problems the improved security. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/725#issuecomment-395171428 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1