Should host/domain names travel over the internet with a trailing dot?

Tue Feb 26 02:06:39 UTC 2013

----- Original Message -----
> From: "Jimmy Hess" <mysidia at 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 at 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