[squid-users] squid-users Digest, Vol 52, Issue 13
Mike Quentel
mike.quentel.rbc at gmail.com
Tue Dec 18 15:40:38 UTC 2018
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=on
dynamic_cert_mem_cache_size=100MB cert=/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, <squid-users-request at lists.squid-cache.org> wrote:
>
> Send squid-users mailing list submissions to
> squid-users at lists.squid-cache.org
>
> 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
> squid-users-request at lists.squid-cache.org
>
> You can reach the person managing the list at
> squid-users-owner at lists.squid-cache.org
>
> 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 <mike.quentel.rbc at gmail.com>
> To: squid-users at lists.squid-cache.org
> Subject: [squid-users] SslBump Peek and Splice using Squid-4.1-5 in
> Amazon1 Linux with Squid Helpers
> Message-ID:
> <CAE53ZLD9oqt0cUKsrwHSDo8nDEo2Midty0SFMFo842-3u9ovAw at mail.gmail.com>
> Content-Type: text/plain; charset="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.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"
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 11 Dec 2018 18:53:23 +0100
> From: Enrico Heine <flashdown at data-core.org>
> To: squid-users at lists.squid-cache.org, Mike Quentel
> <mike.quentel.rbc at gmail.com>
> Subject: Re: [squid-users] SslBump Peek and Splice using Squid-4.1-5
> in Amazon1 Linux with Squid Helpers
> Message-ID: <33156AE7-7EFA-4B8D-8B75-059534D73251 at data-core.org>
> Content-Type: text/plain; charset="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 at 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.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
> >squid-users at lists.squid-cache.org
> >http://lists.squid-cache.org/listinfo/squid-users
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20181211/f46270b6/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 12 Dec 2018 12:07:49 +1300
> From: Amos Jeffries <squid3 at treenet.co.nz>
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] SslBump Peek and Splice using Squid-4.1-5
> in Amazon1 Linux with Squid Helpers
> Message-ID: <15dc44bc-ef9e-02a6-f4bb-0d05087f5a3b at treenet.co.nz>
> Content-Type: text/plain; charset=utf-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 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
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
>
> ------------------------------
>
> End of squid-users Digest, Vol 52, Issue 13
> *******************************************
More information about the squid-users
mailing list