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

[Grant Taylor]

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.

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

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.

I have very little technical understanding of HTTP/2 as I've not needed 
to delve into it and it has largely just worked for me.

> And ... Squid still only supports HTTP/1.1 and older.

Okay.  That sort of surprises me.  But I have zero knowledge to disagree.

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

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

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

I feel like this in a round about way supports my stance that the 
default ports are perfectly fine to use.

> Attempting to use a reverse-proxy or origin server such a configuration 
> may work for some messages, but **will** fail due to syntax or semantic 
> errors on others.

I question the veracity of that statement.

Sure, trying to speak contemporary protocols (HTTP/1.1 or HTTP/2) to an 
ancient HTTP server is not going to work.

But I believe that Squid and Apache HTTPD can be configured to perform 
all three roles; origin server, reverse proxy, and forward proxy.

Aside:  Squid might not be a typical origin server in that you can't 
have it /directly/ serve /typical/ origin content.  However I believe it 
does function as an origin server for things like Squid error pages.

> Likewise NAT'ing inbound port 443 or port 80 traffic to a 
> forward-proxy will encounter the same types of issues - while it is 
> perfectly fine to do so towards a reverse-proxy or origin server.

I believe that is entirely dependent on the capability and configuration 
of the forward proxy.  --  I've done exactly this with Apache HTTPD. 
Though I've not had the (dis)pleasure of doing so with Squid.



-- 
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/20221022/8e0e1170/attachment.bin>