In message <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: [I believe this is Brian, then Mark: ]
When I did my initial development with OpenSSL, I observed:
- If I did not have the rooted domain name in the SAN, then any SSL client stack would fail the verification if a rooted domain name was used to connect to the SSL server.
Well you have a broken SSL client app. If it is accepting non legal hostnames it should be normalising them before passing them to the ssl layer.
From what little research I've done (only OpenSSL), the SSL client is relying on getaddrinfo(3) to do name resolution. In turn, I haven't found an implementation of getaddrinfo(3) that rejects rooted domain names as non-legal.
And getaddrinfo() returns the canonical name (ai_canonname) which is the name found after searching, if any, and CNAMEs (DNAME) have been followed. It doesn't have a period at the end unless there is a implementation bug. struct addrinfo { int ai_flags; /* input flags */ int ai_family; /* protocol family for socket */ int ai_socktype; /* socket type */ int ai_protocol; /* protocol for socket */ socklen_t ai_addrlen; /* length of socket-address */ struct sockaddr *ai_addr; /* socket-address for socket */ char *ai_canonname; /* canonical name for service location */ struct addrinfo *ai_next; /* pointer to next in list */ }; Now http{s} clients and server administrators have misused CNAME for years so ai_canonname is not as useful as it should be. ai_canonname should match the expected name in the presented CERT. As a result the http{s} client needs to do the normalisation including search list processing. Yes there are lots of broken clients.
Yes, but that's not the question, Brian, assuming I understand the problem as well as I think I do. The question is not how the client does the name resolution on the client machine -- it's what it does with the domain name it's looking up before doing the SSL interaction with the server side, a process with which I'm not familiar enough to know if the client actually send the host/domain name to the server end. Assuming it does -- and I am -- the question is: should it take the dot off.
===
More formally: "is a host/domain name with a trailing dot *actually a legal host name?
No. See RFC 952
Or is that merely local shorthand notation for resolvers and DNS server zone files, to define absoluteness. In short: are domain names on-the-wire *always* to be interpreted as absolute even in the absence of a trailing dot."
My personal opinion, based on about 2 decades of watching from the outside, and of systems analysis and application design in non-internet contexts, is to say that yes, they must; there is *in fact* no reason for a relative domain name to leave a machine, since the context for it's relativity is dependent on the resolv.conf on that machine for lookups, and on which zone file it's in for service...
and that the implication of that is that any application/library which takes a text-string host/domain name handed to it from off-machine ought to normalize away any trailing dot.
I invite counter-arguments and -citations. :-)
Cheers, -- jr 'yeah, I know, it's Monday' a -- Jay R. Ashworth Baylink jra@baylink.co m Designer The Things I Think RFC 210 0 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI I St Petersburg FL USA #natog +1 727 647 127 4
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org