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

[Grant Taylor]

On 10/30/22 6:59 AM, squid3 at treenet.co.nz wrote:
> 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.

Did you by chance mean IANA?

I looked and 3128 is registered to something other than Squid.

Nor did their search bring anything up for Squid.

> I mean "authority" as used by HTTP specification, which refers to 
> https://www.rfc-editor.org/rfc/rfc3986#section-3.2
> 
> 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/" ?

I would hope that it would return an error page, much like Squid does 
when it can't resolve a domain name or the connection times out.

> 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).

Agreed.

> 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.

Why would a client (worth it's disk space) ever conflate the value of 
it's configured proxy as the origin server?

I can see a potential for confusion when using (network) transparent / 
intercepting proxies.

> 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.

ACK

> The defaults though are tuned for origin server (or reverse-proxy) 
> direct contact.

I don't see how that precludes their use for (forward) proxy servers.

> No Browser I know supports 
> "http-alt://proxy.example.com?http://origin.example.net/index.html" URLs.

But I bet that many browsers would support:

    http://proxy.example.com:8080/?http://origin.example.net/index.html

Also, I'm talking about "http://" and "https://" using their default 
ports of 80 & 443.

> ... "at your own risk" they technically might be. So long as you only 
> receive one of the three types of syntax there - port 80/443 being 
> officially registered for origin / reverse-proxy syntax.

I've been using them without any known problem for multiple years across 
multiple platforms, clients, and versions thereof.  So I'll keep using 
it at my own risk.

> It is based on experience. Squid used to be a lot more lenient and tried 
> for decades to do the syntax auto-detection. The path from that to 
> separate ports is littered with CVEs. Most notably the curse that keeps 
> on giving: CVE-2009-0801, which is just the trigger issue for a whole 
> nest of bad side effects.

I wonder how much of that problematic history was related to HTTP/0.9 vs 
HTTP/1.0 vs HTTP/1.1 clients.

I similarly wonder how much HTTP/1.0, or even HTTP/0.9, protocol is used 
these days.

Also, there is the elephant in the room of we're talking about a proxy 
server which is frequently, but not always, on a dedicated system or IP. 
  As such, I have no problem predicating the use of the HTTP(80) and 
HTTPS(443) ports when there is no possible chance of confusion between 
forward proxy roles and origin server / reverse proxy roles.



-- 
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/20221031/84078341/attachment.bin>