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 as reference, there are also third-party .debs if you trust them).
* squid.conf:
-----------------------
acl localhost src 127.0.0.0/8
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@xxxxxxxxxxxxxx> 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@lists.squid-cache.org ] Namens Amos Jeffries
Verzonden: dinsdag 13 juni 2017 5:41
Aan: squid-users@lists.squid-cache.org
Onderwerp: Re: 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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
