httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Host vs SNI and final dot
Date Wed, 11 Jan 2017 13:51:43 GMT
https://some.domain.tld./ may fail with AH02032 (400 Bad Request)
because "Hostname provided via SNI and hostname provided via HTTP"

Not very commonly generated by servers, this URL end up being
generated by some email clients (mainly on smart phones/tabs) while
"interpreting" message contents (i.e. sentences often end with "...,
see https://some.domain.tld.", with the final dot being the one of the
sentence, not really the FQDN which most email writers are not enough
aware of, along with the trailing slash :)

In httpd, r->hostname's final dot is stripped but not the SNI's.

So I tried https://some.domain.tld./ with several browsers (and cURL)
and they seem to all put the final dot in both SNI and Host header
(but cURL that strips them in both).

The specs don't help (me) to much here, RFC 6066 (section 3) says the
SNI is "represented as a byte string using ASCII encoding without a
trailing dot", while RFC 7230 (section 5.4) states that "a client MUST
send a field-value for Host that is identical to that [target URI]
authority component".
Regarding the authority, itself defined (AIUI) in RFC 3986 (section
3.2.2), we have: "The rightmost domain label of a fully qualified
domain name in DNS may be followed by a single "." and should be if it
is necessary to distinguish between the complete domain name and some
local domain".
What a mess...

So main browsers do not conform to RFC 6066 by dot-ing the SNI, while
httpd (and cURL) don't conform to RFC 7230 by undot-ing the Host.

Usually one can "ServerAlias some.domain.tld." to avoid AH02032 (not
on 2.2.x though, where the SNI is blindly string-compared with
r->hostname), but still the SNI (per SSL_get_servername() or
ENV:TLS_SNI) and hostname (per non canonicalized ap_get_server_name()
or r->hostname directly) will differ for all looking modules/CGIs.

Could/should we do something about this?
The easier thing would be to strip the SNI to avoid AH02032 with
actual browsers, we won't be less compliant than now.
The hard way seems to be to let the trailing dot in r->hostname (for
redirects/proxypreserve/... to keep it), but then (beyond the compat
issues) we'd have to do something about the SNI with RFC 6066
conforming clients...

Sorry for the long message, and thanks to those here, still ;)

View raw message