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

[Amos Jeffries]

On 22/10/22 06:04, Grant Taylor wrote:
> On 10/20/22 11:58 PM, Adam Majer wrote:
>> It's basically by convention now.
> 
> Sure.
> 
> Conventions change over time.
> 
> Long enough ago 3128 wasn't the conventional port for Squid.
> 

Not just convention. AFAICT was formally registered with W3C, before 
everyone went to using IETF for registrations.




> Maybe, hopefully, said discussion will spark an idea in at least one 
> person's head and that might turn into something in 10 or 20 years.
> 

FYI, discussion started ~30 years ago.


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.
  And ... Squid still only supports HTTP/1.1 and older.


> 
>> Forward proxies don't sit on regular server ports because they require 
>> explicit config on the client.
> 
> If we're explicitly configuring the client, then what does the port 
> that's chosen have any influence on the explicit configuration?


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


> 
> Curl's man page is rather convenient and somewhat supportive ~> telling:
> 
> ```
>         Using an environment variable to set the proxy has the same 
> effect as using the -x, --proxy option.
> 
>         http_proxy [protocol://]<host>[:port]
>                Sets the proxy server to use for HTTP.
> 
>         HTTPS_PROXY [protocol://]<host>[:port]
>                Sets the proxy server to use for HTTPS.
> ```
> 
> Notice how the `[:port]` is /optional/?
> 

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.


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


HTH
Amos