SslBump Peek and Splice using Squid-4.1-5 in Amazon1 Linux with Squid Helpers

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

SslBump Peek and Splice using Squid-4.1-5 in Amazon1 Linux with Squid Helpers

Mike Quentel
Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
(Amazon 1 Linux) to allow transparent proxy of certain domains, as
well as IPs associated with those domains, whilst rejecting everything
else.

I have been referencing documentation at
https://wiki.squid-cache.org/Features/SslPeekAndSplice

Version of Squid: 4.1-5 for Amazon 1 Linux available at
http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
@elico for these packages) specifically, the following:

1) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.amzn1.x86_64.rpm
2) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers-4.1-5.amzn1.x86_64.rpm

Example of tests that I am running:

1) curl -kv https://service.us2.sumologic.com (EXPECTED: successfully
accessed; OBSERVED: successfully accessed)
2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
because it resolves to service.us2.sumologic.com; OBSERVED:
"Certificate does not match domainname"  [No Error] (TLS code:
SQUID_X509_V_ERR_DOMAIN_MISMATCH))
3) curl -kv https://www.google.com (EXPECTED: failed to access;
OBSERVED: failed to access)
4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))

Below is the latest version of the squid.conf being used. Apologies
for any obvious errors--new to Squid here. I have been grappling with
this for weeks, with many iterations of squid.conf so any advice is
greatly appreciated; many thanks in advance.

---

visible_hostname squid

host_verify_strict off

# Handling HTTP requests
http_port 3128
http_port 3129 intercept

sslcrtd_children 10

acl CONNECT method CONNECT

# AWS services domain
acl allowed_http_sites dstdomain .amazonaws.com
# docker hub registry
acl allowed_http_sites dstdomain .docker.io
acl allowed_http_sites dstdomain .docker.com
acl allowed_http_sites dstdomain www.congiu.net

# Handling HTTPS requests
# https_port 3130 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=100MB cert=/etc/squid/squid.pem
https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=100MB
cert=/etc/squid/squid.pem
acl SSL_port port 443

# AWS services domain
acl allowed_https_sites ssl::server_name .amazonaws.com
# docker hub registry
acl allowed_https_sites ssl::server_name .docker.io
acl allowed_https_sites ssl::server_name .docker.com

# project specific
acl allowed_https_sites ssl::server_name www.congiu.net
acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca

# nslookup resolved IPs for collectors.sumologic.com
# workaround solution to support sumologic collector
acl allowed_https_sites ssl::server_name .sumologic.com
# THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
# acl allowed_https_sites ssl::server_name --server-provided
service.sumologic.com sslflags=DONT_VERIFY_PEER
# acl allowed_https_sites ssl::server_name --server-provided
service.us2.sumologic.com sslflags=DONT_VERIFY_PEER

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

ssl_bump peek step1 all
ssl_bump peek step2 allowed_https_sites
# http://lists.squid-cache.org/pipermail/squid-users/2018-September/019150.html
ssl_bump bump
ssl_bump splice step3 allowed_https_sites
ssl_bump bump
ssl_bump terminate step2 all

http_access allow CONNECT

# http_access allow SSL_port

http_access deny CONNECT !allowed_https_sites
http_access deny CONNECT !allowed_http_sites
http_access allow allowed_https_sites
http_access allow allowed_http_sites
http_access deny all

cache deny all

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

Re: SslBump Peek and Splice using Squid-4.1-5 in Amazon1 Linux with Squid Helpers

Enrico Heine
Dear Mike,

Please checkout the following and let us know if you need further help.

http://www.squid-cache.org/Doc/config/sslproxy_cert_error/

Best regards,

Flashdown

Am 11. Dezember 2018 16:41:56 MEZ schrieb Mike Quentel <[hidden email]>:
Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
(Amazon 1 Linux) to allow transparent proxy of certain domains, as
well as IPs associated with those domains, whilst rejecting everything
else.

I have been referencing documentation at
https://wiki.squid-cache.org/Features/SslPeekAndSplice

Version of Squid: 4.1-5 for Amazon 1 Linux available at
http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
@elico for these packages) specifically, the following:

1) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.amzn1.x86_64.rpm
2) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers-4.1-5.amzn1.x86_64.rpm

Example of tests that I am running:

1) curl -kv https://service.us2.sumologic.com (EXPECTED: successfully
accessed; OBSERVED: successfully accessed)
2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
because it resolves to service.us2.sumologic.com; OBSERVED:
"Certificate does not match domainname" [No Error] (TLS code:
SQUID_X509_V_ERR_DOMAIN_MISMATCH))
3) curl -kv https://www.google.com (EXPECTED: failed to access;
OBSERVED: failed to access)
4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
OBSERVED: "Certificate does not match domainname" [No Error] (TLS
code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))

Below is the latest version of the squid.conf being used. Apologies
for any obvious errors--new to Squid here. I have been grappling with
this for weeks, with many iterations of squid.conf so any advice is
greatly appreciated; many thanks in advance.
visible_hostname squid

host_verify_strict off

# Handling HTTP requests
http_port 3128
http_port 3129 intercept

sslcrtd_children 10

acl CONNECT method CONNECT

# AWS services domain
acl allowed_http_sites dstdomain .amazonaws.com
# docker hub registry
acl allowed_http_sites dstdomain .docker.io
acl allowed_http_sites dstdomain .docker.com
acl allowed_http_sites dstdomain www.congiu.net

# Handling HTTPS requests
# https_port 3130 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=100MB cert=/etc/squid/squid.pem
https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=100MB
cert=/etc/squid/squid.pem
acl SSL_port port 443

# AWS services domain
acl allowed_https_sites ssl::server_name .amazonaws.com
# docker hub registry
acl allowed_https_sites ssl::server_name .docker.io
acl allowed_https_sites ssl::server_name .docker.com

# project specific
acl allowed_https_sites ssl::server_name www.congiu.net
acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca

# nslookup resolved IPs for collectors.sumologic.com
# workaround solution to support sumologic collector
acl allowed_https_sites ssl::server_name .sumologic.com
# THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
# acl allowed_https_sites ssl::server_name --server-provided
service.sumologic.com sslflags=DONT_VERIFY_PEER
# acl allowed_https_sites ssl::server_name --server-provided
service.us2.sumologic.com sslflags=DONT_VERIFY_PEER

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

ssl_bump peek step1 all
ssl_bump peek step2 allowed_https_sites
# http://lists.squid-cache.org/pipermail/squid-users/2018-September/019150.html
ssl_bump bump
ssl_bump splice step3 allowed_https_sites
ssl_bump bump
ssl_bump terminate step2 all

http_access allow CONNECT

# http_access allow SSL_port

http_access deny CONNECT !allowed_https_sites
http_access deny CONNECT !allowed_http_sites
http_access allow allowed_https_sites
http_access allow allowed_http_sites
http_access deny all

cache deny all

debug_options "ALL,9"
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SslBump Peek and Splice using Squid-4.1-5 in Amazon1 Linux with Squid Helpers

Amos Jeffries
Administrator
On 12/12/18 6:53 am, Enrico Heine wrote:
> Dear Mike,
>
> Please checkout the following and let us know if you need further help.
>
> http://www.squid-cache.org/Doc/config/sslproxy_cert_error/
>

Before you use it though, please consider what the words "Certificate
does not match domainname" actually *mean*.

This Squid is configured to deliver a single specific custom-built
certificate to all clients who contact the proxy. Yet the proxy is being
used to receive TLS traffic for any domain and the admin is passing test
traffic for multiple different domains and raw-IP addresses.



> Best regards,
>
> Flashdown
>
> Am 11. Dezember 2018 16:41:56 MEZ schrieb Mike Quentel:
>
>     Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
>     (Amazon 1 Linux) to allow transparent proxy of certain domains, as
>     well as IPs associated with those domains, whilst rejecting everything
>     else.
>
>     I have been referencing documentation at
>     https://wiki.squid-cache.org/Features/SslPeekAndSplice
>
>     Version of Squid: 4.1-5 for Amazon 1 Linux available at
>     http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
>     @elico for these packages) specifically, the following:
>
>     1) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.amzn1.x86_64.rpm
>     2) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers-4.1-5.amzn1.x86_64.rpm
>
>     Example of tests that I am running:
>
>     1) curl -kv https://service.us2.sumologic.com (EXPECTED: successfully
>     accessed; OBSERVED: successfully accessed)

The TLS SNI contains "service.us2.sumologic.com", and
 - the server produced an X.509 certificate for that domain, and
 - your server_name ACL matches it as a sub-domain of ".sumologic.com"


Note that the -k parameter for curl only disables security on the
curl<->Squid TSL connection. It has nothing to do with the
Squid<->origin connections.

You should really be using "curl --cacert /etc/squid/squid.pem" or
connections without the -k to test what actually happens for clients
when their traffic goes through your system.


>     2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
>     because it resolves to service.us2.sumologic.com; OBSERVED:
>     "Certificate does not match domainname"  [No Error] (TLS code:
>     SQUID_X509_V_ERR_DOMAIN_MISMATCH))

IMO the expectation is what is wrong here.

The TLS SNI does not exist, and
 - being intercepted traffic the CONNECT authority is
"54.149.155.70:443", and
 - the server produced an X.509 certificate with SubjectName of either
"54.149.155.70" or something else not matching your server_name ACL entries.

FYI: server_name is a text-string matching ACL. I expect you will find
there is no reverse-DNS being performed during the ssl_bump testing,
only later after contact the server has already been decided to allow.
You can confirm that with the debug log your test produced. Look for the
lines saying what each ACL is checking for and against.


>     3) curl -kv https://www.google.com (EXPECTED: failed to access;
>     OBSERVED: failed to access)

"failed to access" is a gross over-simplification. This transaction is
both allowed and not-allowed at the same time.

If you look into the log I expect you will see this sequence happening:

 * the http_access rules *allow* the CONNECT tunnel, then

 * the ssl_bump rules select do "bump" action at Step-2 (aka. using only
the TLS clientHello details), then

 * curl -k ignores the small problem that you are not presenting the
X.509 keys belonging to Google.

 * the decrypted GET request inside the tunnel gets rejected because:
 - the "allowed_https_sites" ACL has no X.509 server details to test
against, so does not match.
  - the "allowed_http_sites" ACL does not match either
  - the "http_access deny all" matches everything reaching it.


>     4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
>     OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
>     code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))

Same thing going on as for test (2).


>
>     Below is the latest version of the squid.conf being used. Apologies
>     for any obvious errors--new to Squid here. I have been grappling with
>     this for weeks, with many iterations of squid.conf so any advice is
>     greatly appreciated; many thanks in advance.
>     ------------------------------------------------------------------------
>     visible_hostname squid

You have connected this proxy to the Internet. The above is required by
Internet RFCs to be a FQDN (fully qualified domain name).

Even if you do not want to follow that requirements it MUST be a unique
name.  If any of your HTTP traffic ever goes through another proxy
sharing this *very common* config mistake you will encounter forwarding
loop errors.


>
>     host_verify_strict off

This is the default. No need to configure it.

Also, if you added that because the errors you mentioned are talking
about domain verification - be aware that HTTP "Host:" header
verification is quite a different thing from TLS certificate verification.


>
>     # Handling HTTP requests
>     http_port 3128
>     http_port 3129 intercept
>
>     sslcrtd_children 10
>
>     acl CONNECT method CONNECT
>
>     # AWS services domain
>     acl allowed_http_sites dstdomain .amazonaws.com
>     # docker hub registry
>     acl allowed_http_sites dstdomain .docker.io
>     acl allowed_http_sites dstdomain .docker.com
>     acl allowed_http_sites dstdomain www.congiu.net
>
>     # Handling HTTPS requests
>     # https_port 3130 intercept ssl-bump generate-host-certificates=on
>     dynamic_cert_mem_cache_size=100MB cert=/etc/squid/squid.pem
>     https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=100MB
>     cert=/etc/squid/squid.pem

FYI: both the lines above behave identical because the generate-*
setting you removed was being set to its default value anyway.


>     acl SSL_port port 443
>
>     # AWS services domain
>     acl allowed_https_sites ssl::server_name .amazonaws.com
>     # docker hub registry
>     acl allowed_https_sites ssl::server_name .docker.io
>     acl allowed_https_sites ssl::server_name .docker.com
>
>     # project specific
>     acl allowed_https_sites ssl::server_name www.congiu.net
>     acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
>     acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca
>
>     # nslookup resolved IPs for collectors.sumologic.com
>     # workaround solution to support sumologic collector
>     acl allowed_https_sites ssl::server_name .sumologic.com
>     # THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED

The expectation is wrong here.

The string "sslflags=DONT_VERIFY_PEER" is not a valid domain nor server
hostname. So highly unlikely that the X.509 certificate SubjectName or
AltSubjectName from the origin server will contain that string.

Also, the flag sets the ACL matching algorithm. When that is set the ACL
cannot match during a ssl_bump "peek step1" cycle.

So one should expect this ACL to stop working when these lines are
added. Not expect that it would do anything useful.


FYI: The string "sslflags=DONT_VERIFY_PEER" is the name and value of a
option other directives elsewhere in squid.conf can use. But it is a
very, very, very bad idea to do so - even 'just for testing'.

 The flag DONT_VERIFY_PEER disables all of TLS security checks - meaning
the connection actively becomes *less* safe than regular/plain-text TCP
connections, while simultaneously hiding all resulting issues from
*your* admin view. Users still have problems, you just cannot see any
hint of them.
 So please purge that setting from any configs and documents you come
across. Investigate and fix any TLS problems that appear, don't just
hide the error messages and pretend everything works.
 Same reason not to be using the equivalent "curl -k" option for testing
TLS validation/verification problems.



>     # acl allowed_https_sites ssl::server_name --server-provided
>     service.sumologic.com sslflags=DONT_VERIFY_PEER
>     # acl allowed_https_sites ssl::server_name --server-provided
>     service.us2.sumologic.com sslflags=DONT_VERIFY_PEER
>
>     acl step1 at_step SslBump1
>     acl step2 at_step SslBump2
>     acl step3 at_step SslBump3
>
>     ssl_bump peek step1 all

The "all" here is useless and only adds confusion to anyone who thinks
it has any meaning.


>     ssl_bump peek step2 allowed_https_sites
>     # http://lists.squid-cache.org/pipermail/squid-users/2018-September/019150.html

The author of that did not understand how the ssl-bump processing was
working. That entire message thread is them attempting to learn and IMO
still not quite understanding the ideas in the end.

Blindly copying into your config from experiments by someone who does
not understand what they are doing is not a good idea. Use an actually
known-working config example (the Squid wiki has several), or try to
design your own based on your own understanding. At the very least we
can see from your self-designed attempt what you may be thinking and
hopefully teach you where any mistakes are visible.


>     ssl_bump bump

Please be aware that when this line when reached at step2 it performs
"client-first" bumping of the TLS.

That means bumping and performing TLS handshake without any real X.509
server details for your allowed_https_sites ACL to use. Only
client-provided claims about what server they are contacting (which may
be outright lies). This has side-effects on what your ssl::server_name
vs dstdomain ACL do in the later http_access checks.

Specifically when the server_name and the URL domain are different
things a simple as testing one first can change permissions for the
client in the other.


>     ssl_bump splice step3 allowed_https_sites

So some of your traffic will splice from the above line - but only
because of the peek (step2) then bump (step3) combination being impossible.


>     ssl_bump bump

There is already an unrestricted "bump" action earlier. This line does
nothing even if it were possibly reached.


>     ssl_bump terminate step2 all

There is a peek action specified earlier for step2, with an unrestricted
bump action as a fallback when allowed_https_sites fails to match. This
line is never reachable.

>
>     http_access allow CONNECT

Ouch. Really do not do the above. The default config file shipped with
Squid starts with these lines for very good reasons:

"
  http_access deny !Safe_ports
  http_access deny CONNECT !SSL_ports
  http_access allow localhost manager
  http_access deny manager

  #
  # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
  #
"

Those reasons (DoS and proxy relay security vulnerabilities) are still
very much relevant in your setup, with no reason to remove them. So
please add them back before you continue testing things, with your
custom http_access rules *underneath* that comment line.

Also, the default SSL_ports is already setup in a way that meets your
requirements. You can adjust Safe_ports to be only the same port, or use
the default set of safe-for-HTTP ports.

FYI: the config you have right now allows any malicious origin server
receiving trafic on port 443 to present a X.509 certificate claiming to be.


>
>     # http_access allow SSL_port
>
>     http_access deny CONNECT !allowed_https_sites
>     http_access deny CONNECT !allowed_http_sites

The above two lines do nothing in your current config. CONNECT requests
are *always* allowed by the line you had earlier.

Once you move back to the default security checks these will start to do
things. It would probably be best to remove the two lines above to
prevent the unexpected new behaviour from confusing you further.


>     http_access allow allowed_https_sites
>     http_access allow allowed_http_sites

These ACLs are very badly named.

* The one called "allowed_https_sites":
 - will *not* match against HTTPS traffic arriving on port 3128 unless
the CONNECT authority-uri names a domain in your list.

- *will* match against HTTP traffic on port 3128 and port 3129 with
"https://" URLs.

* The one called "allowed_http_sites" *will* match against HTTPS traffic
arriving on any port.

 --> meaning that for both of them the "https" and "http" word in their
name is deceptive.

* Both these ACLs are used to *deny* traffic.
 --> meaning the "allowed" word in their name is deceptive.

What you are left with is just "sites" which is so vague as to be
meaningless.


It would be a lot clearer if you renamed them:
 - "allowed_https_sites" to "tls_servers"
 - "allowed_http_sites" to "url_domains"


>     http_access deny all
>
>     cache deny all
>
>     debug_options "ALL,9"

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

Re: SslBump Peek and Splice using Squid-4.1-5 in Amazon1 Linux with Squid Helpers

Mike Quentel
Resending this message using corrected subject line...

Many thanks Enrico and Amos for the advice you each shared. I have
incorporated the suggested changes into squid.conf and almost have the
desired results in Squid.

Squid is successfully blocking access to TLS sites by an IP address,
but not the same sites using the domain names.

For example, Squid blocking the IP address (taken from nslookup) of
www.google.com successfully works (ERR_ACCESS_DENIED):
https://172.217.1.4

But, attempting to access https://www.google.com will still download
the page (200).

How can I force Squid to block the TLS FQDN versions of web sites that
are not in the white list?

This is the updated squid.conf:

---

visible_hostname squid

http_port 3129 intercept

sslcrtd_children 10

acl CONNECT method CONNECT

acl url_domains dstdomain .amazonaws.com
acl url_domains dstdomain .docker.io
acl url_domains dstdomain .docker.com
acl url_domains dstdomain .congiu.com

https_port 3130 ssl-bump intercept generate-host-certificates=3Don
dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
acl SSL_ports port 443
http_access allow SSL_ports

acl tls_servers ssl::server_name .amazonaws.com
acl tls_servers ssl::server_name .docker.io
acl tls_servers ssl::server_name .docker.com
acl tls_servers ssl::server_name .congiu.com
acl tls_servers ssl::server_name .fedoraproject.org
acl tls_servers ssl::server_name mirror.csclub.uwaterloo.ca
acl tls_servers ssl::server_name .sumologic.com

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

always_direct allow url_domains
sslproxy_cert_error allow all

http_access deny CONNECT !SSL_Ports
http_access allow url_domains
http_access allow tls_servers
http_access deny all

cache deny all

ssl_bump peek step1 all
ssl_bump peek step2 tls_servers
ssl_bump splice step3 tls_servers
ssl_bump stare step2
ssl_bump bump step3
ssl_bump terminate step2 all

# debug_options ALL,1 80,5
debug_options ALL,1 33,4

---

Thanks, Mike Quentel

On Tue, 11 Dec 2018 at 18:08, <[hidden email]> w=
rote:

>
> Send squid-users mailing list submissions to
>         [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.squid-cache.org/listinfo/squid-users
> or, via email, send a message with subject or body 'help' to
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of squid-users digest..."
>
>
> Today's Topics:
>
>    1. SslBump Peek and Splice using Squid-4.1-5 in Amazon1      Linux
>       with Squid Helpers (Mike Quentel)
>    2. Re: SslBump Peek and Splice using Squid-4.1-5 in  Amazon1
>       Linux with Squid Helpers (Enrico Heine)
>    3. Re: SslBump Peek and Splice using Squid-4.1-5 in Amazon1
>       Linux with Squid Helpers (Amos Jeffries)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 11 Dec 2018 10:41:56 -0500
> From: Mike Quentel <[hidden email]>
> To: [hidden email]
> Subject: [squid-users] SslBump Peek and Splice using Squid-4.1-5 in
>         Amazon1 Linux with Squid Helpers
> Message-ID:
>         <[hidden email]=
om>

> Content-Type: text/plain; charset=3D"UTF-8"
>
> Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
> (Amazon 1 Linux) to allow transparent proxy of certain domains, as
> well as IPs associated with those domains, whilst rejecting everything
> else.
>
> I have been referencing documentation at
> https://wiki.squid-cache.org/Features/SslPeekAndSplice
>
> Version of Squid: 4.1-5 for Amazon 1 Linux available at
> http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
> @elico for these packages) specifically, the following:
>
> 1) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.amzn1.x=
86_64.rpm
> 2) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers-4.1-5=
.amzn1.x86_64.rpm

>
> Example of tests that I am running:
>
> 1) curl -kv https://service.us2.sumologic.com (EXPECTED: successfully
> accessed; OBSERVED: successfully accessed)
> 2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
> because it resolves to service.us2.sumologic.com; OBSERVED:
> "Certificate does not match domainname"  [No Error] (TLS code:
> SQUID_X509_V_ERR_DOMAIN_MISMATCH))
> 3) curl -kv https://www.google.com (EXPECTED: failed to access;
> OBSERVED: failed to access)
> 4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
> OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
> code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))
>
> Below is the latest version of the squid.conf being used. Apologies
> for any obvious errors--new to Squid here. I have been grappling with
> this for weeks, with many iterations of squid.conf so any advice is
> greatly appreciated; many thanks in advance.
>
> ---
>
> visible_hostname squid
>
> host_verify_strict off
>
> # Handling HTTP requests
> http_port 3128
> http_port 3129 intercept
>
> sslcrtd_children 10
>
> acl CONNECT method CONNECT
>
> # AWS services domain
> acl allowed_http_sites dstdomain .amazonaws.com
> # docker hub registry
> acl allowed_http_sites dstdomain .docker.io
> acl allowed_http_sites dstdomain .docker.com
> acl allowed_http_sites dstdomain www.congiu.net
>
> # Handling HTTPS requests
> # https_port 3130 intercept ssl-bump generate-host-certificates=3Don
> dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
> https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=3D100MB
> cert=3D/etc/squid/squid.pem
> acl SSL_port port 443
>
> # AWS services domain
> acl allowed_https_sites ssl::server_name .amazonaws.com
> # docker hub registry
> acl allowed_https_sites ssl::server_name .docker.io
> acl allowed_https_sites ssl::server_name .docker.com
>
> # project specific
> acl allowed_https_sites ssl::server_name www.congiu.net
> acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
> acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca
>
> # nslookup resolved IPs for collectors.sumologic.com
> # workaround solution to support sumologic collector
> acl allowed_https_sites ssl::server_name .sumologic.com
> # THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
> # acl allowed_https_sites ssl::server_name --server-provided
> service.sumologic.com sslflags=3DDONT_VERIFY_PEER
> # acl allowed_https_sites ssl::server_name --server-provided
> service.us2.sumologic.com sslflags=3DDONT_VERIFY_PEER
>
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
>
> ssl_bump peek step1 all
> ssl_bump peek step2 allowed_https_sites
> # http://lists.squid-cache.org/pipermail/squid-users/2018-September/01915=
0.html

> ssl_bump bump
> ssl_bump splice step3 allowed_https_sites
> ssl_bump bump
> ssl_bump terminate step2 all
>
> http_access allow CONNECT
>
> # http_access allow SSL_port
>
> http_access deny CONNECT !allowed_https_sites
> http_access deny CONNECT !allowed_http_sites
> http_access allow allowed_https_sites
> http_access allow allowed_http_sites
> http_access deny all
>
> cache deny all
>
> debug_options "ALL,9"
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 11 Dec 2018 18:53:23 +0100
> From: Enrico Heine <[hidden email]>
> To: [hidden email], Mike Quentel
>         <[hidden email]>
> Subject: Re: [squid-users] SslBump Peek and Splice using Squid-4.1-5
>         in      Amazon1 Linux with Squid Helpers
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=3D"utf-8"
>
> Dear Mike,
>
> Please checkout the following and let us know if you need further help.
>
> http://www.squid-cache.org/Doc/config/sslproxy_cert_error/
>
> Best regards,
>
> Flashdown
>
> Am 11. Dezember 2018 16:41:56 MEZ schrieb Mike Quentel <mike.quentel.rbc@=
gmail.com>:

> >Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
> >(Amazon 1 Linux) to allow transparent proxy of certain domains, as
> >well as IPs associated with those domains, whilst rejecting everything
> >else.
> >
> >I have been referencing documentation at
> >https://wiki.squid-cache.org/Features/SslPeekAndSplice
> >
> >Version of Squid: 4.1-5 for Amazon 1 Linux available at
> >http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
> >@elico for these packages) specifically, the following:
> >
> >1)
> >http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.amzn1.x86=
_64.rpm
> >2)
> >http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers-4.1-5.a=
mzn1.x86_64.rpm

> >
> >Example of tests that I am running:
> >
> >1) curl -kv https://service.us2.sumologic.com (EXPECTED: successfully
> >accessed; OBSERVED: successfully accessed)
> >2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
> >because it resolves to service.us2.sumologic.com; OBSERVED:
> >"Certificate does not match domainname"  [No Error] (TLS code:
> >SQUID_X509_V_ERR_DOMAIN_MISMATCH))
> >3) curl -kv https://www.google.com (EXPECTED: failed to access;
> >OBSERVED: failed to access)
> >4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
> >OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
> >code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))
> >
> >Below is the latest version of the squid.conf being used. Apologies
> >for any obvious errors--new to Squid here. I have been grappling with
> >this for weeks, with many iterations of squid.conf so any advice is
> >greatly appreciated; many thanks in advance.
> >
> >---
> >
> >visible_hostname squid
> >
> >host_verify_strict off
> >
> ># Handling HTTP requests
> >http_port 3128
> >http_port 3129 intercept
> >
> >sslcrtd_children 10
> >
> >acl CONNECT method CONNECT
> >
> ># AWS services domain
> >acl allowed_http_sites dstdomain .amazonaws.com
> ># docker hub registry
> >acl allowed_http_sites dstdomain .docker.io
> >acl allowed_http_sites dstdomain .docker.com
> >acl allowed_http_sites dstdomain www.congiu.net
> >
> ># Handling HTTPS requests
> ># https_port 3130 intercept ssl-bump generate-host-certificates=3Don
> >dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
> >https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=3D100MB
> >cert=3D/etc/squid/squid.pem
> >acl SSL_port port 443
> >
> ># AWS services domain
> >acl allowed_https_sites ssl::server_name .amazonaws.com
> ># docker hub registry
> >acl allowed_https_sites ssl::server_name .docker.io
> >acl allowed_https_sites ssl::server_name .docker.com
> >
> ># project specific
> >acl allowed_https_sites ssl::server_name www.congiu.net
> >acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
> >acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca
> >
> ># nslookup resolved IPs for collectors.sumologic.com
> ># workaround solution to support sumologic collector
> >acl allowed_https_sites ssl::server_name .sumologic.com
> ># THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
> ># acl allowed_https_sites ssl::server_name --server-provided
> >service.sumologic.com sslflags=3DDONT_VERIFY_PEER
> ># acl allowed_https_sites ssl::server_name --server-provided
> >service.us2.sumologic.com sslflags=3DDONT_VERIFY_PEER
> >
> >acl step1 at_step SslBump1
> >acl step2 at_step SslBump2
> >acl step3 at_step SslBump3
> >
> >ssl_bump peek step1 all
> >ssl_bump peek step2 allowed_https_sites
> >#
> >http://lists.squid-cache.org/pipermail/squid-users/2018-September/019150=
.html

> >ssl_bump bump
> >ssl_bump splice step3 allowed_https_sites
> >ssl_bump bump
> >ssl_bump terminate step2 all
> >
> >http_access allow CONNECT
> >
> ># http_access allow SSL_port
> >
> >http_access deny CONNECT !allowed_https_sites
> >http_access deny CONNECT !allowed_http_sites
> >http_access allow allowed_https_sites
> >http_access allow allowed_http_sites
> >http_access deny all
> >
> >cache deny all
> >
> >debug_options "ALL,9"
> >_______________________________________________
> >squid-users mailing list
> >[hidden email]
> >http://lists.squid-cache.org/listinfo/squid-users
>
> --
> Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet=
.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/2018=
1211/f46270b6/attachment-0001.html>

>
> ------------------------------
>
> Message: 3
> Date: Wed, 12 Dec 2018 12:07:49 +1300
> From: Amos Jeffries <[hidden email]>
> To: [hidden email]
> Subject: Re: [squid-users] SslBump Peek and Splice using Squid-4.1-5
>         in Amazon1 Linux with Squid Helpers
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=3Dutf-8
>
> On 12/12/18 6:53 am, Enrico Heine wrote:
> > Dear Mike,
> >
> > Please checkout the following and let us know if you need further help.
> >
> > http://www.squid-cache.org/Doc/config/sslproxy_cert_error/
> >
>
> Before you use it though, please consider what the words "Certificate
> does not match domainname" actually *mean*.
>
> This Squid is configured to deliver a single specific custom-built
> certificate to all clients who contact the proxy. Yet the proxy is being
> used to receive TLS traffic for any domain and the admin is passing test
> traffic for multiple different domains and raw-IP addresses.
>
>
>
> > Best regards,
> >
> > Flashdown
> >
> > Am 11. Dezember 2018 16:41:56 MEZ schrieb Mike Quentel:
> >
> >     Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
> >     (Amazon 1 Linux) to allow transparent proxy of certain domains, as
> >     well as IPs associated with those domains, whilst rejecting everyth=
ing

> >     else.
> >
> >     I have been referencing documentation at
> >     https://wiki.squid-cache.org/Features/SslPeekAndSplice
> >
> >     Version of Squid: 4.1-5 for Amazon 1 Linux available at
> >     http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
> >     @elico for these packages) specifically, the following:
> >
> >     1) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.a=
mzn1.x86_64.rpm
> >     2) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers=
-4.1-5.amzn1.x86_64.rpm
> >
> >     Example of tests that I am running:
> >
> >     1) curl -kv https://service.us2.sumologic.com (EXPECTED: successful=
ly

> >     accessed; OBSERVED: successfully accessed)
>
> The TLS SNI contains "service.us2.sumologic.com", and
>  - the server produced an X.509 certificate for that domain, and
>  - your server_name ACL matches it as a sub-domain of ".sumologic.com"
>
>
> Note that the -k parameter for curl only disables security on the
> curl<->Squid TSL connection. It has nothing to do with the
> Squid<->origin connections.
>
> You should really be using "curl --cacert /etc/squid/squid.pem" or
> connections without the -k to test what actually happens for clients
> when their traffic goes through your system.
>
>
> >     2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
> >     because it resolves to service.us2.sumologic.com; OBSERVED:
> >     "Certificate does not match domainname"  [No Error] (TLS code:
> >     SQUID_X509_V_ERR_DOMAIN_MISMATCH))
>
> IMO the expectation is what is wrong here.
>
> The TLS SNI does not exist, and
>  - being intercepted traffic the CONNECT authority is
> "54.149.155.70:443", and
>  - the server produced an X.509 certificate with SubjectName of either
> "54.149.155.70" or something else not matching your server_name ACL entri=
es.

>
> FYI: server_name is a text-string matching ACL. I expect you will find
> there is no reverse-DNS being performed during the ssl_bump testing,
> only later after contact the server has already been decided to allow.
> You can confirm that with the debug log your test produced. Look for the
> lines saying what each ACL is checking for and against.
>
>
> >     3) curl -kv https://www.google.com (EXPECTED: failed to access;
> >     OBSERVED: failed to access)
>
> "failed to access" is a gross over-simplification. This transaction is
> both allowed and not-allowed at the same time.
>
> If you look into the log I expect you will see this sequence happening:
>
>  * the http_access rules *allow* the CONNECT tunnel, then
>
>  * the ssl_bump rules select do "bump" action at Step-2 (aka. using only
> the TLS clientHello details), then
>
>  * curl -k ignores the small problem that you are not presenting the
> X.509 keys belonging to Google.
>
>  * the decrypted GET request inside the tunnel gets rejected because:
>  - the "allowed_https_sites" ACL has no X.509 server details to test
> against, so does not match.
>   - the "allowed_http_sites" ACL does not match either
>   - the "http_access deny all" matches everything reaching it.
>
>
> >     4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
> >     OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
> >     code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))
>
> Same thing going on as for test (2).
>
>
> >
> >     Below is the latest version of the squid.conf being used. Apologies
> >     for any obvious errors--new to Squid here. I have been grappling wi=
th
> >     this for weeks, with many iterations of squid.conf so any advice is
> >     greatly appreciated; many thanks in advance.
> >     -------------------------------------------------------------------=
-----

> >     visible_hostname squid
>
> You have connected this proxy to the Internet. The above is required by
> Internet RFCs to be a FQDN (fully qualified domain name).
>
> Even if you do not want to follow that requirements it MUST be a unique
> name.  If any of your HTTP traffic ever goes through another proxy
> sharing this *very common* config mistake you will encounter forwarding
> loop errors.
>
>
> >
> >     host_verify_strict off
>
> This is the default. No need to configure it.
>
> Also, if you added that because the errors you mentioned are talking
> about domain verification - be aware that HTTP "Host:" header
> verification is quite a different thing from TLS certificate verification=
.

>
>
> >
> >     # Handling HTTP requests
> >     http_port 3128
> >     http_port 3129 intercept
> >
> >     sslcrtd_children 10
> >
> >     acl CONNECT method CONNECT
> >
> >     # AWS services domain
> >     acl allowed_http_sites dstdomain .amazonaws.com
> >     # docker hub registry
> >     acl allowed_http_sites dstdomain .docker.io
> >     acl allowed_http_sites dstdomain .docker.com
> >     acl allowed_http_sites dstdomain www.congiu.net
> >
> >     # Handling HTTPS requests
> >     # https_port 3130 intercept ssl-bump generate-host-certificates=3Do=
n
> >     dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
> >     https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=3D10=
0MB

> >     cert=3D/etc/squid/squid.pem
>
> FYI: both the lines above behave identical because the generate-*
> setting you removed was being set to its default value anyway.
>
>
> >     acl SSL_port port 443
> >
> >     # AWS services domain
> >     acl allowed_https_sites ssl::server_name .amazonaws.com
> >     # docker hub registry
> >     acl allowed_https_sites ssl::server_name .docker.io
> >     acl allowed_https_sites ssl::server_name .docker.com
> >
> >     # project specific
> >     acl allowed_https_sites ssl::server_name www.congiu.net
> >     acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
> >     acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca
> >
> >     # nslookup resolved IPs for collectors.sumologic.com
> >     # workaround solution to support sumologic collector
> >     acl allowed_https_sites ssl::server_name .sumologic.com
> >     # THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
>
> The expectation is wrong here.
>
> The string "sslflags=3DDONT_VERIFY_PEER" is not a valid domain nor server
> hostname. So highly unlikely that the X.509 certificate SubjectName or
> AltSubjectName from the origin server will contain that string.
>
> Also, the flag sets the ACL matching algorithm. When that is set the ACL
> cannot match during a ssl_bump "peek step1" cycle.
>
> So one should expect this ACL to stop working when these lines are
> added. Not expect that it would do anything useful.
>
>
> FYI: The string "sslflags=3DDONT_VERIFY_PEER" is the name and value of a
> option other directives elsewhere in squid.conf can use. But it is a
> very, very, very bad idea to do so - even 'just for testing'.
>
>  The flag DONT_VERIFY_PEER disables all of TLS security checks - meaning
> the connection actively becomes *less* safe than regular/plain-text TCP
> connections, while simultaneously hiding all resulting issues from
> *your* admin view. Users still have problems, you just cannot see any
> hint of them.
>  So please purge that setting from any configs and documents you come
> across. Investigate and fix any TLS problems that appear, don't just
> hide the error messages and pretend everything works.
>  Same reason not to be using the equivalent "curl -k" option for testing
> TLS validation/verification problems.
>
>
>
> >     # acl allowed_https_sites ssl::server_name --server-provided
> >     service.sumologic.com sslflags=3DDONT_VERIFY_PEER
> >     # acl allowed_https_sites ssl::server_name --server-provided
> >     service.us2.sumologic.com sslflags=3DDONT_VERIFY_PEER
> >
> >     acl step1 at_step SslBump1
> >     acl step2 at_step SslBump2
> >     acl step3 at_step SslBump3
> >
> >     ssl_bump peek step1 all
>
> The "all" here is useless and only adds confusion to anyone who thinks
> it has any meaning.
>
>
> >     ssl_bump peek step2 allowed_https_sites
> >     # http://lists.squid-cache.org/pipermail/squid-users/2018-September=
/019150.html

>
> The author of that did not understand how the ssl-bump processing was
> working. That entire message thread is them attempting to learn and IMO
> still not quite understanding the ideas in the end.
>
> Blindly copying into your config from experiments by someone who does
> not understand what they are doing is not a good idea. Use an actually
> known-working config example (the Squid wiki has several), or try to
> design your own based on your own understanding. At the very least we
> can see from your self-designed attempt what you may be thinking and
> hopefully teach you where any mistakes are visible.
>
>
> >     ssl_bump bump
>
> Please be aware that when this line when reached at step2 it performs
> "client-first" bumping of the TLS.
>
> That means bumping and performing TLS handshake without any real X.509
> server details for your allowed_https_sites ACL to use. Only
> client-provided claims about what server they are contacting (which may
> be outright lies). This has side-effects on what your ssl::server_name
> vs dstdomain ACL do in the later http_access checks.
>
> Specifically when the server_name and the URL domain are different
> things a simple as testing one first can change permissions for the
> client in the other.
>
>
> >     ssl_bump splice step3 allowed_https_sites
>
> So some of your traffic will splice from the above line - but only
> because of the peek (step2) then bump (step3) combination being impossibl=
e.

>
>
> >     ssl_bump bump
>
> There is already an unrestricted "bump" action earlier. This line does
> nothing even if it were possibly reached.
>
>
> >     ssl_bump terminate step2 all
>
> There is a peek action specified earlier for step2, with an unrestricted
> bump action as a fallback when allowed_https_sites fails to match. This
> line is never reachable.
>
> >
> >     http_access allow CONNECT
>
> Ouch. Really do not do the above. The default config file shipped with
> Squid starts with these lines for very good reasons:
>
> "
>   http_access deny !Safe_ports
>   http_access deny CONNECT !SSL_ports
>   http_access allow localhost manager
>   http_access deny manager
>
>   #
>   # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
>   #
> "
>
> Those reasons (DoS and proxy relay security vulnerabilities) are still
> very much relevant in your setup, with no reason to remove them. So
> please add them back before you continue testing things, with your
> custom http_access rules *underneath* that comment line.
>
> Also, the default SSL_ports is already setup in a way that meets your
> requirements. You can adjust Safe_ports to be only the same port, or use
> the default set of safe-for-HTTP ports.
>
> FYI: the config you have right now allows any malicious origin server
> receiving trafic on port 443 to present a X.509 certificate claiming to b=
e.

>
>
> >
> >     # http_access allow SSL_port
> >
> >     http_access deny CONNECT !allowed_https_sites
> >     http_access deny CONNECT !allowed_http_sites
>
> The above two lines do nothing in your current config. CONNECT requests
> are *always* allowed by the line you had earlier.
>
> Once you move back to the default security checks these will start to do
> things. It would probably be best to remove the two lines above to
> prevent the unexpected new behaviour from confusing you further.
>
>
> >     http_access allow allowed_https_sites
> >     http_access allow allowed_http_sites
>
> These ACLs are very badly named.
>
> * The one called "allowed_https_sites":
>  - will *not* match against HTTPS traffic arriving on port 3128 unless
> the CONNECT authority-uri names a domain in your list.
>
> - *will* match against HTTP traffic on port 3128 and port 3129 with
> "https://" URLs.
>
> * The one called "allowed_http_sites" *will* match against HTTPS traffic
> arriving on any port.
>
>  --> meaning that for both of them the "https" and "http" word in their
> name is deceptive.
>
> * Both these ACLs are used to *deny* traffic.
>  --> meaning the "allowed" word in their name is deceptive.
>
> What you are left with is just "sites" which is so vague as to be
> meaningless.
>
>
> It would be a lot clearer if you renamed them:
>  - "allowed_https_sites" to "tls_servers"
>  - "allowed_http_sites" to "url_domains"
>
>
> >     http_access deny all
> >
> >     cache deny all
> >
> >     debug_options "ALL,9"
>
> Cheers
> Amos
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
>
> ------------------------------
>
> End of squid-users Digest, Vol 52, Issue 13
> *******************************************
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SslBump Peek and Splice using Squid-4.1-5 in Amazon1 Linux with Squid Helpers

Eliezer Croitoru
Remove the line:
http_access allow SSL_ports

It bypass all the next ACL's....

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]



-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Mike Quentel
Sent: Tuesday, December 18, 2018 22:32
To: [hidden email]; [hidden email]; asdf asdf <[hidden email]>
Subject: Re: [squid-users] SslBump Peek and Splice using Squid-4.1-5 in Amazon1 Linux with Squid Helpers

Resending this message using corrected subject line...

Many thanks Enrico and Amos for the advice you each shared. I have
incorporated the suggested changes into squid.conf and almost have the
desired results in Squid.

Squid is successfully blocking access to TLS sites by an IP address,
but not the same sites using the domain names.

For example, Squid blocking the IP address (taken from nslookup) of
www.google.com successfully works (ERR_ACCESS_DENIED):
https://172.217.1.4

But, attempting to access https://www.google.com will still download
the page (200).

How can I force Squid to block the TLS FQDN versions of web sites that
are not in the white list?

This is the updated squid.conf:

---

visible_hostname squid

http_port 3129 intercept

sslcrtd_children 10

acl CONNECT method CONNECT

acl url_domains dstdomain .amazonaws.com
acl url_domains dstdomain .docker.io
acl url_domains dstdomain .docker.com
acl url_domains dstdomain .congiu.com

https_port 3130 ssl-bump intercept generate-host-certificates=3Don
dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
acl SSL_ports port 443
http_access allow SSL_ports

acl tls_servers ssl::server_name .amazonaws.com
acl tls_servers ssl::server_name .docker.io
acl tls_servers ssl::server_name .docker.com
acl tls_servers ssl::server_name .congiu.com
acl tls_servers ssl::server_name .fedoraproject.org
acl tls_servers ssl::server_name mirror.csclub.uwaterloo.ca
acl tls_servers ssl::server_name .sumologic.com

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

always_direct allow url_domains
sslproxy_cert_error allow all

http_access deny CONNECT !SSL_Ports
http_access allow url_domains
http_access allow tls_servers
http_access deny all

cache deny all

ssl_bump peek step1 all
ssl_bump peek step2 tls_servers
ssl_bump splice step3 tls_servers
ssl_bump stare step2
ssl_bump bump step3
ssl_bump terminate step2 all

# debug_options ALL,1 80,5
debug_options ALL,1 33,4

---

Thanks, Mike Quentel

On Tue, 11 Dec 2018 at 18:08, <[hidden email]> w=
rote:

>
> Send squid-users mailing list submissions to
>         [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.squid-cache.org/listinfo/squid-users
> or, via email, send a message with subject or body 'help' to
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of squid-users digest..."
>
>
> Today's Topics:
>
>    1. SslBump Peek and Splice using Squid-4.1-5 in Amazon1      Linux
>       with Squid Helpers (Mike Quentel)
>    2. Re: SslBump Peek and Splice using Squid-4.1-5 in  Amazon1
>       Linux with Squid Helpers (Enrico Heine)
>    3. Re: SslBump Peek and Splice using Squid-4.1-5 in Amazon1
>       Linux with Squid Helpers (Amos Jeffries)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 11 Dec 2018 10:41:56 -0500
> From: Mike Quentel <[hidden email]>
> To: [hidden email]
> Subject: [squid-users] SslBump Peek and Splice using Squid-4.1-5 in
>         Amazon1 Linux with Squid Helpers
> Message-ID:
>         <[hidden email]=
om>

> Content-Type: text/plain; charset=3D"UTF-8"
>
> Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
> (Amazon 1 Linux) to allow transparent proxy of certain domains, as
> well as IPs associated with those domains, whilst rejecting everything
> else.
>
> I have been referencing documentation at
> https://wiki.squid-cache.org/Features/SslPeekAndSplice
>
> Version of Squid: 4.1-5 for Amazon 1 Linux available at
> http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
> @elico for these packages) specifically, the following:
>
> 1) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.amzn1.x=
86_64.rpm
> 2) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers-4.1-5=
.amzn1.x86_64.rpm

>
> Example of tests that I am running:
>
> 1) curl -kv https://service.us2.sumologic.com (EXPECTED: successfully
> accessed; OBSERVED: successfully accessed)
> 2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
> because it resolves to service.us2.sumologic.com; OBSERVED:
> "Certificate does not match domainname"  [No Error] (TLS code:
> SQUID_X509_V_ERR_DOMAIN_MISMATCH))
> 3) curl -kv https://www.google.com (EXPECTED: failed to access;
> OBSERVED: failed to access)
> 4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
> OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
> code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))
>
> Below is the latest version of the squid.conf being used. Apologies
> for any obvious errors--new to Squid here. I have been grappling with
> this for weeks, with many iterations of squid.conf so any advice is
> greatly appreciated; many thanks in advance.
>
> ---
>
> visible_hostname squid
>
> host_verify_strict off
>
> # Handling HTTP requests
> http_port 3128
> http_port 3129 intercept
>
> sslcrtd_children 10
>
> acl CONNECT method CONNECT
>
> # AWS services domain
> acl allowed_http_sites dstdomain .amazonaws.com
> # docker hub registry
> acl allowed_http_sites dstdomain .docker.io
> acl allowed_http_sites dstdomain .docker.com
> acl allowed_http_sites dstdomain www.congiu.net
>
> # Handling HTTPS requests
> # https_port 3130 intercept ssl-bump generate-host-certificates=3Don
> dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
> https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=3D100MB
> cert=3D/etc/squid/squid.pem
> acl SSL_port port 443
>
> # AWS services domain
> acl allowed_https_sites ssl::server_name .amazonaws.com
> # docker hub registry
> acl allowed_https_sites ssl::server_name .docker.io
> acl allowed_https_sites ssl::server_name .docker.com
>
> # project specific
> acl allowed_https_sites ssl::server_name www.congiu.net
> acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
> acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca
>
> # nslookup resolved IPs for collectors.sumologic.com
> # workaround solution to support sumologic collector
> acl allowed_https_sites ssl::server_name .sumologic.com
> # THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
> # acl allowed_https_sites ssl::server_name --server-provided
> service.sumologic.com sslflags=3DDONT_VERIFY_PEER
> # acl allowed_https_sites ssl::server_name --server-provided
> service.us2.sumologic.com sslflags=3DDONT_VERIFY_PEER
>
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
>
> ssl_bump peek step1 all
> ssl_bump peek step2 allowed_https_sites
> # http://lists.squid-cache.org/pipermail/squid-users/2018-September/01915=
0.html

> ssl_bump bump
> ssl_bump splice step3 allowed_https_sites
> ssl_bump bump
> ssl_bump terminate step2 all
>
> http_access allow CONNECT
>
> # http_access allow SSL_port
>
> http_access deny CONNECT !allowed_https_sites
> http_access deny CONNECT !allowed_http_sites
> http_access allow allowed_https_sites
> http_access allow allowed_http_sites
> http_access deny all
>
> cache deny all
>
> debug_options "ALL,9"
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 11 Dec 2018 18:53:23 +0100
> From: Enrico Heine <[hidden email]>
> To: [hidden email], Mike Quentel
>         <[hidden email]>
> Subject: Re: [squid-users] SslBump Peek and Splice using Squid-4.1-5
>         in      Amazon1 Linux with Squid Helpers
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=3D"utf-8"
>
> Dear Mike,
>
> Please checkout the following and let us know if you need further help.
>
> http://www.squid-cache.org/Doc/config/sslproxy_cert_error/
>
> Best regards,
>
> Flashdown
>
> Am 11. Dezember 2018 16:41:56 MEZ schrieb Mike Quentel <mike.quentel.rbc@=
gmail.com>:

> >Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
> >(Amazon 1 Linux) to allow transparent proxy of certain domains, as
> >well as IPs associated with those domains, whilst rejecting everything
> >else.
> >
> >I have been referencing documentation at
> >https://wiki.squid-cache.org/Features/SslPeekAndSplice
> >
> >Version of Squid: 4.1-5 for Amazon 1 Linux available at
> >http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
> >@elico for these packages) specifically, the following:
> >
> >1)
> >http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.amzn1.x86=
_64.rpm
> >2)
> >http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers-4.1-5.a=
mzn1.x86_64.rpm

> >
> >Example of tests that I am running:
> >
> >1) curl -kv https://service.us2.sumologic.com (EXPECTED: successfully
> >accessed; OBSERVED: successfully accessed)
> >2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
> >because it resolves to service.us2.sumologic.com; OBSERVED:
> >"Certificate does not match domainname"  [No Error] (TLS code:
> >SQUID_X509_V_ERR_DOMAIN_MISMATCH))
> >3) curl -kv https://www.google.com (EXPECTED: failed to access;
> >OBSERVED: failed to access)
> >4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
> >OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
> >code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))
> >
> >Below is the latest version of the squid.conf being used. Apologies
> >for any obvious errors--new to Squid here. I have been grappling with
> >this for weeks, with many iterations of squid.conf so any advice is
> >greatly appreciated; many thanks in advance.
> >
> >---
> >
> >visible_hostname squid
> >
> >host_verify_strict off
> >
> ># Handling HTTP requests
> >http_port 3128
> >http_port 3129 intercept
> >
> >sslcrtd_children 10
> >
> >acl CONNECT method CONNECT
> >
> ># AWS services domain
> >acl allowed_http_sites dstdomain .amazonaws.com
> ># docker hub registry
> >acl allowed_http_sites dstdomain .docker.io
> >acl allowed_http_sites dstdomain .docker.com
> >acl allowed_http_sites dstdomain www.congiu.net
> >
> ># Handling HTTPS requests
> ># https_port 3130 intercept ssl-bump generate-host-certificates=3Don
> >dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
> >https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=3D100MB
> >cert=3D/etc/squid/squid.pem
> >acl SSL_port port 443
> >
> ># AWS services domain
> >acl allowed_https_sites ssl::server_name .amazonaws.com
> ># docker hub registry
> >acl allowed_https_sites ssl::server_name .docker.io
> >acl allowed_https_sites ssl::server_name .docker.com
> >
> ># project specific
> >acl allowed_https_sites ssl::server_name www.congiu.net
> >acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
> >acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca
> >
> ># nslookup resolved IPs for collectors.sumologic.com
> ># workaround solution to support sumologic collector
> >acl allowed_https_sites ssl::server_name .sumologic.com
> ># THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
> ># acl allowed_https_sites ssl::server_name --server-provided
> >service.sumologic.com sslflags=3DDONT_VERIFY_PEER
> ># acl allowed_https_sites ssl::server_name --server-provided
> >service.us2.sumologic.com sslflags=3DDONT_VERIFY_PEER
> >
> >acl step1 at_step SslBump1
> >acl step2 at_step SslBump2
> >acl step3 at_step SslBump3
> >
> >ssl_bump peek step1 all
> >ssl_bump peek step2 allowed_https_sites
> >#
> >http://lists.squid-cache.org/pipermail/squid-users/2018-September/019150=
.html

> >ssl_bump bump
> >ssl_bump splice step3 allowed_https_sites
> >ssl_bump bump
> >ssl_bump terminate step2 all
> >
> >http_access allow CONNECT
> >
> ># http_access allow SSL_port
> >
> >http_access deny CONNECT !allowed_https_sites
> >http_access deny CONNECT !allowed_http_sites
> >http_access allow allowed_https_sites
> >http_access allow allowed_http_sites
> >http_access deny all
> >
> >cache deny all
> >
> >debug_options "ALL,9"
> >_______________________________________________
> >squid-users mailing list
> >[hidden email]
> >http://lists.squid-cache.org/listinfo/squid-users
>
> --
> Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet=
.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/2018=
1211/f46270b6/attachment-0001.html>

>
> ------------------------------
>
> Message: 3
> Date: Wed, 12 Dec 2018 12:07:49 +1300
> From: Amos Jeffries <[hidden email]>
> To: [hidden email]
> Subject: Re: [squid-users] SslBump Peek and Splice using Squid-4.1-5
>         in Amazon1 Linux with Squid Helpers
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=3Dutf-8
>
> On 12/12/18 6:53 am, Enrico Heine wrote:
> > Dear Mike,
> >
> > Please checkout the following and let us know if you need further help.
> >
> > http://www.squid-cache.org/Doc/config/sslproxy_cert_error/
> >
>
> Before you use it though, please consider what the words "Certificate
> does not match domainname" actually *mean*.
>
> This Squid is configured to deliver a single specific custom-built
> certificate to all clients who contact the proxy. Yet the proxy is being
> used to receive TLS traffic for any domain and the admin is passing test
> traffic for multiple different domains and raw-IP addresses.
>
>
>
> > Best regards,
> >
> > Flashdown
> >
> > Am 11. Dezember 2018 16:41:56 MEZ schrieb Mike Quentel:
> >
> >     Hi, I have been unsuccessfully trying to get Squid-4.1-5 in AWS
> >     (Amazon 1 Linux) to allow transparent proxy of certain domains, as
> >     well as IPs associated with those domains, whilst rejecting everyth=
ing

> >     else.
> >
> >     I have been referencing documentation at
> >     https://wiki.squid-cache.org/Features/SslPeekAndSplice
> >
> >     Version of Squid: 4.1-5 for Amazon 1 Linux available at
> >     http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/ (many thanks to
> >     @elico for these packages) specifically, the following:
> >
> >     1) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-4.1-5.a=
mzn1.x86_64.rpm
> >     2) http://faster.ngtech.co.il/repo/amzn/1/beta/x86_64/squid-helpers=
-4.1-5.amzn1.x86_64.rpm
> >
> >     Example of tests that I am running:
> >
> >     1) curl -kv https://service.us2.sumologic.com (EXPECTED: successful=
ly

> >     accessed; OBSERVED: successfully accessed)
>
> The TLS SNI contains "service.us2.sumologic.com", and
>  - the server produced an X.509 certificate for that domain, and
>  - your server_name ACL matches it as a sub-domain of ".sumologic.com"
>
>
> Note that the -k parameter for curl only disables security on the
> curl<->Squid TSL connection. It has nothing to do with the
> Squid<->origin connections.
>
> You should really be using "curl --cacert /etc/squid/squid.pem" or
> connections without the -k to test what actually happens for clients
> when their traffic goes through your system.
>
>
> >     2) curl -kv https://54.149.155.70 (EXPECTED: successfully accessed
> >     because it resolves to service.us2.sumologic.com; OBSERVED:
> >     "Certificate does not match domainname"  [No Error] (TLS code:
> >     SQUID_X509_V_ERR_DOMAIN_MISMATCH))
>
> IMO the expectation is what is wrong here.
>
> The TLS SNI does not exist, and
>  - being intercepted traffic the CONNECT authority is
> "54.149.155.70:443", and
>  - the server produced an X.509 certificate with SubjectName of either
> "54.149.155.70" or something else not matching your server_name ACL entri=
es.

>
> FYI: server_name is a text-string matching ACL. I expect you will find
> there is no reverse-DNS being performed during the ssl_bump testing,
> only later after contact the server has already been decided to allow.
> You can confirm that with the debug log your test produced. Look for the
> lines saying what each ACL is checking for and against.
>
>
> >     3) curl -kv https://www.google.com (EXPECTED: failed to access;
> >     OBSERVED: failed to access)
>
> "failed to access" is a gross over-simplification. This transaction is
> both allowed and not-allowed at the same time.
>
> If you look into the log I expect you will see this sequence happening:
>
>  * the http_access rules *allow* the CONNECT tunnel, then
>
>  * the ssl_bump rules select do "bump" action at Step-2 (aka. using only
> the TLS clientHello details), then
>
>  * curl -k ignores the small problem that you are not presenting the
> X.509 keys belonging to Google.
>
>  * the decrypted GET request inside the tunnel gets rejected because:
>  - the "allowed_https_sites" ACL has no X.509 server details to test
> against, so does not match.
>   - the "allowed_http_sites" ACL does not match either
>   - the "http_access deny all" matches everything reaching it.
>
>
> >     4) curl -kv https://172.217.13.164 (EXPECTED: failed to access;
> >     OBSERVED: "Certificate does not match domainname"  [No Error] (TLS
> >     code: SQUID_X509_V_ERR_DOMAIN_MISMATCH))
>
> Same thing going on as for test (2).
>
>
> >
> >     Below is the latest version of the squid.conf being used. Apologies
> >     for any obvious errors--new to Squid here. I have been grappling wi=
th
> >     this for weeks, with many iterations of squid.conf so any advice is
> >     greatly appreciated; many thanks in advance.
> >     -------------------------------------------------------------------=
-----

> >     visible_hostname squid
>
> You have connected this proxy to the Internet. The above is required by
> Internet RFCs to be a FQDN (fully qualified domain name).
>
> Even if you do not want to follow that requirements it MUST be a unique
> name.  If any of your HTTP traffic ever goes through another proxy
> sharing this *very common* config mistake you will encounter forwarding
> loop errors.
>
>
> >
> >     host_verify_strict off
>
> This is the default. No need to configure it.
>
> Also, if you added that because the errors you mentioned are talking
> about domain verification - be aware that HTTP "Host:" header
> verification is quite a different thing from TLS certificate verification=
.

>
>
> >
> >     # Handling HTTP requests
> >     http_port 3128
> >     http_port 3129 intercept
> >
> >     sslcrtd_children 10
> >
> >     acl CONNECT method CONNECT
> >
> >     # AWS services domain
> >     acl allowed_http_sites dstdomain .amazonaws.com
> >     # docker hub registry
> >     acl allowed_http_sites dstdomain .docker.io
> >     acl allowed_http_sites dstdomain .docker.com
> >     acl allowed_http_sites dstdomain www.congiu.net
> >
> >     # Handling HTTPS requests
> >     # https_port 3130 intercept ssl-bump generate-host-certificates=3Do=
n
> >     dynamic_cert_mem_cache_size=3D100MB cert=3D/etc/squid/squid.pem
> >     https_port 3130 intercept ssl-bump dynamic_cert_mem_cache_size=3D10=
0MB

> >     cert=3D/etc/squid/squid.pem
>
> FYI: both the lines above behave identical because the generate-*
> setting you removed was being set to its default value anyway.
>
>
> >     acl SSL_port port 443
> >
> >     # AWS services domain
> >     acl allowed_https_sites ssl::server_name .amazonaws.com
> >     # docker hub registry
> >     acl allowed_https_sites ssl::server_name .docker.io
> >     acl allowed_https_sites ssl::server_name .docker.com
> >
> >     # project specific
> >     acl allowed_https_sites ssl::server_name www.congiu.net
> >     acl allowed_https_sites ssl::server_name mirrors.fedoraproject.org
> >     acl allowed_https_sites ssl::server_name mirror.csclub.uwaterloo.ca
> >
> >     # nslookup resolved IPs for collectors.sumologic.com
> >     # workaround solution to support sumologic collector
> >     acl allowed_https_sites ssl::server_name .sumologic.com
> >     # THE FOLLOWING TWO LINES DO NOT SEEM TO WORK AS EXPECTED
>
> The expectation is wrong here.
>
> The string "sslflags=3DDONT_VERIFY_PEER" is not a valid domain nor server
> hostname. So highly unlikely that the X.509 certificate SubjectName or
> AltSubjectName from the origin server will contain that string.
>
> Also, the flag sets the ACL matching algorithm. When that is set the ACL
> cannot match during a ssl_bump "peek step1" cycle.
>
> So one should expect this ACL to stop working when these lines are
> added. Not expect that it would do anything useful.
>
>
> FYI: The string "sslflags=3DDONT_VERIFY_PEER" is the name and value of a
> option other directives elsewhere in squid.conf can use. But it is a
> very, very, very bad idea to do so - even 'just for testing'.
>
>  The flag DONT_VERIFY_PEER disables all of TLS security checks - meaning
> the connection actively becomes *less* safe than regular/plain-text TCP
> connections, while simultaneously hiding all resulting issues from
> *your* admin view. Users still have problems, you just cannot see any
> hint of them.
>  So please purge that setting from any configs and documents you come
> across. Investigate and fix any TLS problems that appear, don't just
> hide the error messages and pretend everything works.
>  Same reason not to be using the equivalent "curl -k" option for testing
> TLS validation/verification problems.
>
>
>
> >     # acl allowed_https_sites ssl::server_name --server-provided
> >     service.sumologic.com sslflags=3DDONT_VERIFY_PEER
> >     # acl allowed_https_sites ssl::server_name --server-provided
> >     service.us2.sumologic.com sslflags=3DDONT_VERIFY_PEER
> >
> >     acl step1 at_step SslBump1
> >     acl step2 at_step SslBump2
> >     acl step3 at_step SslBump3
> >
> >     ssl_bump peek step1 all
>
> The "all" here is useless and only adds confusion to anyone who thinks
> it has any meaning.
>
>
> >     ssl_bump peek step2 allowed_https_sites
> >     # http://lists.squid-cache.org/pipermail/squid-users/2018-September=
/019150.html

>
> The author of that did not understand how the ssl-bump processing was
> working. That entire message thread is them attempting to learn and IMO
> still not quite understanding the ideas in the end.
>
> Blindly copying into your config from experiments by someone who does
> not understand what they are doing is not a good idea. Use an actually
> known-working config example (the Squid wiki has several), or try to
> design your own based on your own understanding. At the very least we
> can see from your self-designed attempt what you may be thinking and
> hopefully teach you where any mistakes are visible.
>
>
> >     ssl_bump bump
>
> Please be aware that when this line when reached at step2 it performs
> "client-first" bumping of the TLS.
>
> That means bumping and performing TLS handshake without any real X.509
> server details for your allowed_https_sites ACL to use. Only
> client-provided claims about what server they are contacting (which may
> be outright lies). This has side-effects on what your ssl::server_name
> vs dstdomain ACL do in the later http_access checks.
>
> Specifically when the server_name and the URL domain are different
> things a simple as testing one first can change permissions for the
> client in the other.
>
>
> >     ssl_bump splice step3 allowed_https_sites
>
> So some of your traffic will splice from the above line - but only
> because of the peek (step2) then bump (step3) combination being impossibl=
e.

>
>
> >     ssl_bump bump
>
> There is already an unrestricted "bump" action earlier. This line does
> nothing even if it were possibly reached.
>
>
> >     ssl_bump terminate step2 all
>
> There is a peek action specified earlier for step2, with an unrestricted
> bump action as a fallback when allowed_https_sites fails to match. This
> line is never reachable.
>
> >
> >     http_access allow CONNECT
>
> Ouch. Really do not do the above. The default config file shipped with
> Squid starts with these lines for very good reasons:
>
> "
>   http_access deny !Safe_ports
>   http_access deny CONNECT !SSL_ports
>   http_access allow localhost manager
>   http_access deny manager
>
>   #
>   # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
>   #
> "
>
> Those reasons (DoS and proxy relay security vulnerabilities) are still
> very much relevant in your setup, with no reason to remove them. So
> please add them back before you continue testing things, with your
> custom http_access rules *underneath* that comment line.
>
> Also, the default SSL_ports is already setup in a way that meets your
> requirements. You can adjust Safe_ports to be only the same port, or use
> the default set of safe-for-HTTP ports.
>
> FYI: the config you have right now allows any malicious origin server
> receiving trafic on port 443 to present a X.509 certificate claiming to b=
e.

>
>
> >
> >     # http_access allow SSL_port
> >
> >     http_access deny CONNECT !allowed_https_sites
> >     http_access deny CONNECT !allowed_http_sites
>
> The above two lines do nothing in your current config. CONNECT requests
> are *always* allowed by the line you had earlier.
>
> Once you move back to the default security checks these will start to do
> things. It would probably be best to remove the two lines above to
> prevent the unexpected new behaviour from confusing you further.
>
>
> >     http_access allow allowed_https_sites
> >     http_access allow allowed_http_sites
>
> These ACLs are very badly named.
>
> * The one called "allowed_https_sites":
>  - will *not* match against HTTPS traffic arriving on port 3128 unless
> the CONNECT authority-uri names a domain in your list.
>
> - *will* match against HTTP traffic on port 3128 and port 3129 with
> "https://" URLs.
>
> * The one called "allowed_http_sites" *will* match against HTTPS traffic
> arriving on any port.
>
>  --> meaning that for both of them the "https" and "http" word in their
> name is deceptive.
>
> * Both these ACLs are used to *deny* traffic.
>  --> meaning the "allowed" word in their name is deceptive.
>
> What you are left with is just "sites" which is so vague as to be
> meaningless.
>
>
> It would be a lot clearer if you renamed them:
>  - "allowed_https_sites" to "tls_servers"
>  - "allowed_http_sites" to "url_domains"
>
>
> >     http_access deny all
> >
> >     cache deny all
> >
> >     debug_options "ALL,9"
>
> Cheers
> Amos
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
>
> ------------------------------
>
> End of squid-users Digest, Vol 52, Issue 13
> *******************************************
_______________________________________________
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