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