Hello it's me again,
thanks for the hint with wget, this was very useful.
The problem with not redirect https to an errorpage is not solved but
this is okay. It's only a nice to have feature to redirect to an errorpage.
But I have a new problem, I want to have a transparent proxy for http
this works fine but when I add the iptables rule for https the loading
won't work.
With the config now you can bypass the blocking with using https, this
is not so good.
I think it's the same as the other problem I had, squid3 is not able to
read and understand the https traffic unless I break the https protocol.
But when I use the CONNECT method to tunneling the https traffic I
thought I can block the https sites with the transparent proxy.
Here is my iptables rule for https:
iptables -t nat -A PREROUTING -p TCP --dport 443 -j REDIRECT --to-port 3128
Here is my squid3 config file:
http_port 3128 intercept
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 2
cache_mem 32 MB
maximum_object_size 10000 KB
maximum_object_size_in_memory 32 KB
cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
cache_dir aufs /var/spool/squid3 2048 128 1024
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl net1 src 172.16.1.0/24
acl net2 src 172.16.2.0/24
acl net3 src 172.16.3.0/24
acl SSL_PORTS port 443
acl SAFE_PORTS port 21
acl SAFE_PORTS port 80
acl SAFE_PORTS port 443
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !SAFE_PORTS
http_access deny CONNECT !SSL_PORTS
http_access allow localhost
http_access allow net1
http_access allow net2
http_access allow net3
http_access deny all
Thanks for help!
best regards,
Michael
Bob Proulx <b...@proulx.com> wrote:
Sven Hartge wrote:
Michael I. wrote:
I tested around a bit with squid3+squidguard and I found out that the
redirect works with the Internet Explorer (IE 11).
Then I tested some other browser (firefox, chrome, ..) and with all
the other browser the redirect didn't work.
Be careful using browsers to test redirects because browsers strongly
cache results. It causes endless confusion with people. The network
wisdom is to test using tools such as wget and curl which don't cache
and look at the headers for verification.
wget -S -O/dev/null https://somesite.example.com/
The command line is preferred because it is a zillion times faster
than exiting the browser and flushing the browser cache manually
before every browser test. It avoids the possibility of a monkey
testing mistake.
Is there a bug in the Internet Explorer or is this because the IE
handle https on an other way?
Hard to guess since you never told us exactly what your configuration in
squid3, squidguard and the browser is, what exactly you do to get a
specific result (error page, redirected page, etc.).
I immediately suspect browser caching a previous redirect since that
has been a problem so many times before.
Bob
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5513ee85.5060...@abwesend.de
