On 22/06/2012 4:34 a.m., A G wrote:
Hi
I am trying to set up squid as a transparent ssl mitm proxy. The
users behind the proxy understand they have no expectation of privacy.
Also each computer behind the proxy has trusted the organisation
certificate.
After several days of research, what I would like to know is:
1. http_port intercept means squid will place its own ip in the packet sent to the destination. Is this correct?
2. http_port tproxy means squid will preserve the client's ip in the packet sent to the destination, is this correct?
3.
Does ssl bump work only with CONNECT messages?
Erm, "ssl-bump" the option only does that yes. Squid which contain "SSL
Bump" the feature do a little more due to the SSL design changes the
ssl-bump option required.
ie clients must have
their browser set to use squid as a proxy.
No. Intercepted traffic which was destined to another proxy will contain
CONNECT requests which ssl-bump can decrypt. This is rare, but some
people intercept any port they see HTTP flowing over.
But
http://wiki.squid-cache.org/Features/SslBump also says it can mitm
transparently redirected SSL traffic. So ssl bump works in
'transparent/intercept' mode; I have seen many guides such as
http://blog.davidvassallo.me/2011/03/22/squid-transparent-ssl-interception/
combining ssl bump with transparent/intercept.
They are based on the wiki texts. The "s" on https_port is doing the
decryption on the TLS connection, there is nothing for ssl-bump to do
once that has happened.
Squid has always accepted TLS traffic in https_port, even intercepted
traffic. At its core ssl-bump is just a more efficient way of
intercepting CONNECT. With older Squid one needed to re-intercept the
CONNECT tunnel setup back to an https_port on Squid where the TLS
termination happened.
4. What is the
point of using http_port (xyz) ssl-bump if port xyz cannot receive ssl
traffic? Wouldn't ssl-bump ONLY be used with https_port, not http_port?
CONNECT request is a non-TLS traffic request to begin accepting TLS traffic.
On the contrary. https_port receiving code is designed to terminate TLS
connections with a TLS handshake on setup and will do so without any
special ssl-bump option. http_port is only designed to accept
clear-text HTTP and ssl-bump triggers Squid to perform TLS handshake on
an existing connection when CONNECT request turns the connection into a
TLS channel.
5.
After all this, is it possible to use tproxy with ssl-bump? That is, do
SSL man in the middle whilst preserving the client's IP address? The
clients have all trusted the organisation CA that will be used by Squid.
I know of no reason why not. The TLS is just "stuff" sent over the
outbound connection same for TPROXY as any other TCP connection. The
problem will be whether the sslproxy_* directives outbound certificates
are built with Squid IP or rDNS hostname. Which of course will
contradict any TPROXY spoofed IP.
http://squid-web-proxy-cache.1019090.n4.nabble.com/about-https-support-for-transparent-proxy-td1048478.html
says it can't, but this message was from three years ago.
That thread is about taking the TPROXY functionality and extending the
end-to-end transparency up into Squid at the HTTP layer. This is a
meaning of "transparent proxy" which is very different from NAT
interception many people use the term for. Proper transparency is how
SOCKS operates.
If anyone ends up completing Mikos work Squid will be able to receive
traffic from any port suspected of being HTTP and let non-HTTP traffic
through without interference. Today if you intercept a port used for two
protocols into Squid all the non-HTTP traffic will get errors.
All of
the examples I have seen use intercept with ssl-bump, not with tproxy.
Or are there other options (squid or otherwise) which will allow
transparent/tproxy ssl proxying?
I think that comes doen to familiarity and age, NAT interception is the
older technology a lot of people are familiar with and using already;
TPROXY is harder and still new to a lot of people. They are just
alternative methods of locating the client connection IP:port details so
in theory they should be interchangeable with regard to the Squid config
settings and other Squid features. If you find they are not it is very
likely a bug we need to get fixed.
Amos
