[squid-users] client-->iptables-->squid-proxy->another-proxy

Sun Aug 20 02:38:23 UTC 2017

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.Madonna at 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-bounces at lists.squid-cache.org]
> Namens Amos Jeffries
> Verzonden: dinsdag 13 juni 2017 5:41
> Aan: squid-users at 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 at 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>

-- 

--------

Diogenes S. de Jesus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170820/4a166727/attachment-0001.html>