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
