[squid-users] SSL Bump Failures with Google and Wikipedia [SOLVED]

[Jeffrey Merkey]

On 10/4/17, Alex Rousskov <rousskov at measurement-factory.com> wrote:
> On 09/30/2017 11:14 PM, Jeffrey Merkey wrote:
>>> After reviewing this problem and all of the great technical
>>> information folks provided, I have it working and I figured out the
>>> best way to deal with this transparently allowing squid to remotely
>>> spoof the server side with modified request headers.
>
> Overall, the above is _not_ the best way to deal with the encoding
> problem. The overall best way is for your eCAP or ICAP service to decode
> virgin and encode adapted message bodies as needed. That way, your Squid
> does not mangle client requests to lie about accepted encodings and your
> service can handle cases where the origin server sends encoded messages
> regardless of the request Accept headers.
>
> Alex.
>
Hi Alex,

great minds think alike.  I came to the same conclusion about using
that request header hackery and I have almost completed a c-icap
service called "inflate" that ungzip's the data as part of an icap
service chain.  I already have incorporated gzip and deflate libs into
the icap service , and I am now integrating brotli as well.  The
service is not fully completed but will be finished sometime this
week.

The code is stored as a branch at:

https://github.com/jeffmerkey/icap/tree/inflate

I will say this, the hack I discussed in the above thread with sending
altered request headers for "accept-encoding:*;p=0" does seem to work
in terms of spoofing remote servers into not sending compressed data,
but I also noticed that not all servers on the internet respond to it
correctly, and some web servers ignore it and send compressed gzip
data anyway.

I will post to the icap list a patch series which contains this
"inflate" service module.

Jeff