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

Also
Will "tranparent" work on https_port? The bowser makes a connection of
443 which i redirect to squid. So will it let the webpages open? They
are not opening for me

-talha

On Thu, Apr 12, 2012 at 11:08 AM, Ahmed Talha Khan <auny87_at_gmail.com> wrote:
> 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

-- 
Regards,
-Ahmed Talha Khan