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

[Grant Taylor]

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.

It used to be a convention to allow smoking in public / government 
offices.  Now the convention is the exact opposite.

> Port 3128 has been set as default port by Squid for more than 2 
> decades.

Agreed.

> Don't expect a change.

I'm not expecting a change.

At most I was hoping for a discussion about it.

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.

> Secondly, like it was said already, servers and proxies are different 
> things.

Semantics are VERY important here.  HTTP daemons and proxy daemons are 
both servers.  They just serve slightly different things.

> And you need to understand the difference between forward and reverse 
> proxies.

Agreed.  I've been using / leveraging / exploiting (in a good way) a 
combination of forward and reverse proxies for multiple decades.  They 
are distinctly different, but yet still remarkably similar.

Squid, Apache's HTTPD, Nginx, and even contemporary IIS can act as both 
an HTTP(S) server (a.k.a. reverse proxy) and / or a forward proxy.

> Reverse proxies can sit on the regular ports because that's their 
> job -- to ask as origins.



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

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/?

Curl (and other things) will default to using the IANA defined port for 
`[protocol://]` if `[:port]` is unspecified.

So ... why do we /need/ to use a different port than what IANA has 
defined for `[protocol://]`?

I'm genuinely asking why we /need/ to use a different port.

What, other than convention or even port contention, is prompting us to 
use a port other than what IANA has defined for the protocol?

> And don't forget we used to have transparent proxies which kind of died 
> (I think?) thanks to TLS.

I question the veracity of /used/ /to/.

Yes, TLS made things more difficult.  But in a corporate (like) 
environment doing TLS monkey in the middle is quite possible with Squid.

I am and have been doing exactly that on my personal devices for the 
last two years.

> Port 3128 is for *forward* proxy setup.

That's by convention / Squid default.

I've run forward HTTP proxies on port 80 and forward HTTPS proxies on 
port 443 for years without any problems.  What's more is that it 
simplifies the client configuration by removing the need to specify the 
port.  The following works perfectly fine for curl, et al.

    export http_proxy="proxy.home.example"

So -- again -- why do we /need/ to use a different port?

I fully acknowledge /contention/ and /contention/.  If that's the answer 
to the question, then so be it.  But I'm not yet convinced of such.



-- 
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/20221021/bf38f1a1/attachment.bin>