Re: [squid-users] ACL based DNS server list

[Grant Taylor]

On 10/25/22 7:27 PM, Sneaker Space LTD wrote:

Hello,


Hi,

Is there a way to use specific DNS servers based on the user or 
connecting IP address that is making the connection by using acls or any 
other method? If so, can someone send an example.


"Any other method" covers a LOT of things.  Including things outside of 
Squid's domain.


You could probably do some things with networking such that different 
clients connected to different instances of Squid each configured to use 
different DNS servers.  --  This is a huge hole in the ground and can 
cover a LOT of things.  All of which are outside of Squid's domain.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ACL based DNS server list

[ngtech1ltd]

Hey James,
 
No it’s not possible.
There is a possibility to run a single proxy per client however you should 
really try to make sense in doing so.
 
Eliezer
 

Eliezer Croitoru
NgTech, Tech Support
Mobile: +972-5-28704261
Email:   ngtech1...@gmail.com
Web:   https://ngtech.co.il/
My-Tube:   https://tube.ngtech.co.il/
 
From: squid-users  On Behalf Of 
Sneaker Space LTD
Sent: Wednesday, 26 October 2022 4:27
To: squid-users@lists.squid-cache.org
Subject: [squid-users] ACL based DNS server list
 
Hello,
 
Is there a way to use specific DNS servers based on the user or connecting IP 
address that is making the connection by using acls or any other method? If so, 
can someone send an example.
 
Thanks,
James
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] FW: Encrypted browser-Squid connection errors

[squid3]

On 2022-10-23 06:10, Grant Taylor wrote:

On 10/21/22 11:30 PM, Amos Jeffries wrote:
Not just convention. AFAICT was formally registered with W3C, before 
everyone went to using IETF for registrations.


Please elaborate on what was formally registered.  I've only seen 3128 
/ 3129 be the default for Squid (and a few things emulating squid).  
Other proxies of the time, namely Netscape's and Microsoft's 
counterparts, tended to use 8080.


I'd genuinely like to learn more about and understand the history / 
etymology / genesis of the 3128 / 3129.


Duane W. would be the best one to ask about the details.

What I know is that some 10-12 years ago I discovered an message by 
Duane mentioning that W3C had (given or accepted) port 3128 for Squid 
use. I've checked the squid-cache archives and not seeing the message.


Right now it looks like the W3C changed their systems and only track the 
standards documents. So I cannot reference their (outdated?) protocol 
registry :-{ . Also checked the squid-cache archives and not finding it 
email history. Sorry.






FYI, discussion started ~30 years ago.


ACK


The problem:

For bandwidth savings HTTP/1.0 defined different URL syntax for origin 
and relay/proxy requests. The form sent to an origin server lacks any 
information about the authority. That was expected to be known 
out-of-band by the origin itself.


HTTP/1.1 has attempted several different mechanisms to fix this over 
the years. None of them has been universally accepted, so the problem 
remains. The best we have is mandatory Host header which most (but 
sadly not all) clients and servers use.


HTTP/2 cements that design with mandatory ":authority" pseudo-header 
field. So the problem is "fixed"for native HTTP/2+ traffic. But until 
HTTP/1.0 and broken HTTP/1.1 clients are all gone the issue will still 
crop up.


I'm not entirely sure what you mean by "the authority".  I'm taking it 
to mean the identity of the service that you are wanting content from. 
The Host: header comment with HTTP/1.1 is what makes me think this.




I mean "authority" as used by HTTP specification, which refers to 
https://www.rfc-editor.org/rfc/rfc3986#section-3.2



My understanding is that neither HTTP/0.9 nor HTTP/1.0 had a Host: 
header and that it was assumed that the IP address you were connecting 
to conveyed the server that you were wanting to connect to.


Yes exactly. That is the source of the problem, perpetuated by the need 
to retain on-wire byte/octet backward compatibility until HTTP/2 changed 
to binary format.


Consider what the proxy has to do when (not if) the IP:port being 
connected to are that proxy's (eg localhost:80) and the URL is only a 
path ("/") on an origin server somewhere else. Does the "GET / HTTP/1.0" 
mean "http://example.com/; or "http://example.net/; ?





More importantly the proxy hostname:port the client is opening TCP 
connections to may be different from the authority-info specified in 
the HTTP request message (or lack thereof).


My working understanding of what the authority is seems to still work 
with this.




The key point is that the proxy host:port and the origin host:port are 
two different authority and only the origin may be passed along in the 
URL (or URL+Host header). When the client uses port 80 and 443 thinking 
they are origin services it is *required* (per 
https://www.rfc-editor.org/rfc/rfc9112.html#name-origin-form) to omit 
the real origins info. Enter problems.



This crosses security boundaries and involves out-of-band information 
sources at all three endpoints involved in the transaction for the 
message semantics and protocol negotiations to work properly.


I feel like the nature of web traffic tends to frequently, but not 
always, cross security / administrative boundaries.  As such, I don't 
think that existence of proxies in the communications path alters 
things much.


Please elaborate on what out-of-band information you are describing. 
The most predominant thing that comes to mind, particularly with 
HTTP/1.1 and HTTP/2 is name resolution -- ostensibly DNS -- to identify 
the IP address to connect to.




I refer to all the many ways the clients may be explicitly or implicitly 
configured to be aware that it is talking to a proxy - such that it 
explicitly avoids sending the problematic origin-form URLs.



What that text does not say is that when they are omitted by the 
**user** they are taken from configuration settings in the OS:


  * the environment variable name provides:
     - the protocol name ("http" or "HTTPS", aka plain-text or 
encrypted)
     - the expected protocol syntax/semantics ("proxy" aka 
forward-proxy)


  * the machine /etc/services configuration provides the default port 
for the named protocol.


Ergo the use of /default/ values when values are not specified.


The defaults though are tuned for origin server (or reverse-proxy) 
direct contact.
No Browser I know supports