On Mon, Feb 25, 2013 at 09:49:19AM -0500, Jay Ashworth wrote:
----- 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.
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.
My understanding is this: Unless you're doing client certificate verification (wherein the server is making decisions about which clients attempting a connection), all validation/verification is done by the client. The SSL client retrieves the server's certificate, and the set of values in the Subject and the Subject Alternative Name is compared against the hostname/IP address used to initiate the process. This comparison is (to my understanding) straight-forward (modulo UTF8 encodings, etc.). The upshot (assuming I'm not totally off base here), is that other than getaddrinfo(), nothing is acting on the semantics of the supplied hostname (or IP address). They are 'just strings', and are (essentially) compared as such.
Cheers, -- jr 'yeah, I know, it's Monday' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large