bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] [Fwd: Re: [bug #47408] Wget sends malformed SNI host names]


From: y.st.
Subject: [Bug-wget] [Fwd: Re: [bug #47408] Wget sends malformed SNI host names]
Date: Wed, 16 Mar 2016 09:50:39 -0700

Oops, I sent this to a personal email address instead of the mailing
list. Forwarding to the mailing list.
-------- plusendita mesaĝo --------
De: y.st. <address@hidden>
Al: Tim Ruehsen <address@hidden>
Temo: Re: [Bug-wget] [bug #47408] Wget sends malformed SNI host names
Dato: Wed, 16 Mar 2016 09:18:13 -0700

I noticed the problem in both Firefox and Chrome, and the bug has been
reported in both, as well as in several other Web browsers. As for cURL,
I also saw that error, but I haven't had time to report it yet. I'll
probably report it today.

In any case, I'd recommend not following either. Instead, it seems like
a better idea to follow the RFCs.

On mer, 2016-03-16 at 12:46 +0100, Tim Ruehsen wrote:
> On Wednesday 16 March 2016 11:59:04 Daniel Stenberg wrote:
> > On Wed, 16 Mar 2016, Tim Ruehsen wrote:
> > > Here is a patch for both openssl and gnutls. Please comment, I'll push it
> > > tomorrow.
> > 
> > The bug report says the SNI field should be different than the Host: header,
> > but I question the sensibility in that. What would be the point? (pun not
> > intended =B))
> > 
> > When requesting contents from an HTTPS site, the SNI field will tell the
> > server which particular virtual server to get the data from and when the
> > trailing dot gets stripped the two strings with and without dot will end up
> > on the same virtual server. Sending a Host: header that doesn't match the
> > virtual server name then is then likely to either get ignored or to cause
> > the HTTP backend to complain.
> > 
> > It will also make it behave a bit different for HTTP than for HTTPS since
> > then there's no SNI field and the Host: header is what will be used and
> > then they clearly are different servers.
> > 
> > And incidentally, curl strips the trailing dot off from both SNI and Host:
> > =)
> 
> That is what I would like to do as well. It seems consistent. And the patch 
> introduces non-elegant code (not really my favor).
> 
> And for DNS lookups... is there a difference between dot and not-dot (e.g. 
> example.com vs. example.com.) ?
> 
> The patch follows Yst Dawson's conclusion, though:
> "That means that the SNI host name and HTTP Host header do not always match.
> The SNI host name must never have a trailing dot, but the HTTP Host header
> must reflect a host name that is identical to the host name of the URI, so if
> the URI's host has a trailing dot, the HTTP Host header must include that
> trailing dot."
> 
> Also what Jay Satiro says:
> "I tried this in Firefox, Chrome and IE and all send the trailing dot for 
> SNI."
> 
> Should we follow the browsers or curl ?
> 
> Tim
> 

-- 
My PGP key ID is 0xE7464A03 and my fingerprint is
D135 B061 DBED 690B 479F E2E3 7D83 E1E5 E746 4A03
I encrypt if I have your key, I sign on request. 
I only accept signing requests on encrypted mail.


-- 
My PGP key ID is 0xE7464A03 and my fingerprint is
D135 B061 DBED 690B 479F E2E3 7D83 E1E5 E746 4A03
I encrypt if I have your key, I sign on request. 
I only accept signing requests on encrypted mail.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]