Re: [squid-dev] Allowing the admin to decide if a specific DNS+ip is ok for caching.

[Eliezer Croitoru]

OK.

So we will try to make the whole environment more secure rather than more 
"profitable".
I think that in general it's a good concept and doesn't sound like some "OCD" 
alike issue.

I will try to write an article about 4.1 release with this point in mind.

Thanks,
Eliezer

* I do not really care if someone will think or thinks that my articles are 
profiting me in any way


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of 
Amos Jeffries
Sent: Thursday, July 19, 2018 10:46 AM
To: squid-dev@lists.squid-cache.org
Subject: Re: [squid-dev] Allowing the admin to decide if a specific DNS+ip is 
ok for caching.

On 19/07/18 04:56, Eliezer Croitoru wrote:
> Hey Squid-Dev’s,
> 
>  
> 
> Currently Squid-Cache forces Host Header Forgery on http and https requests.
> 
> -  https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
> 

Forces? no. Prevents.

> Squid is working properly or “the best” when the client and the proxy
> use the same DNS service.
> 
> In the past I have asked about defining a bumped connection as secured
> and to disable host header forgery checks on some of these.
> 

Having a connection be bumped does not mean the requests decrypted from
that connection are meant for that server. DONT_VERIFY_PEER and such
false "workaround" are still very common things for admin to do.

A client or intermediary can as easily forge the SNI value on TLS setup
as a Host header in plain-text HTTP. The resulting problems in both
cases are the same.



> The conditions are:
> 
> -  Squid validates that the server certificate is valid against
> the local CA bundles (an admin can add or remove a certificate manually
> or automatically)
> 
> -  The admin defines an external tool that verifies and/or
> allows host header forgery to be disabled per request.
> 
>  
> 
> I am in the middle of testing 4.1 and wondering what is expected from
> 4.1 regarding host header forgery.
> 
> Was there any change of policy?
> 

No changes from Squid-3 are expected in terms of these checks. There may
be changes in TLS handling which decrypt more (or less) requests.

Any requests which *are* decrypted, the initial CONNECT (from SNI) are
expected to be verified.
 TPROXY / NAT intercepted traffic is verified against the against the
dst-IP of the intercepted client TCP connection.
 Bumped and non-intercepted traffic (in strict verify mode) against the
server-IP from initial client CONNECT tunnel.

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

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

Re: [squid-dev] Allowing the admin to decide if a specific DNS+ip is ok for caching.

[Amos Jeffries]

On 19/07/18 04:56, Eliezer Croitoru wrote:
> Hey Squid-Dev’s,
> 
>  
> 
> Currently Squid-Cache forces Host Header Forgery on http and https requests.
> 
> -  https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery
> 

Forces? no. Prevents.

> Squid is working properly or “the best” when the client and the proxy
> use the same DNS service.
> 
> In the past I have asked about defining a bumped connection as secured
> and to disable host header forgery checks on some of these.
> 

Having a connection be bumped does not mean the requests decrypted from
that connection are meant for that server. DONT_VERIFY_PEER and such
false "workaround" are still very common things for admin to do.

A client or intermediary can as easily forge the SNI value on TLS setup
as a Host header in plain-text HTTP. The resulting problems in both
cases are the same.



> The conditions are:
> 
> -  Squid validates that the server certificate is valid against
> the local CA bundles (an admin can add or remove a certificate manually
> or automatically)
> 
> -  The admin defines an external tool that verifies and/or
> allows host header forgery to be disabled per request.
> 
>  
> 
> I am in the middle of testing 4.1 and wondering what is expected from
> 4.1 regarding host header forgery.
> 
> Was there any change of policy?
> 

No changes from Squid-3 are expected in terms of these checks. There may
be changes in TLS handling which decrypt more (or less) requests.

Any requests which *are* decrypted, the initial CONNECT (from SNI) are
expected to be verified.
 TPROXY / NAT intercepted traffic is verified against the against the
dst-IP of the intercepted client TCP connection.
 Bumped and non-intercepted traffic (in strict verify mode) against the
server-IP from initial client CONNECT tunnel.

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

[squid-dev] Allowing the admin to decide if a specific DNS+ip is ok for caching.

[Eliezer Croitoru]

Hey Squid-Dev's,

 

Currently Squid-Cache forces Host Header Forgery on http and https requests.

-  https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery

Squid is working properly or "the best" when the client and the proxy use
the same DNS service.

In the past I have asked about defining a bumped connection as secured and
to disable host header forgery checks on some of these.

The conditions are:

-  Squid validates that the server certificate is valid against the
local CA bundles (an admin can add or remove a certificate manually or
automatically)

-  The admin defines an external tool that verifies and/or allows
host header forgery to be disabled per request.

 

I am in the middle of testing 4.1 and wondering what is expected from 4.1
regarding host header forgery.

Was there any change of policy?

 

Thanks,

Eliezer

 



Eliezer Croitoru  
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



 

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