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

[Amos Jeffries]

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