Search squid archive

Re: Help with UA filtering in https connections

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/03/2018 05:52 AM, Matus UHLAR - fantomas wrote:
On 02.01.18 09:06, Alex Rousskov wrote:
On 01/02/2018 07:08 AM, Matus UHLAR - fantomas wrote:
On 02.01.18 06:04, squidnoob wrote:
http_access allow CONNECT safe_ports
http_access deny CONNECT

the two lines above unconditionally allow CONNECT anywhere,

This is incorrect. The lines deny CONNECT to unsafe ports.

Those lines unconditionally allow CONNECT requests to safe ports ANYWHERE,

On 03.01.18 08:55, Alex Rousskov wrote:
Yes, or, to be more precise, they (together with ssl_bump rules) allow
fetching of any server certificate from a reasonable(*) port. They do
not allow HTTP requests to arbitrary safe ports. Only Squid-generated
TLS handshakes.


which is apparently not what was wanted/expected.

Why not?

because there can be many reasons to deny CONNECT request for example
destined to localhost or internal network.

in the default config, these directives are at the beginning, before
checking for allowed clients and destinations is done.

in the provided config:
http://lists.squid-cache.org/pipermail/squid-users/2017-December/017267.html

there are no deny directives before "http_access allow SSL_port"
and so it's quite possible that all clients that should not have access will
be allowed.

of course, there MAY be other directives or measures to avoid that
but I really think it's better to put "deny CONNECT !SSL_ports"
than allow CONNECT and later wonder why some requests are not

that in this case you can[not] deny the connect request later,

Denying CONNECTs at step1 does not really work well in a general case
because, during SslBump step1, Squid does not have enough information to
generate the right certificate for the access denial error page.

I don't think this matters when we do have "http_access deny CONNECT" in
both cases.

In a general case, the admin has to pick between two evils:

* Allow TLS handshakes with arbitrary servers on TLS ports (my sketch)

* or tell Squid to respond with error pages that the user cannot see
 (without bypassing browser security warnings).

Which evil is lesser is up to the admin to decide. Needless to say,
there are environments where both strategies should be used, depending
on the transaction parameters.


(*) We should allow CONNECTs to SSL_ports, not Safe_ports. I hope my
sketch did not use those ACLs.

I'm afraid you did.
+and I'm also afraid that your proposal also prevents us from disabling
CONNECTs later:

http://lists.squid-cache.org/pipermail/squid-users/2017-December/017268.html

--
Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Atheism is a non-prophet organization. _______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux