On 2/25/13, Jay Ashworth <jra@baylink.com> wrote:
From: "Brian Reichert" <reichert@numachi.com> [snip] 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.
By the time the hostname is sent over HTTP, the SSL connection is already established, and all the SSL negotiation already happened.. 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. 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 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. 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. It probably doesn't matter if the server removes the "." or not, before sending it.. the server has to allow the dot. 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. " -- -JH