[squid-dev] Fix for cache_peer forceddomain= in CONNECT case

Amos Jeffries squid3 at treenet.co.nz
Mon Nov 9 21:39:20 UTC 2015


On 10/11/2015 1:18 a.m., aymericvincent wrote:
> 
> Hi,
> 
> while looking around for the impact of the auth-no-keytab patch, I
> stumbled upon a missing copy of peer_domain in src/tunnel.cc and I
> can confirm that the Host: line is not forced if I query a document
> through a https URL whereas it is forced if I query the same document
> through a http URL.
> 
> Could you please review the implications of this patch and commit it?
> I'm not using the feature.

Thank you.

I found two places in the trunk tunnel code where peer_login is being
set and it looks like the domain should be too. One in
tunnelConnectDone, the other in switchToTunnel. I have applied the same
change to both places in trunk rev.14392.


Since you ask, the implications are potentially nasty but only in the
rare case that the recipient pays any attention at all to Host on these
messages.
With the domain in the authority-URI the Host header on a CONNECT
request is meaningless - and its so widely abused with garbage values
that if there is a sane proxy at the other end it will just ignore the
header.


> 
> Might it explain the problem described at
> http://stackoverflow.com/questions/26548298/squid3-reverse-ssl-proxy-squid-x509-v-err-domain-mismatch-error
> ?
> 

Possibly. It gets complicated with two distinct domains in the CONNECT
message, SNI values from-client and to-server, three domain fields in
the X.509 certificate each containing whole lists of domains, and both
OpenSSL validator and Squid helper potentially involved - plus
implementation bugs. So I'm quite hesitant to give an opinion about that
old Squid version.


PS. can you please prefix your subject lines with "[PATCH]" in future
when you include a patch. Thank you.

Amos


More information about the squid-dev mailing list