[squid-users] RFC2616 headers in bumped requests

[Amos Jeffries]

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

On 4/11/2014 11:17 p.m., Steve Hill wrote:
> 
> Squid (correctly) inserts Via and X-Forwarded-For headers into
> requests that it is proxying.  However, in the case of encrypted
> traffic, the server and client are expecting the traffic to reach
> the other end as-is, since usually this could not be intercepted.
> With SSL bumped requests this is no longer true - the proxy can
> (and does) modify the traffic, by inserting these headers.
> 
> So I'm asking the question: is this behavior considered desirable,
> or should we be attempting to modify the request as little as
> possible for compatibility reasons?

It is desirable. More so for intercepted SSL traffic than for regular
HTTP traffic. These headers convey the important information about the
path the traffic took to reach each endpoint. Only with full
information can the endpoints accurately assign security trust/context
on the message.

> 
> I've just come across a web server that throws its toys out of the
> pram when it sees a Via header in an HTTPS request, and
> unfortunately it's quite a big one - Yahoo.  See this request:
> 
> ----- GET /news/degrees-lead-best-paid-careers-141513989.html
> HTTP/1.1 Host: uk.finance.yahoo.com Via: 1.1
> 

That is unfortunately an invalid HTTP Via header. It is mandatory to
contain the host field even if it contains a host alias for the real
FQDN. If that is what is actually being transfered the server is right
in complaining.


> HTTP/1.1 301 Moved Permanently Date: Tue, 04 Nov 2014 09:55:40 GMT 
> Via: http/1.1 yts212.global.media.ir2.yahoo.com
> (ApacheTrafficServer [c s f ]), http/1.1 r04.ycpi.ams.yahoo.net
> (ApacheTrafficServer [cMsSfW])

As you can see here the upstream server itself is inserting Via
headers to HTTPS traffic due to a CDN at the server end.

It is reporting that the HTTPS request is being sent unencrypted over
their portion of the network. Not terrible if we assume its their
internal LAN or VPN network, but it cearly demonstrates how realistic
is that end-to-end encryption assumption you say the client and server
have.


> Server: ATS Strict-Transport-Security: max-age=172800 Location: 
> https://uk.finance.yahoo.com/news/degrees-lead-best-paid-careers-141513989.html
>
> 
Content-Length: 0
> Age: 0 Connection: keep-alive -----
> 
> Compare to:
> 
> ----- GET /news/degrees-lead-best-paid-careers-141513989.html
> HTTP/1.1 Host: uk.finance.yahoo.com
> 
> HTTP/1.1 200 OK ... -----
> 
> 
> Note that the 301 that they return when a Via header is present
> just points back at the same URI, so the client never gets the
> object it requested.
> 
> For now I have worked around it with: request_header_access Via
> deny https request_header_access X-Forwarded-For deny https But it
> does make me wonder if inserting the headers into bumped traffic is
> a sensible thing to do.
> 

If you can please chek that Via header being emitted by your Squid
when things break. And also whether your Squid is contacting their
server on an HTTPS or HTTP port.
 If your Squid is contacting their HTTP port for un-encrypted traffic
this redirect is competely expected.

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

iQEcBAEBAgAGBQJUWNvPAAoJELJo5wb/XPRjmsoH/3d9CswaasIZRKlEuu1dQ0a2
/KFZmxhKJDHKYT4yQva+l0og6/FwhFdaUNr0s6xhVfyfUG/fRX2KALCElXl9Bbbe
y3qKrFVSGBJXdXZ/Pysv5ZixKBGBXeiHF4akGZZpK3zexgUjb/+NYg5CrDVi7omi
NbbZE/cTmYa2ZlrlG0F0v5hxlIhjTmyhxJNBR5PWKHWCkYZMnc4cynjrCnNzSmnX
LuY1pFSE9SCRovE3kUgZRB5tDfdk7bNOLfjMHBW1B9p/INRrmnTTVxhxKmPadzWn
9I0IOlusNSYrgYE9mQCp+TYQhVhDRuTN9LubIuuYsC5mHmSdW2WMUs0ExkyOhOM=
=lJ19
-----END PGP SIGNATURE-----