Re: [squid-users] HTTPS woes

[Yuri Voinov]

13.04.2017 22:57, Olly Lennox пишет:
> Hi There,
>
> I've been battling for the last few days on a little project to setup a 
> Raspberry PI device as a small parental blocking server. I've managed to 
> configure the device to work as a transparent proxy using squid which is 
> assigned as the default gateway via DHCP and after a lot of messing about 
> I've finally got to the point where it's routing traffic correctly, proxying 
> and blocking unwanted websites over HTTP.
>
> The problem I have is that for the life of me I cannot get things to work 
> over HTTPS. It's working over the older, insecure web browsers where anything 
> goes but the more modern browsers will not accept the SSL certificates and 
> fail with insecure messages. I've tried various ways of generating a cert and 
> also generating a CA cert and signing my other cert with it to no avail. I've 
> had a mixture of errors back from the browser from WEAK_ALGORITHM to 
> BAD_AUTHORITY to INVALID_CERT.
>
> I've been using openssl to generate self-signed certificates and create a der 
> file. Below is a recent attempt but I've tried lots of different approaches:
>
> 
> openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout 
> squid.key -out squid.crt 
> openssl req -new -x509 -key squid.key -out squid.pem 
> openssl x509 -in squid.pem -inform pem -out squid.der -outform der
> 
>
>
> Then my config in Squid is like this, the dhparams file I generated as per 
> instructions in the squid wiki:
First of all: what's Squid's version?
>
> 
> http_port 3128 intercept
> https_port 3129 intercept ssl-bump generate-host-certificates=on 
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.crt 
> key=/etc/squid3/ssl_cert/squid.key options=NO_SSLv3 
> dhparams=/etc/squid3/ssl_cert/dhparam.pem 
You squid's built with interception support? show squid -v output.
>
> ssl_bump server-first all 
This  ^ option valid only up to Squid 3.4. If you
using 3.5.x, you should use new peek-n-splice rules.
> sslproxy_cert_error allow all 
> sslproxy_flags DONT_VERIFY_PEER 
 Don't do this. Never. This force
squid to ignore (and hide) all security issues with SSL from user and
from you.
> sslproxy_cipher 
> EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>  
>
> 
>
> The only routing rules I'm using are to forward port 80/443 to 3128/2129 
> respectively and also a POST_ROUTING "masquerade" rule which I got from a 
> guide (and I'm not sure I 100% understand!)
80/443 should be NATed to squid's box on squid's box.
>  
>
> Can anyone tell me where I'm going wrong? This is only for use on very small 
> networks (home router + 2 or 3 trusted devices and users) so security between 
> the rPI and the client is not a major concern - I just want it to work in the 
> most simple and foolproof way possible.
You doing wrong only one: you not give any important to resolve issue
information.
At least squid's version and build options.
>
> Any advice would be very welcome.
>
> Thanks,
>
> Olly
> oli...@lennox-it.uk
> lennox-it.uk
> tel: 07900 648 252
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
Bugs to the Future


0x613DEC46.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] HTTPS woes

[Olly Lennox]

Hi There,

I've been battling for the last few days on a little project to setup a 
Raspberry PI device as a small parental blocking server. I've managed to 
configure the device to work as a transparent proxy using squid which is 
assigned as the default gateway via DHCP and after a lot of messing about I've 
finally got to the point where it's routing traffic correctly, proxying and 
blocking unwanted websites over HTTP.

The problem I have is that for the life of me I cannot get things to work over 
HTTPS. It's working over the older, insecure web browsers where anything goes 
but the more modern browsers will not accept the SSL certificates and fail with 
insecure messages. I've tried various ways of generating a cert and also 
generating a CA cert and signing my other cert with it to no avail. I've had a 
mixture of errors back from the browser from WEAK_ALGORITHM to BAD_AUTHORITY to 
INVALID_CERT.

I've been using openssl to generate self-signed certificates and create a der 
file. Below is a recent attempt but I've tried lots of different approaches:


openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout squid.key 
-out squid.crt 
openssl req -new -x509 -key squid.key -out squid.pem 
openssl x509 -in squid.pem -inform pem -out squid.der -outform der



Then my config in Squid is like this, the dhparams file I generated as per 
instructions in the squid wiki:


http_port 3128 intercept
https_port 3129 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.crt 
key=/etc/squid3/ssl_cert/squid.key options=NO_SSLv3 
dhparams=/etc/squid3/ssl_cert/dhparam.pem 

#always_direct allow all 
ssl_bump server-first all 
sslproxy_cert_error allow all 
sslproxy_flags DONT_VERIFY_PEER 
sslproxy_cipher 
EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
 



The only routing rules I'm using are to forward port 80/443 to 3128/2129 
respectively and also a POST_ROUTING "masquerade" rule which I got from a guide 
(and I'm not sure I 100% understand!)
 

Can anyone tell me where I'm going wrong? This is only for use on very small 
networks (home router + 2 or 3 trusted devices and users) so security between 
the rPI and the client is not a major concern - I just want it to work in the 
most simple and foolproof way possible.


Any advice would be very welcome.

Thanks,

Olly
oli...@lennox-it.uk
lennox-it.uk
tel: 07900 648 252
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] [RFC] Changes to http_access defaults

[Alex Rousskov]

On 04/13/2017 10:39 AM, Alex Rousskov wrote:

> The "many folks misconfigure access rules" problem may not have a
> good solution (under Squid control); we should be careful not to make
> things worse while not solving the unsolvable problem.


Here is an alternative idea: Instead of adding default http_access rules
inside Squid, add an optional squid.conf lint/checker. For many
configurations, especially the simple ones used by new Squid admins, it
is fairly easy to _automatically_ check whether these default rules are
violated.

If these rules are violated, Squid will log a startup warning like this:

  WARNING: Your http_access rules allow CONNECT to unsafe port XXX.
  More info at http://...?warning=xyz=XXX.

The URL will detail the dangers and also explain how to disable this
specific warning or linting as a whole.

I can discuss/detail this further if there is consensus that automated
checking is overall better than built-in http_access defaults.
Unfortunately, I do not have the time to volunteer an implementation.


HTH,

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] [squid-dev] [RFC] Changes to http_access defaults

[Alex Rousskov]

On 04/13/2017 09:58 AM, Yuri Voinov wrote:
> 13.04.2017 21:14, Dan Purgert пишет:

>> How would a "built-in default" alter an existing setup? I mean, in
>> every other instance that I can think of, if the config file includes
>> the directive, the config file's version overrides the default ...

> This is normal behaviour. System administrator should have possibility
> to override ANY default.

That much is understood. What is not yet clear are the exact conditions
under which those defaults disappear. This is one of the two primary
questions the RFC does not answer yet (the other one being what exactly
this change is actually trying to accomplish).

"Normally", foo_bar defaults disappear at the first sign of an explicit
foo_bar rule in squid.conf. However, that will probably defeat the
(unspecified) purpose of supporting http_access defaults because every
Squid needs non-default http_access rules!

The suspected uselessness of "normal" behavior is exactly why those two
questions must be answered in the updated version of the RFC.

My earlier response sketched one way to add http_access defaults that do
not disappear so easily that they become useless (see
deny_unsafe_ports), but that idea has its own serious flaws. The "many
folks misconfigure access rules" problem may not have a good solution
(under Squid control); we should be careful not to make things worse
while not solving the unsolvable problem.

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] [squid-dev] [RFC] Changes to http_access defaults

[Yuri Voinov]

13.04.2017 21:14, Dan Purgert пишет:
> Quoting Alex Rousskov :
>
>> On 04/12/2017 12:16 PM, Amos Jeffries wrote:
>>
>>> Changes to http_access defaults
>>
>> Clearly stating what you are trying to accomplish with these changes may
>> help others evaluate your proposal. Your initial email focuses on _how_
>> you are going to accomplish some implied/vague goal. What is the goal
>> here?
>>
>>
>>> I have become convinced that Squid always checks those
>>> security rules, then do the custom access rules. All other orderings
>>> seem to have turned out to be problematic and security-buggy in some
>>> edge cases or another.
>>
>> s/Squid always checks/Squid should always check/
>>
>>
>>> What are peoples opinions about making the following items built-in
>>> defaults?
>>>
>>>  acl Safe_ports port 21 80 443
>>>  acl CONNECT_ports port 443
>>>  acl CONNECT method CONNECT
>>>
>>>  http_acces deny !Safe_ports
>>>  http_access deny CONNECT !CONNECT_ports
>>
>>> The above change will have some effect on installations that try to use
>>> an empty squid.conf.
>>
>> And on many other existing installations, of course, especially on those
>> with complex access rules which are usually the most difficult to
>> modify/adjust. In other words, this is a pretty serious change.
>>
>>
>
> How would a "built-in default" alter an existing setup? I mean, in
> every other instance that I can think of, if the config file includes
> the directive, the config file's version overrides the default ...
This is normal behaviour. System administrator should have possibility
to override ANY default.
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
Bugs to the Future


0x613DEC46.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] [squid-dev] [RFC] Changes to http_access defaults

[Dan Purgert]

Quoting Alex Rousskov :


On 04/12/2017 12:16 PM, Amos Jeffries wrote:


Changes to http_access defaults


Clearly stating what you are trying to accomplish with these changes may
help others evaluate your proposal. Your initial email focuses on _how_
you are going to accomplish some implied/vague goal. What is the goal here?



I have become convinced that Squid always checks those
security rules, then do the custom access rules. All other orderings
seem to have turned out to be problematic and security-buggy in some
edge cases or another.


s/Squid always checks/Squid should always check/



What are peoples opinions about making the following items built-in
defaults?

 acl Safe_ports port 21 80 443
 acl CONNECT_ports port 443
 acl CONNECT method CONNECT

 http_acces deny !Safe_ports
 http_access deny CONNECT !CONNECT_ports



The above change will have some effect on installations that try to use
an empty squid.conf.


And on many other existing installations, of course, especially on those
with complex access rules which are usually the most difficult to
modify/adjust. In other words, this is a pretty serious change.




How would a "built-in default" alter an existing setup? I mean, in  
every other instance that I can think of, if the config file includes  
the directive, the config file's version overrides the default ...


--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281


biniqniyftsiv.bin
Description: PGP Public Key


pgp16qIkBgS_N.pgp
Description: PGP Digital Signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy with simple iptable rule ...

[Arsalan Hussain]

Dear All,

Two things i want to share what i observed but didn't understand.

1-  it happens to HTTPS 443 websites like facebook, youtube, google mail
2-  it is squid configuration problem, because when i stop iptables the
same problem arise.

as given below access.log entries.  website give Error:
1492086861.068  33508 192.168.5.178 TAG_NONE/503 0 CONNECT
plus.google.com:443 - HIER_NONE/- -
1492086861.068  33506 192.168.5.178 TAG_NONE/503 0 CONNECT
connect.facebook.net:443 - HIER_NONE/- -
1492086861.068  32960 192.168.5.178 TAG_NONE/503 0 CONNECT
www.youtube.com:443 - HIER_NONE/- -
1492086861.068  30685 192.168.5.178 TAG_NONE/503 0 CONNECT
www.centos.org:443 - HIER_NONE/- -
1492086861.068  30659 192.168.5.178 TAG_NONE/503 0 CONNECT m.addthis.com:443
- HIER_NONE/- -
1492086861.068  30658 192.168.5.178 TAG_NONE/503 0 CONNECT
www.spinics.net:443 - HIER_NONE/- -


Interesting fact is that, after next refresh or open in new tab
(Mozila/Chrome) , The same website gets open fine after a while.

Really confusing one because sometime working and some time problem.

On Thu, Apr 13, 2017 at 4:46 PM, Arsalan Hussain 
wrote:

> Dear All,
>
> I am facing problem with iptable rules for squid 3.5.23. my simple squid
> configuration is attached and also iptable rules.
>
> It works fine when i restart squid, iptables, network services but after a
> while it give problem of slow speed or even rejecting packets in squid
> access.log
>
>  0 192.168.6.129 TAG_NONE/503 0 CONNECT s.youtube.com:443 -HIER_NONE/- -
>  0 192.168.6.129 TAG_NONE/503 0 CONNECT s.youtube.com:443 - HIER_NONE/- -
>
> when these kind entries shows in access.log websites do not open to user
> and they received message refused by proxy. (a routine access.log entries
> attached).
>
> If somebody assists me in this problem to solve it.
>
> With Regards,
>
>
> *Arsalan Hussain*
> *If you are too lazy to plow now, don't expect a harvest, later*
>



-- 
With Regards,


*Arsalan Hussain*
*Assistant Director, Networks & Information System*

*PRESTON UNIVERSITY*
Add: Plot: 85, Street No: 3, Sector H-8/1, Islamabad, Pakistan
Cell: +92-322-5018611
UAN: (51) 111-707-808 (Ext: 443)
*If you are too lazy to plow now, don't expect a harvest, later*
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid Proxy with simple iptable rule ...

[Arsalan Hussain]

Dear All,

I am facing problem with iptable rules for squid 3.5.23. my simple squid
configuration is attached and also iptable rules.

It works fine when i restart squid, iptables, network services but after a
while it give problem of slow speed or even rejecting packets in squid
access.log

 0 192.168.6.129 TAG_NONE/503 0 CONNECT s.youtube.com:443 -HIER_NONE/- -
 0 192.168.6.129 TAG_NONE/503 0 CONNECT s.youtube.com:443 - HIER_NONE/- -

when these kind entries shows in access.log websites do not open to user
and they received message refused by proxy. (a routine access.log entries
attached).

If somebody assists me in this problem to solve it.

With Regards,


*Arsalan Hussain*
*If you are too lazy to plow now, don't expect a harvest, later*
1492082727.375 126331 192.168.5.178 TCP_TUNNEL/200 1185 CONNECT 
apis.google.com:443 - HIER_DIRECT/172.217.23.142 -
1492082733.497 317889 192.168.5.178 TCP_TUNNEL/200 5638 CONNECT 
4-edge-chat.facebook.com:443 - HIER_DIRECT/157.240.7.20 -
1492082734.141   1354 192.168.6.130 TCP_TUNNEL/200 467 CONNECT 
clients4.google.com:443 - HIER_DIRECT/172.217.23.142 -
1492082741.315  35003 192.168.6.130 TAG_NONE/503 0 CONNECT www.facebook.com:443 
- HIER_NONE/- -
1492082741.315  33013 192.168.6.130 TAG_NONE/503 0 CONNECT www.facebook.com:443 
- HIER_NONE/- -
1492082741.315  33514 192.168.6.129 TAG_NONE/503 0 CONNECT 
r15---sn-25g7sner.googlevideo.com:443 - HIER_NONE/- -
1492082741.708  25111 192.168.5.165 TAG_NONE/500 0 CONNECT 
server21902.teamviewer.com:443 - HIER_DIRECT/217.146.8.3 -
1492082741.709  19092 192.168.5.165 TAG_NONE/500 0 CONNECT 
server21902.teamviewer.com:443 - HIER_DIRECT/217.146.8.3 -
1492082741.712  10060 192.168.5.165 TAG_NONE/500 0 CONNECT 
server21902.teamviewer.com:443 - HIER_DIRECT/217.146.8.3 -
1492082743.561 242726 192.168.6.129 TCP_TUNNEL/200 724 CONNECT 
youtubei.youtube.com:443 - HIER_DIRECT/172.217.23.142 -
1492082743.896  31001 192.168.6.129 TCP_TUNNEL/200 0 CONNECT 
r2---sn-o5t5uxa-pncs.googlevideo.com:443 - HIER_DIRECT/124.109.34.13 -
1492082751.850  28155 192.168.6.129 TCP_TUNNEL/200 151 CONNECT 
r2---sn-o5t5uxa-pncs.googlevideo.com:443 - HIER_DIRECT/124.109.34.13 -
1492082764.166   9420 192.168.6.130 TCP_TUNNEL/200 1938 CONNECT 
scontent-iad3-1.xx.fbcdn.net:443 - HIER_DIRECT/31.13.69.203 -
1492082764.166   3917 192.168.6.130 TCP_TUNNEL/200 952 CONNECT 
notifications.google.com:443 - HIER_DIRECT/172.217.23.142 -
1492082767.311  0 192.168.6.130 TAG_NONE/503 0 CONNECT www.facebook.com:443 
- HIER_NONE/- -
1492082769.326  0 192.168.6.130 TAG_NONE/503 0 CONNECT www.facebook.com:443 
- HIER_NONE/- -
1492082774.180   3883 192.168.6.130 TCP_TUNNEL/200 724 CONNECT 
clients6.google.com:443 - HIER_DIRECT/172.217.23.142 -
1492082774.180   3398 192.168.6.130 TCP_TUNNEL/200 1399 CONNECT 
clients6.google.com:443 - HIER_DIRECT/172.217.23.142 -
1492082775.299  0 192.168.5.178 TAG_NONE/503 0 CONNECT www.facebook.com:443 
- HIER_NONE/- -
1492082779.316  0 192.168.6.130 TAG_NONE/503 0 CONNECT www.facebook.com:443 
- HIER_NONE/- -
1492082781.319  0 192.168.6.130 TAG_NONE/503 0 CONNECT www.facebook.com:443 
- HIER_NONE/- -
1492082790.654  0 148.153.44.86 TAG_NONE/400 3987 GET / - HIER_NONE/- 
text/html
1492082794.210   2908 192.168.6.130 TCP_TUNNEL/200 1171 CONNECT 
googleads.g.doubleclick.net:443 - HIER_DIRECT/74.125.24.157 -
1492082794.210   7898 192.168.6.130 TCP_TUNNEL/200 4981 CONNECT 
www.youtube.com:443 - HIER_DIRECT/172.217.23.142 -
1492082798.320 119980 192.168.5.178 TCP_TUNNEL/200 4791 CONNECT 
apps.skype.com:443 - HIER_DIRECT/104.88.201.172 -
1492082805.251 118554 192.168.5.178 TCP_TUNNEL/200 5878 CONNECT 
mobile.pipe.aria.microsoft.com:443 - HIER_DIRECT/40.114.149.220 -
1492082811.161 124461 192.168.5.178 TCP_TUNNEL/200 5979 CONNECT 
mobile.pipe.aria.microsoft.com:443 - HIER_DIRECT/40.114.149.220 -
1492082816.898  86006 192.168.6.129 TCP_TUNNEL/200 6120423 CONNECT 
r2---sn-o5t5uxa-pncs.googlevideo.com:443 - HIER_DIRECT/124.109.34.13 -
1492082817.469 609736 192.168.6.129 TCP_TUNNEL/200 204106 CONNECT 
i1.ytimg.com:443 - HIER_DIRECT/172.217.23.142 -
1492082817.798 327546 192.168.6.129 TCP_TUNNEL/200 828 CONNECT 
securepubads.g.doubleclick.net:443 - HIER_DIRECT/172.217.24.98 -
1492082817.883 609479 192.168.6.129 TCP_TUNNEL/200 1285 CONNECT 
www.youtube-nocookie.com:443 - HIER_DIRECT/172.217.23.142 -
1492082818.494 609913 192.168.6.129 TCP_TUNNEL/200 1046 CONNECT 
clients1.google.com:443 - HIER_DIRECT/172.217.23.142 -
1492082818.605 538832 192.168.6.129 TCP_TUNNEL/200 611021 CONNECT 
i.ytimg.com:443 - HIER_DIRECT/172.217.23.142 -
1492082818.713 654038 192.168.6.129 TCP_TUNNEL/200 288016 CONNECT 
yt3.ggpht.com:443 - HIER_DIRECT/74.125.24.132 -
1492082818.902 517858 192.168.6.129 TCP_TUNNEL/200 2231 CONNECT 
www.googleadservices.com:443 - HIER_DIRECT/74.125.24.156 -
1492082819.224 610547 192.168.6.129 TCP_TUNNEL/200 9851 CONNECT 
googleads.g.doubleclick.net:443 - HIER_DIRECT/74.125.200.156 -
1492082819.393 505039 192.168.6.129 

Re: [squid-users] Squid 3.4.8 Reverse with multiple SSL Sites and multiple Certs/Domains

[Maik Linnemann]

Thanks for clarification and support the free work/world! i already tried nginx 
and it seems doing its job. I will keep an eye on squid 4 and what was said 
about the issues. 

Von: Amos Jeffries [squ...@treenet.co.nz]
Gesendet: Donnerstag, 13. April 2017 00:56
An: Maik Linnemann; squid-users@lists.squid-cache.org
Betreff: Re: AW: [squid-users] Squid 3.4.8 Reverse with multiple SSL Sites and 
multiple Certs/Domains

On 13/04/2017 7:13 a.m., Maik Linnemann wrote:
> I figured out that nginx is able to do what i want, at least SNI and
> multiple certs. I am forced to try that in the meantime. Also i will
> check varnish. Is there any realistic date when SNI is available in
> reverse proxy with squid? Is there anyone coding at all for that
> feature?
>

I've been working on it as part of the  GnuTLS support in Squid-4.
https_port can now be configured with multiple cert= key= parameter
pairs. But loading any past the first pair with OpenSSL builds is still
missing.

I _think_ all that is left now (for OpenSSL builds) is to alter that
logic loading cert= files into the server context. But I have not
investigated those details closely yet.

My focus in the 'free' work is getting GnuTLS working for Debian/Ubuntu
and refactoring for more easy porting to other backend libraries in
future (Fedora, RHEL and Apple want other libraries). I intend for SNI
to be usable out of the box with GnuTLS builds. Someone may do OpenSSL
changes to match by the time it goes public - I cannot test it so that
depends on others.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users