[squid-users] RFC2616 headers in bumped requests

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/11/2014 11:51 p.m., Steve Hill wrote:
> On 17/11/14 22:05, Amos Jeffries wrote:
> 
>> Would you mind running an experiment for me?
>> 
>> To see what happens if Squid delivers either of these Via
>> headers instead of its current output:
>> 
>> Via: HTTPS/1.1 iceni2.opendium.net (squid/3.4.9)
> 
> The HTTPS/1.1 one appears to work correctly.
> 
>> Via: TLS/1.2 iceni2.opendium.net (squid/3.4.9)
> 
> The web server produces the same broken redirect as before when I
> send TLS/1.2.
> 
>> Setting it with request_header_access/replace should do.
> 
> I've tested this in Squid with request_header_access/replace and 
> confirmed with openssl's s_client directly.
> 


Just to followup, there will not be a permanent change made to Squid
because:

1) "HTTPS" is a common name for an entire stack of protocols. Since it
is a whole stack of protocols (HTTP-on-TLS-on-TCP-on-IP...) it is not
being registered by IANA as a label for an individual protocol.

2) the Via headers indicates the single top-level protocol. Which is
actually HTTP for both port 80 and 443 traffic, even though port 443
is HTTP being transmitted over TLS connections. Thus Squid Via header
is correct.


The ATS server has at least three bugs;

A) it is emitting some unknown "http/1.1" protocol. The "HTTP"
protocol label is case-sensitive as defined in RFC 7230.

B) it is attempting to determine security from the Via header. As the
server operators themselves should know (due to the "http/1.1" usage
by their own server) the presence of any top-level HTTP is no
indicator for or against security of the underlying network connection.

C) it is redirecting to the same https:// URI which is being delivered
to it. The server itself is uniquely in a position to be aware of
these types of loop and so expected not to cause them. (Squid opening
a port 443 connection is dead giveaway they are getting https:// even
if it is proxied).


PS. that said, the workaround should be enough to get things going
again until the ATS people fix their bugs.

Cheers
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUesnsAAoJELJo5wb/XPRj5RYIAIzYJF0nbjG24jR3i73rVQSl
BUcUdwsfwo/KFDSDmqHBlgiN5qcxAt2pZcKzmyGevqmY+nwUQSBUwCvigWXh5tT1
vhrjAB4iuJfFefQqHac4ZtflVID5ft4hSLcwfxdlRwcld5XvNubU5L4bBLNkOuja
1JAezYn+EJtonhQsC7ZxecWPiDCMo/sUgtDjWjoYu3Awtn/A0mNQpzmPfsUyQyjI
c/2hwTZFPcPruwleZ6kB4/XXcfSRCKVpdI/U/nuPeoEXraO+n6ZhU6Y+6LfaHO26
osmgBf3DM2NirHSI67Ewgk9++JeFAd0v0MASFdzlH97da5SxIGy8yva1bl38Ii0=
=6EbN
-----END PGP SIGNATURE-----