Search squid archive
Re: [squid-users] Capabilities of Squid as SSL MITM
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.htmlsays 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.
[Linux Audio Users] [Photo] [Yosemite News] [Samba] [Video Projectors] [Video Devices] [Big List of Linux Books] [LCD TVs] [Webcams] [Linux USB]