For those looking into this topic, I was able to make it work on 3.5. The trick is to have "ssl_bump splice all". My upstream proxy is 10.1.7.7:3128. This is all in Ubuntu 16.04 - however the squid package was rebuilt due to lack of --with-openssl and --enable-ssl (there are several guides on the internet on how to rebuild a package, I used this one <https://docs.diladele.com/administrator_guide_4_0/system_configuration/https_filtering/recompile_squid.html> as reference, there are also third-party .debs if you trust them).
* squid.conf: ----------------------- acl localhost src 127.0.0.0/8 acl localnet src 192.168.100.0/24 192.168.101.0/24 172.16.0.0/12 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 443 # https acl CONNECT method CONNECT http_access allow localhost localnet http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access deny all http_port 3128 accel vhost allow-direct ssl_bump splice all https_port 3129 ssl-bump intercept cert=/etc/squid/ssl_cert/myca.pem cache_peer 10.1.7.7 parent 3128 0 no-query no-digest never_direct allow all shutdown_lifetime 2 seconds * iptables (PRE-ROUTING required if you're using e.g. docker - your containers will also not need proxy config): ----------------------- iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 3129 iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3128 iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner proxy --dport 80 -j REDIRECT --to-port 3128 iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner proxy --dport 443 -j REDIRECT --to-port 3129 Cheers On Tue, Jun 13, 2017 at 9:35 AM, Madonna, A. (spir-it) < a.mado...@rechtspraak.nl> wrote: > Hello Jeryl, > > If you look on the mailing list we and many before us have this problem. > > Client ----> Squid proxy ----> Parent proxy ----> Internets (http / HTTPS) > > As already stated by 1 of the developers before, the code simply does not > exist to handle this. cache_peer can't do a "HTTP CONNECT", simulating the > first client connection with a parent proxy. > > This has been so for at least the last 5+ years. > > We are now looking into a solution where we put something between the > squid and the parent proxy which can provide a "HTTP CONNECT" in > combination with ssl_bump preserving the original SNI(server name > indication). > > Client ----> Squid proxy ----> "HTTP CONNECT" solution---->Parent proxy > ----> Internets (http / HTTPS) > > Kind regards, > > > > -----Oorspronkelijk bericht----- > Van: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] > Namens Amos Jeffries > Verzonden: dinsdag 13 juni 2017 5:41 > Aan: squid-users@lists.squid-cache.org > Onderwerp: Re: [squid-users] client-->iptables-->squid- > proxy->another-proxy > > On 13/06/17 08:33, JerylCook wrote: > > I've been stuck on this for a few days :P... > > > > I 'thought' I had a fairly good understanding of squid + ssl_bump > > but not so sure. > > > > In a nutshell i am having an issue linking a second proxy server via > > cache_peer. > > > > we have 2 boxes. > > > > *Configuration:* > > 1 box, has iptables configured to send all outbound traffic to > > 10.0.0.1:8999 which is the second box's squid server and port(8999) > > > > 2nd box, has squid running on 8999, we have another server running on > 8998. > > both proxy servers are using the same 'CA'. > > > > https 10.0.0.1:8999 transparent ssl-bump generate-host-certificates=on. > .... > > > > cache_peer 10.0.0.1:8998 8998 0 ssl default no-query no-digest > > sslflags=DONT_VERIFY_PEER.... > > > > use-case: > > wget https://facebook.com --ca-cert=/dat/sharedCa.cer , on box 1 > > through iptables.. > > 1. squid on box 2 generates and signs a certificate with > > CN=facebook.com for the client > > That sounds a little suspicious to me. FB have a more complicated CN in > their real certs. You omitted your ssl_bump rules, so the type of bumping > and details available are unknown - but I suspect they may not be doing > what you expect in that case. > > > 2. client trusts the CA and cert. > > Which if the three CA involved? they need to trust the one being used by > the frontend Squid cert generator. > Only frontend Squid needs to trust the backend peer CA. And likewise, > only the backend peer needs to trust the origin CA. > > > 3.we want squid to send this proxied https request to the second proxy > > server on :8998. this proxy server is set to generate impersonation > > certs as well using the same rootCAKey that squid uses... > > This is where the current behaviour is lacking AFAIK. SSL-Bump assumes the > client (frontend Squid) is either sending a CONNECT request to get the > server details from, or that it is working with intercepted TLS rather than > a TLS explicit proxy connection. So the backend behaviour is still very > much just receive a request for https:// URL and do the serve TLS thing - > no mimicing on its client connection (AFAIK). > > > however, we keep getting > > "Failed to establish a secure connection, SQUID_ERR_SSL_HANDSHAKE", > > Handshake with SSL Server failed: error:140770FC:SSL routines > > SSL23_GET_SERVER_HELLO: unknown protocol" > > > > Does squid 3.5.20 support PROXY Protocol in cache_peer if you need to > > link a second proxy? or is my configuration messed up. > > Squid only supports receiving PROXY Protocol on the http_port directive. > Not yet sending to a cache_peer. Though I don't see any relevance to PROXY > Protocol in anything you have described about your configuration. > > If the peer is sending an error back to Squid when it gets TLS instead of > PROXY intro octets that would explain the SSL errors. It also would if the > peer was sending back HTTP messages instead of TLS (HTTPS), which is a more > common problem when the peer is an older Squid. > > > SSL-Bump is supported to cache_peer when the peer connection is a TLS/SSL > connection. Though be aware that the "server" frontend Squid mimics would > then be the backend peer's certificate, not the origin server. > > Also, avoid DONT_VERIFY_PEER, it is really doing more harm than anything > useful. Since this is a peer you know about you should also know its CA in > advance. So use "sslflags=NO_DEFAULT_CA sslcafile=..." and Squid can do all > the security checks just fine regardless of whether its a custom CA or not. > > Amos > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > > ________________________________ > > Informatie van de Raad voor de rechtspraak, de rechtbanken, de > gerechtshoven en de bijzondere colleges vindt u op www.rechtspraak.nl. > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > -- -------- Diogenes S. de Jesus
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
