Re: [squid-users] Using squid as transparent proxy causes problem with pages on https

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 12 Apr 2012 12:28:10 +1200

On 12.04.2012 06:16, Ahmed Talha Khan wrote:
> Hey Amos,
>
> I am not talking about the port 443 https. lets talk about port 80
> ssl/http. I have configured the ip-tables correctly to re-direct my
> traffic to squid.Now how will the ssl_bump feature behave when
> configured as transparent. For me it was not working and is the
> problem.

Fine. CONNECT is a client->proxy request method, used on port 3128
(http-proxy service). They should never exist on port-80 (http-server
service). So there is nothing for ssl-bump to do there either.

ssl-bump feature simply unwraps a CONNECT request internal TLS layer.
Which limits its usefulness to traffic situations where CONNECT exist:

  * when the browser is aware of and sending traffic to the proxy of its
own choice...
    via regular TCP: http_port + ssl-bump
    via TLS tunnel: https_port + ssl-bump

  * when the intercepted traffic was destined to another proxy
(intercepted port 3128 traffic etc)
    via regular TCP: http_port + intercept + ssl-bump
    via TLS tunnel: https_port + intercept + ssl-bump

  * some various edge case like when you intercept a client who is
violating HTTP with invalid CONNECT requests on port 80, or to a proxy
configured on the port.

I think the confusing thing seems to be that ssl-bump is a *valid*
option on both port types and both intercept and forward modes. So we
can't provide helpful "invalid parameter" messages from -k parse to make
the usage cases clearer.

It is identical in external behaviour to the old config hack of
URL-rewriting CONNECT endpoint IP:port URI back to a local Squid
https_port. Just far more efficient.

Amos
Received on Thu Apr 12 2012 - 00:28:13 MDT

This archive was generated by hypermail 2.2.0 : Thu Apr 12 2012 - 12:00:03 MDT