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
