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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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
