Search squid archive

Re: FW: Encrypted browser-Squid connection errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

<<attachment: smime.p7s>>

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux