Connection to cache peer failed "SSL Transparent proxy'

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

Connection to cache peer failed "SSL Transparent proxy'

Walid A. Shaari
Hello,

I have a squid proxy, trying to configure it to enforce traffic from a private cloud appliance (Azure Stack) to go over to the corporate proxy. traffic is mostly https, I see the below errors, note that ParentProxy-22 is the parent proxy listening on port 9090.  also, why in the access logs I have some entries not going to parent proxy   (e.g. 1549282865.527 13 192.168.3.10 NONE/200 0 CONNECT 52.138.216.83:443 - HIER_NONE/- -)

### error logs ### Feb 4 15:26:38 azproxy squid[192272]: TCP connection to ParentProxy-22/9090 failed 
Feb 4 15:26:38 azproxy squid[192272]: Error parsing SSL Server Hello Message on FD 20 
Feb 4 15:26:38 azproxy squid[192272]: ERROR: negotiating TLS on FD 20: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (1/-1/0) 
Feb 4 15:26:38 azproxy squid[192272]: TCP connection to ParentProxy-22/9090 failed 
Feb 4 15:26:38 azproxy squid[192272]: Detected DEAD Parent: ParentProxy-22 
Feb 4 15:26:38 azproxy squid[192272]: Detected REVIVED Parent: ParentProxy-22 
Feb 4 15:26:38 azproxy squid[192272]: Error parsing SSL Server Hello Message on FD 24 
Feb 4 15:26:38 azproxy squid[192272]: ERROR: negotiating TLS on FD 24: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (1/-1/0) 
Feb 4 15:26:38 azproxy squid[192272]: TCP connection to ParentProxy-22/9090 failed
The squid configuration is as follows:

### iptables setup ### [root@ azproxy ~] $ iptables -L -t nat -n -v Chain PREROUTING (policy ACCEPT 6089 packets, 376K bytes) pkts bytes target prot opt in out source destination 5029 261K REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 8080
 21742 1130K REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 8090 ### squid.conf ## dns_v4_first on

cache_peer ParentProxy-22 parent 9090 0 no-query sslcapath=/etc/pki/ca-trust/source/anchors/
acl local-network dstdomain .azcompany.com
acl everything src 10.0.0.0/8
http_access allow everything
never_direct deny local-network
never_direct allow all
http_port 8080 intercept
https_port 8090 intercept ssl-bump generate-host-certificates=on cert=/etc/squid/ssl_certs/azproxyCA.pem dynamic_cert_mem_cache_size=16MB #connection-auth=off
http_port 8100             #forward port not used.

sslcrtd_program /usr/lib64/squid/security_file_certgen -s /var/spool/squid/ssl_db -M 4MB
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
tls_outgoing_options /etc/pki/ca-trust/source/anchors/ca.crt
debug_options ALL,9### excerpts from access log ### 1549282836.118 44 192.168.3.11 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -:
1549282836.150 14 192.168.3.11 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282836.271 38 192.168.3.11 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282836.300 13 192.168.3.11 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282837.661 30 192.168.3.11 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282837.710 19 192.168.3.11 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282837.797 4 192.168.3.11 NONE/200 0 CONNECT 23.50.187.199:443 - HIER_NONE/- -1549282837.856 42 192.168.3.11 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282840.277 15 192.168.3.7 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282840.300 17 192.168.3.7 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282848.695 19 192.168.3.17 TCP_MISS/200 2283 GET http://ocsp.aramco.com.sa/ocsp/MFQwUjBQME4wTDAJBgUrDgMCGgUABBTcIwl9uZE4WwaD1jq3IdqcP3CI0wQUBCvyP4WY3ATuQXNOru2Zj%2B6W%2BfcCExkAABWDWqKqrUfWBR8AAAAAFYM%3D - ORIGINAL_DST/10.1.152.115 application/ocsp-response
1549282853.233 17 192.168.3.10 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -

1549282853.266 14 192.168.3.10 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282853.299 17 192.168.3.10 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282853.329 14 192.168.3.10 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282865.527 13 192.168.3.10 NONE/200 0 CONNECT 52.138.216.83:443 - HIER_NONE/- -
1549282865.552 13 192.168.3.10 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab? -FIRSTUP_PARENT/ParentProxy-22 text/html 
1549282865.615 57 192.168.3.10 TCP_MISS/503 4689 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab? -FIRSTUP_PARENT/ParentProxy-22 text/html 
1549282875.690 38 192.168.3.17 TCP_MISS/503 4707 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab? -FIRSTUP_PARENT/ParentProxy-22 text/html 
1549282875.711 14 192.168.3.17 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282876.012 28 10.8.101.53 NONE/200 0 CONNECT 111.221.29.254:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282880.455 18 192.168.3.10 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282880.544 42 192.168.3.10 TCP_MISS_ABORTED/500 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab? - HIER_NONE/- text/html
1549282880.614 17 192.168.3.10 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282880.644 13 192.168.3.10 NONE/200 0 CONNECT 23.50.187.199:443 - FIRSTUP_PARENT/ParentProxy-22 -
1549282880.995 22 192.168.3.4 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282881.026 25 192.168.3.4 TCP_MISS_ABORTED/503 4272 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
1549282882.164 19 192.168.3.17 TCP_MISS/503 4689 GET http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab? - FIRSTUP_PARENT/ParentProxy-22 text/html
==== squid version and build ===
[root@azproxy ~] $ squid -v
Squid Cache: Version 4.5
Service Name: squid

This binary uses OpenSSL 1.0.2k-fips 26 Jan 2017. For legal restrictions on distribution see https://www.openssl.org/source/license.html configure options: '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid.pid' '--disable-dependency-tracking' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,getpwnam,fake' '--enable-auth-ntlm=fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos,wrapper' '--enable-external-acl-helpers=wbinfo_group,kerberos_ldap_group,LDAP_group,delayer,file_userip,SQL_session,unix_group,session,time_quota' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-icap-client' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-storeio=aufs,diskd,ufs,rock' '--enable-wccpv2' '--enable-esi' '--enable-security-cert-generators' '--enable-security-cert-validators' '--enable-icmp' '--with-aio' '--with-default-user=squid' '--with-filedescriptors=16384' '--with-dl' '--with-openssl' '--enable-ssl-crtd' '--with-pthreads' '--with-included-ltdl' '--disable-arch-native' '--without-nettle' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' --enable-ltdl-convenience


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

Re: Connection to cache peer failed "SSL Transparent proxy'

Amos Jeffries
Administrator
[ Rules horribly mangled by sending a web page to a plain-text mailing
list. I have fixed some where I replied, but not all. ]


On 5/02/19 4:07 am, Walid A. Shaari wrote:
> Hello,
>
> I have a squid proxy, trying to configure it to enforce traffic from a
> private cloud appliance (Azure Stack) to go over to the corporate proxy.
> traffic is mostly https, I see the below errors, note
> that ParentProxy-22 is the parent proxy listening on port 9090.



>  also,
> why in the access logs I have some entries not going to parent proxy 
>  (e.g. 1549282865.527 13 192.168.3.10 NONE/200 0
> CONNECT 52.138.216.83:443 <http://52.138.216.83:443/> - HIER_NONE/- -)
>

Some transactions do not need server contact. The above "CONNECT" with
raw-IP:port, "NONE" status type, "NONE" peer type and 0 byte size is
what gets logged for the SSL-Bump step-1 interaction when only a TCP SYN
packet has actually happened.

NP: Each step of SSL-Bump process has a separate log entry with
incrementally more data up to the one with a 'final' result which
instead logs the decrypted transactions or the error.


> ### error logs ###Feb 4 15:26:38 azproxy squid[192272]: TCP connection
> to ParentProxy-22/9090 failed 
> Feb 4 15:26:38 azproxy squid[192272]: Error parsing SSL Server Hello
> Message on FD 20 
> Feb 4 15:26:38 azproxy squid[192272]: ERROR: negotiating TLS on FD 20:
> error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
> (1/-1/0)

The OpenSSL library on your proxy machine does not understand the
protocol that it is receiving in the supposedly TLS / HTTPS traffic.

Usually seeing this on peer connections means the peer is *not* a TLS
explicit proxy, nor HTTPS / TLS origin server. Such things respond in
their actual protocol with an error -> OpenSSL displays that message.


...>
> cache_peer ParentProxy-22 parent 9090 0 no-query
> sslcapath=/etc/pki/ca-trust/source/anchors/

Two things of note:

1) as above, does this peer *actually* support TLS connections on its
port 9090?
 Native TLS connections, not HTTP Upgrade or anything like that.

2) That sslcapath= is providing an entire set of CA's. Any given server
typically has one certificate, signed by one CA. So it is rare that you
would need an entire set of CA's to be trusted by this proxy.

For better security you should be able to load the specific CA that peer
uses with sslcafile= instead of the whole path.


> acl local-network dstdomain .azcompany.com
> acl everything src 10.0.0.0/8
> http_access allow everything


These are very deceptive.

 * "everything" is actually a small sub-set of 'things'.

 * "local-network" is not necessarily local. Any IP address with
reverse-DNS configured to claim its name is within *.azcompany.com will
match this ACL regardless of where in the world it actually is.


The default squid.conf defines an ACL "localnet" (Local Network) for the
permitted clients subnet.

The ACL called "all" is provided to match every transaction with a
client IP.


> never_direct deny local-network


Fine, but why are you waiting until a place (never_direct) where Squid
is unable to wait for results of reverse-DNS lookup?
 That will result in unpredictable non-match occuring whenever DNS TTL
is encountered.


> never_direct allow all
> http_port 8080 intercept
> https_port 8090 intercept ssl-bump generate-host-certificates=on
> cert=/etc/squid/ssl_certs/azproxyCA.pem dynamic_cert_mem_cache_size=16MB
> #connection-auth=off
> http_port 8100             #forward port not used.
>
> sslcrtd_program /usr/lib64/squid/security_file_certgen -s
> /var/spool/squid/ssl_db -M 4MB
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump bump all

> tls_outgoing_options /etc/pki/ca-trust/source/anchors/ca.crt

Squid should be telling you on startup that there is no valid option
named "/etc/pki/ca-trust/source/anchors/ca.crt"

 tls_outgoing_options directive takes a set of k=v pairs setting the
options just like http(s)_port and cache_peer.



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

Re: Connection to cache peer failed "SSL Transparent proxy'

Walid A. Shaari

Dear Amos,


Thank you for your time and response. I have changed the configuration to the below. I believe the parent proxy is not using SSL/TLS. I do not see the Hello error message any longer ( I hope).  I have not used your proposed localnet as I just saw your email, at the time being, the ACL is quite open as I am still troubleshooting, will tighten it when I am comfortable with a final config.

- for the 'never direct', are you suggesting I use 'never direct deny localnet'?


by the way, my final goal is to enable https traffic through, not really intercept it, by trial and error and reading the mailing list, that config below is what seems to be working for me right now, can not confirm totally as parent proxy is not under my control, nor is the appliance, however from the access.log and system message logs, things look better than earlier.  what is the best resource to understand the peek and splice, any good places other than squid cache main url?


I did get a couple of new errors, have not worked on them, I might have some clues.


  1- squid[192090]: SECURITY ALERT: Host header forgery detected on local=52.138.216.83:443 remote=192.168.3.4:1384 FD 50 flags=33 (local IP does not match any domain IP)

       I believe this is covered in https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery


   2- temporary disabling (Unauthorized) digest from 192.168.4.22

        wondering if  I should add 'always_direct deny all'  and ' nonhierarchical_direct off'?

####   Anonymous access to parent proxy

#forwarded_for  delete

#request_header_access Surrogate-Capability deny all



dns_v4_first on

cache_peer  192.168.4.22  parent 9090 0 no-query #sslcapath=/etc/pki/ca-trust/source/anchors/  

acl local-network dstdomain .azcompany.com   # tighten after finalizng troubleshooting, maybe replace with localnet

http_access allow all

never_direct deny local-network    # revisit not using DNS for resolution

never_direct allow all    

http_port 8080 intercept    # should I really use intercept in here? can I get away without it

https_port 8090 intercept ssl-bump generate-host-certificates=on  cert=/etc/squid/ssl_certs/bccaz01CA.pem  dynamic_cert_mem_cache_size=16MB #connection-auth=off

http_port 8100    #forward port not used, only for troubleshooting.


sslcrtd_program /usr/lib64/squid/security_file_certgen -s /var/spool/squid/ssl_db -M 4MB


acl step1 at_step SslBump1

acl azure_sites  dstdom_regex microsoft.com azure.com azureedge.net microsoftazurestack.com trafficmanager.net  wdcp.microsoft.com wdcpalt.microsoft.com updates.microsoft.com

acl azure_sites2 dstdom_regex download.microsoft.com msdl.microsoft.com crl.microsoft.com secure.aadcdn.microsoftonline-p.com

ssl_bump peek step1

ssl_bump splice  azure_sites azure_sites2 #Avoid bumping Microsoft/Azure related sites


sslproxy_cert_error allow azure_sites azure_sites2     # is there a better way to handle these and log them?


debug_options  ALL,9


On Tue, 5 Feb 2019 at 09:25, Amos Jeffries <[hidden email]> wrote:
[ Rules horribly mangled by sending a web page to a plain-text mailing
list. I have fixed some where I replied, but not all. ]


On 5/02/19 4:07 am, Walid A. Shaari wrote:
> Hello,
>
> I have a squid proxy, trying to configure it to enforce traffic from a
> private cloud appliance (Azure Stack) to go over to the corporate proxy.
> traffic is mostly https, I see the below errors, note
> that ParentProxy-22 is the parent proxy listening on port 9090.



>  also,
> why in the access logs I have some entries not going to parent proxy 
>  (e.g. 1549282865.527 13 192.168.3.10 NONE/200 0
> CONNECT 52.138.216.83:443 <http://52.138.216.83:443/> - HIER_NONE/- -)
>

Some transactions do not need server contact. The above "CONNECT" with
raw-IP:port, "NONE" status type, "NONE" peer type and 0 byte size is
what gets logged for the SSL-Bump step-1 interaction when only a TCP SYN
packet has actually happened.

NP: Each step of SSL-Bump process has a separate log entry with
incrementally more data up to the one with a 'final' result which
instead logs the decrypted transactions or the error.


> ### error logs ###Feb 4 15:26:38 azproxy squid[192272]: TCP connection
> to ParentProxy-22/9090 failed 
> Feb 4 15:26:38 azproxy squid[192272]: Error parsing SSL Server Hello
> Message on FD 20 
> Feb 4 15:26:38 azproxy squid[192272]: ERROR: negotiating TLS on FD 20:
> error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
> (1/-1/0)

The OpenSSL library on your proxy machine does not understand the
protocol that it is receiving in the supposedly TLS / HTTPS traffic.

Usually seeing this on peer connections means the peer is *not* a TLS
explicit proxy, nor HTTPS / TLS origin server. Such things respond in
their actual protocol with an error -> OpenSSL displays that message.


...>
> cache_peer ParentProxy-22 parent 9090 0 no-query
> sslcapath=/etc/pki/ca-trust/source/anchors/

Two things of note:

1) as above, does this peer *actually* support TLS connections on its
port 9090?
 Native TLS connections, not HTTP Upgrade or anything like that.

2) That sslcapath= is providing an entire set of CA's. Any given server
typically has one certificate, signed by one CA. So it is rare that you
would need an entire set of CA's to be trusted by this proxy.

For better security you should be able to load the specific CA that peer
uses with sslcafile= instead of the whole path.


> acl local-network dstdomain .azcompany.com
> acl everything src 10.0.0.0/8
> http_access allow everything


These are very deceptive.

 * "everything" is actually a small sub-set of 'things'.

 * "local-network" is not necessarily local. Any IP address with
reverse-DNS configured to claim its name is within *.azcompany.com will
match this ACL regardless of where in the world it actually is.


The default squid.conf defines an ACL "localnet" (Local Network) for the
permitted clients subnet.

The ACL called "all" is provided to match every transaction with a
client IP.


> never_direct deny local-network


Fine, but why are you waiting until a place (never_direct) where Squid
is unable to wait for results of reverse-DNS lookup?
 That will result in unpredictable non-match occuring whenever DNS TTL
is encountered.


> never_direct allow all
> http_port 8080 intercept
> https_port 8090 intercept ssl-bump generate-host-certificates=on
> cert=/etc/squid/ssl_certs/azproxyCA.pem dynamic_cert_mem_cache_size=16MB
> #connection-auth=off
> http_port 8100             #forward port not used.
>
> sslcrtd_program /usr/lib64/squid/security_file_certgen -s
> /var/spool/squid/ssl_db -M 4MB
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump bump all

> tls_outgoing_options /etc/pki/ca-trust/source/anchors/ca.crt

Squid should be telling you on startup that there is no valid option
named "/etc/pki/ca-trust/source/anchors/ca.crt"

 tls_outgoing_options directive takes a set of k=v pairs setting the
options just like http(s)_port and cache_peer.



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

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

Re: Connection to cache peer failed "SSL Transparent proxy'

Amos Jeffries
Administrator
On 6/02/19 5:28 am, Walid A. Shaari wrote:

> Dear Amos,
>
>
> Thank you for your time and response. I have changed the configuration
> to the below. I believe the parent proxy is not using SSL/TLS. I do not
> see the Hello error message any longer ( I hope).  I have not used your
> proposed localnet as I just saw your email, at the time being, the ACL
> is quite open as I am still troubleshooting, will tighten it when I am
> comfortable with a final config.
>
> - for the 'never direct', are you suggesting I use 'never direct deny
> localnet'?

There are two ways to resolve the issue there.

1) The most often we recommend is to _also_ use the same ACL in an
earlier security check like http_access so the DNS lookup happens early
and the data is more reliably available when the fast-type check needs it.

or,

2) To use something that does not require remote lookups. IP address
tests etc.


It depends on what your policies are as to which is the better approach
to take. It is looking a bit like (2) is probably the way to go. With
the switch from dstdomain to server_name type for the ssl_bump
processing this issue may just disappear.


>
> by the way, my final goal is to enable https traffic through, not really
> intercept it, by trial and error and reading the mailing list, that
> config below is what seems to be working for me right now, can not
> confirm totally as parent proxy is not under my control, nor is the
> appliance, however from the access.log and system message logs, things
> look better than earlier.  what is the best resource to understand the
> peek and splice, any good places other than squid cache main url?
>

The documentation of what modern Squid SSL-Bump feature does can be
found at <https://wiki.squid-cache.org/Features/SslPeekAndSplice>. It is
community maintained and kept as up to date as we can.

That page links to the relevant squid.conf documentation for the
relevant pieces. The whole TLS situation is a bit volatile so questions
are welcome here if you are unsure about anything in regards to your
specific Squid version, or observe things not matching that text.


>
> I did get a couple of new errors, have not worked on them, I might have
> some clues.
>
>
>   1- squid[192090]: SECURITY ALERT: Host header forgery detected on
> local=52.138.216.83:443
> <http://52.138.216.83:443/> remote=192.168.3.4:1384
> <http://10.8.103.4:1384/> FD 50 flags=33 (local IP does not match any
> domain IP)
>
>        I believe this is covered in
> https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
>

Yes.


>
>    2- temporary disabling (Unauthorized) digest from 192.168.4.22
>
>         wondering if  I should add 'always_direct deny all'  and '
> nonhierarchical_direct off'?
>

To encourage use of the peer when it is possible but not optimal. That
"nonhierarchical_direct off" is the way to go.


But "always_direct deny ..." is a soft negative. It just means don't
*force* things to go direct. So they might still go direct to origin or
via a cache_peer as needed.

"never_direct allow ..." is the directive to force things to go to
cache_peer's or fail. Instead of via DIRECT or ORIGINAL_DST server
connections.

If you try to force things you will run up against the lack of
re-CONNECT features in Squid. That is Squid cannot yet generate CONNECT
tunnels through non-TLS peers like you have.

Given that the intercepted HTTPS traffic must leave Squid over secure
connections that effectively means it cannot use the peer as it normally
would and has to send that traffic via ORIGINAL_DST / DIRECT connections
to the HTTPS server. If those are forbidden the transaction has no
choice but to terminate with an error message.


FWIW: Measurement Factory have an experimental branch adding that
re-CONNECT functionality to Squid, if you are okay running alpha quality
code that may be of interest.
 On the other side, I am working with a client on a configuration that
should result in the needed behaviour for the stable releases. That is
just entering testing and depends on whether they are willing for the
details to be published.


> ####   Anonymous access to parent proxy
>
> #forwarded_for  delete
>
> #request_header_access Surrogate-Capability deny all
>

FYI: the bug behind the S-C header problems is now fixed in v4.5
release. Once you upgrade this can be removed.

>
> dns_v4_first on
>
> cache_peer  192.168.4.22  parent 9090 0 no-query
> #sslcapath=/etc/pki/ca-trust/source/anchors/  
>
> acl local-network dstdomain .azcompany.com  #
> tighten after finalizng troubleshooting, maybe replace with localnet
>
> http_access allow all
>
> never_direct deny local-network    # revisit not using DNS for resolution
>
> never_direct allow all    
>
> http_port 8080 intercept    # should I really use intercept in here? can
> I get away without it
>
> https_port 8090 intercept ssl-bump generate-host-certificates=on 
> cert=/etc/squid/ssl_certs/bccaz01CA.pem 
> dynamic_cert_mem_cache_size=16MB #connection-auth=off
>
> http_port 8100    #forward port not used, only for troubleshooting.
>
>
> sslcrtd_program /usr/lib64/squid/security_file_certgen -s
> /var/spool/squid/ssl_db -M 4MB
>
>
> acl step1 at_step SslBump1
>
> acl azure_sites  dstdom_regex microsoft.com <http://microsoft.com>
> azure.com <http://azure.com> azureedge.net <http://azureedge.net>
> microsoftazurestack.com <http://microsoftazurestack.com>
> trafficmanager.net <http://trafficmanager.net>  wdcp.microsoft.com
> <http://wdcp.microsoft.com> wdcpalt.microsoft.com
> <http://wdcpalt.microsoft.com> updates.microsoft.com
> <http://updates.microsoft.com>
>
> acl azure_sites2 dstdom_regex download.microsoft.com
> <http://download.microsoft.com> msdl.microsoft.com
> <http://msdl.microsoft.com> crl.microsoft.com <http://crl.microsoft.com>
> secure.aadcdn.microsoftonline-p.com
> <http://secure.aadcdn.microsoftonline-p.com>
>

FYI: Regex is a slow procedure so when possible should be avoided. Since
all the above are domain names it looks like dstdomain would be better
with these ACL values. Some maybe using the wildcard dstdomain syntax.

 acl azure_sites dstdomain .microsoft.com \
    .azure.com .azureedge.net \
    .microsoftazurestack.com .trafficmanager.net

 acl azure_sites2 dstdomain .microsoft.com \
    secure.aadcdn.microsoftonline-p.com


> ssl_bump peek step1
>
> ssl_bump splice  azure_sites azure_sites2 #Avoid bumping Microsoft/Azure
> related sites
>

The way ACLs work in Squid items on a line like "azure_sites
azure_sites2" *both* have to match for the lines action to be used.

So the above line means all those domains except *.microsoft.com will
*not* be spliced here even if a URL domain was available.


>
> sslproxy_cert_error allow azure_sites azure_sites2     # is there a
> better way to handle these and log them?
>


For ssl_bump you should prefer the ssl::server_name or
ssl::server_name_regex type ACLs.

All Squid has in the way of URL at that timing is the CONNECT message
from step 1, which is a raw-IP for intercepted traffic. The domain names
in TLS / ssl_bump come from TLS SNI and server X.509 certificate.

The ssl::server_name ACL uses dstdomain-like comparisons, but against
the TLS handshake values instead of the HTTP request message values or
reverse-DNS names.


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

Re: Connection to cache peer failed "SSL Transparent proxy'

Walid A. Shaari


On Wed, 6 Feb 2019 at 05:53, Amos Jeffries <[hidden email]> wrote:

It depends on what your policies are as to which is the better approach
to take. It is looking a bit like (2) is probably the way to go. With
the switch from dstdomain to server_name type for the ssl_bump
processing this issue may just disappear.


Thank you, will try it tomorow.

>
> by the way, my final goal is to enable https traffic through, not really
> intercept it, by trial and error and reading the mailing list, that
> config below is what seems to be working for me right now, can not
> confirm totally as parent proxy is not under my control, nor is the
> appliance, however from the access.log and system message logs, things
> look better than earlier.  what is the best resource to understand the
> peek and splice, any good places other than squid cache main url?
>

The documentation of what modern Squid SSL-Bump feature does can be
found at <https://wiki.squid-cache.org/Features/SslPeekAndSplice>. It is
community maintained and kept as up to date as we can.

That page links to the relevant squid.conf documentation for the
relevant pieces. The whole TLS situation is a bit volatile so questions
are welcome here if you are unsure about anything in regards to your
specific Squid version, or observe things not matching that text.

..... ..... ...... 
If you try to force things you will run up against the lack of
re-CONNECT features in Squid. That is Squid cannot yet generate CONNECT
tunnels through non-TLS peers like you have.

Given that the intercepted HTTPS traffic must leave Squid over secure
connections that effectively means it cannot use the peer as it normally
would and has to send that traffic via ORIGINAL_DST / DIRECT connections
to the HTTPS server. If those are forbidden the transaction has no
choice but to terminate with an error message.


FWIW: Measurement Factory have an experimental branch adding that
re-CONNECT functionality to Squid, if you are okay running alpha quality
code that may be of interest.
 On the other side, I am working with a client on a configuration that
should result in the needed behaviour for the stable releases. That is
just entering testing and depends on whether they are willing for the
details to be published.

I am ok if it resolves my issues and does not introduce new bugs, I have some deadlines that I need to meet or otherwise drop all of this.


 > ####   Anonymous access to parent proxy
>
> #forwarded_for  delete
>
> #request_header_access Surrogate-Capability deny all
>

FYI: the bug behind the S-C header problems is now fixed in v4.5
release. Once you upgrade this can be removed.

I am on v4.5

 >

> dns_v4_first on
>
> cache_peer  192.168.4.22  parent 9090 0 no-query
> #sslcapath=/etc/pki/ca-trust/source/anchors/  
>
> acl local-network dstdomain .azcompany.com  #
> tighten after finalizng troubleshooting, maybe replace with localnet
>
> http_access allow all
>
> never_direct deny local-network    # revisit not using DNS for resolution
>
> never_direct allow all    
>
> http_port 8080 intercept    # should I really use intercept in here? can
> I get away without it
>
> https_port 8090 intercept ssl-bump generate-host-certificates=on 
> cert=/etc/squid/ssl_certs/bccaz01CA.pem 
> dynamic_cert_mem_cache_size=16MB #connection-auth=off
>
> http_port 8100    #forward port not used, only for troubleshooting.
>
>
> sslcrtd_program /usr/lib64/squid/security_file_certgen -s
> /var/spool/squid/ssl_db -M 4MB
>
>
> acl step1 at_step SslBump1
>
> acl azure_sites  dstdom_regex microsoft.com <http://microsoft.com>
> azure.com <http://azure.com> azureedge.net <http://azureedge.net>
> microsoftazurestack.com <http://microsoftazurestack.com>
> trafficmanager.net <http://trafficmanager.netwdcp.microsoft.com
> <http://wdcp.microsoft.com> wdcpalt.microsoft.com
> <http://wdcpalt.microsoft.com> updates.microsoft.com
> <http://updates.microsoft.com>
>
> acl azure_sites2 dstdom_regex download.microsoft.com
> <http://download.microsoft.com> msdl.microsoft.com
> <http://msdl.microsoft.com> crl.microsoft.com <http://crl.microsoft.com>
> secure.aadcdn.microsoftonline-p.com
> <http://secure.aadcdn.microsoftonline-p.com>
>

FYI: Regex is a slow procedure so when possible should be avoided. Since
all the above are domain names it looks like dstdomain would be better
with these ACL values. Some maybe using the wildcard dstdomain syntax.

 acl azure_sites dstdomain .microsoft.com \
    .azure.com .azureedge.net \
    .microsoftazurestack.com .trafficmanager.net

 acl azure_sites2 dstdomain .microsoft.com \
    secure.aadcdn.microsoftonline-p.com

Great, thanks, will use that definitely. 



> ssl_bump peek step1
>
> ssl_bump splice  azure_sites azure_sites2 #Avoid bumping Microsoft/Azure
> related sites
>

The way ACLs work in Squid items on a line like "azure_sites
azure_sites2" *both* have to match for the lines action to be used.

So the above line means all those domains except *.microsoft.com will
*not* be spliced here even if a URL domain was available.

Sorry, I did not get that, is it because microsoft.com is duplicated by mistake twice on both lines?  

Thank you Amos, you were great help.

Walid



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

Re: Connection to cache peer failed "SSL Transparent proxy'

Amos Jeffries
Administrator
On 7/02/19 8:03 am, Walid A. Shaari wrote:

>
> On Wed, 6 Feb 2019 at 05:53, Amos Jeffries wrote:
>
>     > ssl_bump peek step1
>     >
>     > ssl_bump splice  azure_sites azure_sites2 #Avoid bumping
>     Microsoft/Azure
>     > related sites
>     >
>
>     The way ACLs work in Squid items on a line like "azure_sites
>     azure_sites2" *both* have to match for the lines action to be used.
>
>     So the above line means all those domains except *.microsoft.com
>     <http://microsoft.com> will
>     *not* be spliced here even if a URL domain was available.
>
>
> Sorry, I did not get that, is it because microsoft.com
> <http://microsoft.com> is duplicated by mistake twice on both lines?  
>

I mean the names which only occur in one of the two ACL checks will do
possibly unwanted things. see the FAQ
<https://wiki.squid-cache.org/SquidFaq/SquidAcl#Common_Mistakes> for
details.

For example; when the request is for "microsoftazurestack.com" the
azure_sites2 part would be false. Which then means the splice is not done.

The only domain(s) where both azure_sites AND azure_sites2 are
matching/true are the *.microsoft.com names.



That said, I do not see any reason why you have two ACLs in the first
place. You could probably combine the two into one name and remove
azure_sites2 entirely.

PS. If the problem is line length for the list you can have multiple
'acl' lines adding different values to an ACL (like our default
Safe_Ports does) so long as the type is identical.

OR, you can also wrap config lines using a '\' right before the
end-of-line CRLF and whitespace to start the wrapped line part. Like:

 directive value1 value2 \
   value3 \
   value4

OR, you could place the list in a file and have the ACL load the values
from there.
Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Connection to cache peer failed "SSL Transparent proxy'

Walid A. Shaari
Got it. Thank you Amos

On Thu, 7 Feb 2019, 03:47 Amos Jeffries <[hidden email] wrote:
On 7/02/19 8:03 am, Walid A. Shaari wrote:
>
> On Wed, 6 Feb 2019 at 05:53, Amos Jeffries wrote:
>
>     > ssl_bump peek step1
>     >
>     > ssl_bump splice  azure_sites azure_sites2 #Avoid bumping
>     Microsoft/Azure
>     > related sites
>     >
>
>     The way ACLs work in Squid items on a line like "azure_sites
>     azure_sites2" *both* have to match for the lines action to be used.
>
>     So the above line means all those domains except *.microsoft.com
>     <http://microsoft.com> will
>     *not* be spliced here even if a URL domain was available.
>
>
> Sorry, I did not get that, is it because microsoft.com
> <http://microsoft.com> is duplicated by mistake twice on both lines?  
>

I mean the names which only occur in one of the two ACL checks will do
possibly unwanted things. see the FAQ
<https://wiki.squid-cache.org/SquidFaq/SquidAcl#Common_Mistakes> for
details.

For example; when the request is for "microsoftazurestack.com" the
azure_sites2 part would be false. Which then means the splice is not done.

The only domain(s) where both azure_sites AND azure_sites2 are
matching/true are the *.microsoft.com names.



That said, I do not see any reason why you have two ACLs in the first
place. You could probably combine the two into one name and remove
azure_sites2 entirely.

PS. If the problem is line length for the list you can have multiple
'acl' lines adding different values to an ACL (like our default
Safe_Ports does) so long as the type is identical.

OR, you can also wrap config lines using a '\' right before the
end-of-line CRLF and whitespace to start the wrapped line part. Like:

 directive value1 value2 \
   value3 \
   value4

OR, you could place the list in a file and have the ACL load the values
from there.
Amos

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