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

Hey Amos,

Thanks for the detailed answer. This means that if the browser doesnot
know about the proxy it will try to create an ssl connection with the
origin server(end-point) and not use the CONNECT method(because it is
not proxy aware). Since squid is just sitting in the middle and it
doesnot know about the connection it will not be able to unwrap the
TLS layer of that connection? Correct me if i am wrong. Which mean
transparent + ssl_bump will not work if the connections are being made
of port 80 simple ssl without CONNECT.?

Actually the confusion arises as some people have mentioned that it
bumps ssl(without CONNECT) even in transparent mode. eg
http://dvas0004.wordpress.com/2011/03/22/squid-transparent-ssl-interception/

One more thing is that if i remove the ssl_bump option and only use
the transparent mode, the https webpages should work? Should squid be
able to proxy them? What about the looping error in the browser?

-talha

On Thu, Apr 12, 2012 at 5:28 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> 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
>

-- 
Regards,
-Ahmed Talha Khan