[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007
--- Comment #12 from Fred Morris consult...@m3047.net ---
Wow. Well, there's a lot more to this than I reckoned... for the most part this
discussion is beyond me. I do have one comment: any final dot should be ignored
for comparison purposes.
3) server/vhost.c::fix_hostname() should stop stripping the trailing dot.
www.example.com and www.example.com. are the same thing; at least they're
supposed to be, at least that's consistent with the principle of least
surprise. Actually, the former is supposed to be the latter. Because nobody
really wants to go to www.example.com.ru. or www.example.com.example.com.
Right? But that's what would potentially happen with a search list. The search
list will not be applied to the second one, because it ends in dot.
So: DNS says they're equivalent, but with a footnote regarding resolvers and
search lists.
Apache logs them differently (with %{Host}i so I presume this comes from the
Host: header): without and with the dot. I don't know if the client should be
sending them differently... However I expect them to refer to the same
(virtual) host, I would be very surprised if they didn't. Servers which don't
treat them the same are as far as I'm concerned broken. (Apache does treat them
the same, which is to say if you set up a NameVirtualHost with separate
logging, both the no dot (logging 200) and dot (logging 400) get directed to
that VirtualHost, which is defined without the dot.)
Now that I'm paying attention, I don't see any ServerName examples with the
trailing dot in the Apache manual.
I just looked through RFC 2616. I didn't find anything about the dot (somebody
else should check, in case I missed it). The examples all show without the dot
though. For the SNI header, the relevant specification says that the hostname
should be sent without the dot and it's very specific and clear about that. On
that basis we can conclude that Firefox is broken (and it's hardly the only
broken client out there); but it is consistent between the SNI hostname and the
Host: header.
Now I want to offer a different example: jira and jira. (It's a better example
for these purposes than mail and mail., although you can ask the guy who owns
mail.com about the impact of search lists if you don't see the importance.)
jira. (with the dot) isn't going to resolve anywhere.. unless I have a private
vanity TLD of jira. But if I have example.com in my search list, the resolver
library tacks it onto jira and attempts to resolve jira.example.com.
What gets logged is jira without the dot; and apparently that's consistent with
SNI because the page gets served.
What do we expect the browser to send in this case? In spite of Firefox's
(misguided IMO) attempts to manage its own DNS resolution I don't think we can
expect clients to have visibility into what the resolver is doing, I think we
just have to expect this; and consequently (and unfortunately) we can't expect
the server to magically apply the same search list and come up with
jira.example.com. But nonetheless jira and jira. should be the same vhost as
far as the server is concerned.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 --- Comment #13 from Fred Morris consult...@m3047.net --- See also: bug 57810 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 --- Comment #15 from Fred Morris consult...@m3047.net --- It's not like compatibility with broken clients isn't a consideration: bug 56241 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 57810] Should apache ignore difference in trailing dot between SNI and HTTP requests?
https://bz.apache.org/bugzilla/show_bug.cgi?id=57810 --- Comment #2 from Fred Morris consult...@m3047.net --- (In reply to Jean-Luc Duprat from comment #1) [...] [ssl:error] [pid 22158] AH02032: Hostname example.com. provided via SNI and hostname example.com provided via HTTP are different [...] Since the URL is generated by service discovery I have no control over it. The clients also behave consistently. The only way to get this to work would be for apache to allow for this minor difference between the SNI and HTTP hostnames. I believe that www.example.com and www.example.com. are equivalent. Apache already treats vhosts this way, it SHOULD (in the jargon of RFCs) ignore trailing dots for FQDN equivalence. My research indicates (most, in fact) clients are in error, because the SNI specification at least (not HTTP unfortunately) unequivocally calls for the trailing dot to be dropped. See bug 58007. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 --- Comment #14 from Fred Morris consult...@m3047.net --- Interesting: bug 56718 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 --- Comment #8 from Yann Ylavic ylavic@gmail.com --- The SNI is compared against r-hostname, which is a parsed value of the original Host header (without the port, the trailing dots), supposedly SNI compatible... So I wonder if: 1) we should fix this, since clients are not supposed to dot FQDNs in SNI, 2) the SNI should be matched against the Host header instead of r-hostname (i.e. the fix belongs in mod_ssl only), 3) server/vhost.c::fix_hostname() should stop stripping the trailing dot. My personnal preference would be 3) since two hosts w/ and w/o the trailing dot (FQDN or not) are possibly not the same ones (and hence the same VirtualHosts). httpd could (theorically) be asked to handle them separately (or not), by using differents ServerNames (or one as ServerName, the other as ServerAlias). There is possibly a compatibility issue though by changing this at the vhost level, and this is beyond the SSL only scope. So we should probably go for 2) since browsers don't play game 1). I don't think we can be lenient and therefore ignore the trailing dot from SNIs, let's be consistent in a strict way. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 --- Comment #11 from Yann Ylavic ylavic@gmail.com --- Discussion about SNIed connections reuse moved to dev@. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 Yann Ylavic ylavic@gmail.com changed: What|Removed |Added CC||ylavic@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 --- Comment #9 from Stefan Eissing ste...@eissing.org --- It cannot be considered a bug when SNI and Host header differ. You cannot expect all requests on the same connection to have the same Host header either. Browsers will reuse TLS connections, if hostnames resolve to the same IP address and wildcard certs or matching alternate names in the certificate to match. It is really a client decision to reuse an existing connection for other hostnames. And if the server wants the client to use another connection for such a request, 421 is the proper status code. See http://httpwg.github.io/specs/rfc7540.html#HttpExtra Section 9.1.2 Additionally, the Alt-Svc http extensions https://httpwg.github.io/http-extensions/alt-svc.html#alt-svc explicitly encourages clients to use a connection for foreign URLs. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 --- Comment #10 from Yann Ylavic ylavic@gmail.com --- Hmm, so how are we supposed to handle a subsequent request on the same connection but for a different vhost with differents SSL parameters (eg. SSLProtocol, CipherSuite, ...), renegotiate? Where is the win with SNI here? How does the client side know about that? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 58007] 400 Bad Request with fully qualified domain name over HTTPS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58007 Leho Kraav @lkraav l...@kraav.com changed: What|Removed |Added CC||l...@kraav.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
