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

Grant Taylor gtaylor at tnetconsulting.net
Wed Nov 2 02:35:49 UTC 2022


On 11/1/22 6:27 PM, squid3 at treenet.co.nz wrote:
> No, you cropped my use-case description. It specified a client which was 
> *unaware* that it was talking to a forward-proxy.

Sorry, that was unintentional.

> Such a client will send requests that only a reverse-proxy or origin 
> server can handle properly - because they have explicit special 
> configuration to do so.

ACK

> In all proxying cases there is special configuration somewhere. For 
> forward-proxy it is in the client (or its OS so-called "default"), for 
> reverse-proxy it is in the proxy, for interception-proxy it is in both 
> the network and the proxy.

ACK

> The working ones deliver an HTTP/1.1 302 redirect to their companies 
> homepage if the request came from outside the company LAN. If the 
> request came from an administrators machine it may respond with stats 
> data about the node being probed.

I suspect that Squid et al. could do similar.  ;-)

> Almost all the installs I have worked on had interception as part of 
> their configuration.

Fair enough.

> It is officially recommended to include interception as a backup 
> to explicit forward-proxy for networks needing full traffic control 
> and/or monitoring.

I've taken things one step further.  I forego the interception and 
simply have the firewall / router hard block traffic not from the proxy 
server.  }:-)

But short of that, I see and acknowledge the value of interception.

> I take it from your statement you have not worked on networks like 
> web-cafes, airports, schools, hospitals, public shopping malls who all 
> use captive portal systems, or high-security institutions capturing 
> traffic for personnel activity audits.

I have worked in schools, and other public places, some of which had a 
captive portal that intercepted to a web server to process registration 
or flat blocked non-proxied traffic.  The proxy server in those cases 
was explicit.

> There are also at least a half dozen nation states with national 
> firewalls doing traffic monitoring and censorship. At least 3 of the 
> ones I know of use Squid's for the HTTP portion.

I'm aware of a small number of such nation states.  I assume that there 
are many more.  I was not aware that Squid played in that arena.

> ACK. That is you. I am coming at this from the maintainer viewpoint 
> where the entire community's needs have to be balanced.

I maintain that the /default/ does not have to work for /all/ use cases.

I agree that the /default/ should work for /most/ use cases.

The current default doesn't work on servers using NLD Active API Server. 
  Ergo the current default doesn't work on /all/ use cases.  }:-)

> And you were specifying the non-default-'http-alt' port via the 
> "http://" scheme in yours.
> Either way these are two different HTTP syntax with different "default 
> port" values.
> 
> 
> An agent supporting the http:// URL treats it as a request for some 
> resource at the HTTP origin server indicated by the URL authority part 
> or Host header.
> 
> An agent supporting the http-alt:// URL treats it as a request to 
> forward-proxy the request-target specified in the URL query segment, 
> using the upstream proxy indicated by the URL authority part or Host 
> header.

If I'm understanding correctly, this is a case of someone asking Bob to 
connect to Bob.  That's not a thing.  Just talk directly to Bob.

> The ones I am aware of are:
>   * HTTP software testing and development
>   * IoT sensor polling
>   * printer network bootstrapping
>   * manufacturing controller management
>   * network stability monitoring systems

Why is anything developed in the last two decades green fielding with 
HTTP/0.9?!?!?!

> I doubt anyone can quantify it accurately. But worldwide use of HTTP/1.1 
> is also dropping, and at a faster rate than 0.9/1.0 right now as the 
> more efficient HTTP/2+ expand.

Sure.  There should be three categories of migrations:

HTTP/0.9 to something
HTTP/1.0 to something
HTTP/1.1 to HTTP/2

I sincerely hope that the somethings are going to HTTP/1.1 or HTTP/2.

> HTTP/1.1 specification requires semantic compatibility. So long as 1.1 
> is still a thing the older versions are likely to remain as well. 
> Undesirable as that may be.

ACK



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20221101/e1f47e47/attachment.bin>


More information about the squid-users mailing list