client-->iptables-->squid-proxy->another-proxy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

client-->iptables-->squid-proxy->another-proxy

JerylCook
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
2. client trusts the CA and cert.
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...

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.
Reply | Threaded
Open this post in threaded view
|

Re: client-->iptables-->squid-proxy->another-proxy

Amos Jeffries
Administrator
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: client-->iptables-->squid-proxy->another-proxy

Madonna, A. (spir-it)
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:[hidden email]] Namens Amos Jeffries
Verzonden: dinsdag 13 juni 2017 5:41
Aan: [hidden email]
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
[hidden email]
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: client-->iptables-->squid-proxy->another-proxy

Diogenes S. Jesus
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) <[hidden email]> 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:[hidden email]] Namens Amos Jeffries
Verzonden: dinsdag 13 juni 2017 5:41
Aan: [hidden email]
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
[hidden email]
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users



--

--------

Diogenes S. de Jesus

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: client-->iptables-->squid-proxy->another-proxy

Amos Jeffries
Administrator
On 20/08/17 14:38, Diogenes S. Jesus wrote:>

> * squid.conf:
> -----------------------
> acl localhost src 127.0.0.0/8 <http://127.0.0.0/8>
> acl localnet src 192.168.100.0/24 <http://192.168.100.0/24>
> 192.168.101.0/24 <http://192.168.101.0/24> 172.16.0.0/12
> <http://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
>

Those http_access rules contain an impossible condition.

The src-IP cannot simultaneously be having a value in the 127/8 network
range *and* in one of the RFC1918 ranges. So there is no way anything is
ever allowed to use this proxy.

I suspect it was working due to a recently fixed bug where the CONNECT
message was not consistently passed through http_access controls
sometimes in the first SSL-Bump step. Do not expect that to work much
longer.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: client-->iptables-->squid-proxy->another-proxy

Diogenes S. Jesus
Hi Amos. Thanks for pointing it out - but this has never been an acl-related issue, more like a https_port / ssl-bump configuration question when the upstream ssl request was not sending a "CONNECT www.example.org:443" but a "GET htttps://www.example.org".

For the sake of testing one can simply get rid of the acls and set "allow all", it wouldn't matter - this line "ssl_bump splice all" is the answer most people were looking for I supposed. 

Best regards.



On Sun, Aug 20, 2017 at 10:31 AM, Amos Jeffries <[hidden email]> wrote:
On 20/08/17 14:38, Diogenes S. Jesus wrote:>
* squid.conf:
-----------------------
acl localhost src 127.0.0.0/8 <http://127.0.0.0/8>
acl localnet src 192.168.100.0/24 <http://192.168.100.0/24> 192.168.101.0/24 <http://192.168.101.0/24> 172.16.0.0/12 <http://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


Those http_access rules contain an impossible condition.

The src-IP cannot simultaneously be having a value in the 127/8 network range *and* in one of the RFC1918 ranges. So there is no way anything is ever allowed to use this proxy.

I suspect it was working due to a recently fixed bug where the CONNECT message was not consistently passed through http_access controls sometimes in the first SSL-Bump step. Do not expect that to work much longer.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users



--

--------

Diogenes S. de Jesus

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: client-->iptables-->squid-proxy->another-proxy

Amos Jeffries
Administrator
On 21/08/17 09:53, Diogenes S. Jesus wrote:
> Hi Amos. Thanks for pointing it out - but this has never been an
> acl-related issue, more like a https_port / ssl-bump configuration
> question when the upstream ssl request was not sending a "CONNECT
> www.example.org:443 <http://www.example.org:443>" but a "GET
> htttps://www.example.org <http://www.example.org>".
>

There are a couple of things wrong with that.

Firstly, port 443 traffic does not validly contain "GET https://..."
requests. It should only contain origin-form requests same as port 80.
The 'https' part is generated by Squid from the fact those requests are
received by an https_port and thus must have been wrapped by TLS/SSL for
the HTTP portion to become handled by Squid.


Secondly, Squid internally generates synthetic/fake CONNECT messages to
represent the intercepted traffic on an https_port. Simulating HTTPS
sent through a forward/explicit proxy. At step1 that is done with the
TCP SYN packet details, at step2 with the client TLS SNI details.
  Splice simply tells bumping not to decrypt any CONNECT message,
including those synthetic ones. The Squid-generated CONNECT is then
caused to be sent upstream to the peer by not being unwrapped/decrypted.
This type of generated CONNECT is implemented any nobody having trouble
with it that I'm aware of.


Thirdly, What is being asked for by JerlyCook and others is some form of
filtering to be done at the front-end proxy for https:// traffic before
it gets sent to the parent/sibling proxy. So splicing is not always a
viable choice for those use-cases even if it is technically the best and
safest thing to do.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users