----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
By the time the hostname is sent over HTTP, the SSL connection is already established, and all the SSL negotiation already happened..
Correct, and yes, I did already know that (though, this morning, before coffee, it would have been hard to tell for sure :-).
it's up to the client to validate the server's FQDN matches the CN of the certificate, or an alternative DNS name; which are all are (hopefully) or ought to be, by definition FQDNs, before the server knows what hostname(s) HTTP requests will be made against.
Also correct. Our issue on point is this: that match where we supply an FQDN is performed by *some piece of code*, which knows that there are multiple names against which to match. What does that code do with a hostname string which is terminated by a period (it apparently does not treat it specially, and just attempts to match with it included, from Brian's experience) and... Is that the proper behavior?
If the domain in a certificate were not interpreted as a FQDN by the client, this would mean, that the certificate for CN=bigbank.example.com might be used to authenticate a connection to https://bigbank.example.com which do the local resolver search order, is in fact a DNS lookup of bigbank.example.com.intranet.example.com
Sure: you can't match a supplied server domain name against cert names which are *longer* (have more atoms) than it is; I get that, see why, and approve.
Which might be captured by a Wildcard A record for *.com found in the intranet.example.com. zone and pointed to a server containing a phishing attack against bigbank.example.com; with a DNS cache poisoned by a false negative cache NXDOMAIN entry for bigbank.example.com.
As is mentioned in RFC 1535, which Mark chastised me for accidentally mentioning a couple hours ago; yes. :-) Oh wait; no, this is a different *class* of attack, no? I can't *have* a wildcard for *.com, *because my resolvers won't ask my servers for that; they'll ask the root*; or do I need to finish reading 1535?
The exeption to not sending the domain name before encryption, would be the shiny new TLS protocol version with the server supporting the rarely used SNI extension; extension for server name indication, that will one day allow virtual hosting for TLS protected HTTP transport, sharing one IP address, with a different X509 certificate served up by the server, based on which hostname has been requested (once browsers and servers begin to support TLS1.2 as a replacement for SSL); in this case, the crypto stack on the server does gain access to the hostname.
Wow; we *really* don't want to implement IPv6, do we? :-)
It probably doesn't matter if the server removes the "." or not, before sending it.. the server has to allow the dot.
It's not a question of what the server does; the server returns a Server Certificate packet, which the client library either matches on itself, or hands upstairs to ... something else. One of those two things makes the comparison, and our question is: Should that thing trim a trailing dot *off the local string*, before matching the names that came in in the cert. If my assertion from this morning, that names are automatically "absolute" in 1035 terms -- that is, a domain name with a dot after is equal to one without -- *everywhere except* 1) in a resolver query (where they're a hint to the resolver, and *don't* go out with the dot over the wire -- at leastI think they don't; I have to double check... and 2) inside a zone file, where they're a hint to the *server* about where to root the record; against $ORIGIN or not... is true, then the behavior I suggest for opening an SSL/TLS connection should also hold: strip the dot before you match, then match absolutely.
The HTTP/1.1 does mention something about HTTP proxies possibly being able to handle a hostname that is not a FQDN, solely by appending their own domain to the hostname; appending a suffix to the hostname is allowed, in that specific case, but a FQDN must not be changed.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 " The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name. "
Hmmm. I don't know that that applies here; we're strictly HTTPS; can you proxy that? Even if you could, the thing you need to look at is inside the encrypted channel, I think. Cheers, -- jra -- 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