Should host/domain names travel over the internet with a trailing dot?
Jimmy Hess
mysidia at gmail.com
Tue Feb 26 01:07:20 UTC 2013
On 2/25/13, Jay Ashworth <jra at baylink.com> wrote:
>> From: "Brian Reichert" <reichert at 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
More information about the NANOG
mailing list