-----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----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
