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

[squid3 at treenet.co.nz]

On 2022-11-02 09:03, Grant Taylor wrote:
> On 11/1/22 1:24 PM, squid3 wrote:
>> No I meant W3C. Back in the before times things were a bit messy.
> 
> Hum.  I have more questions than answers.  I'm not aware of W3C ever 
> assigning ports.  I thought it was /always/ IANA.
> 
>> Indeed, thus we cannot register it with IEFT/IANA now. The IANA 
>> http-alt port would probably be best if we did go official.
> 
> ACK
> 
>> You see my point I hope. A gateway proxy that returns an error to 
>> *every* request is not very good.
> 
> Except it's not "/ever/ /request/"  It's "/every/ /request/ /of/ /a/ 
> /specific/ /type/" where type is an HTTP version.
> 

No, you cropped my use-case description. It specified a client which was 
*unaware* that it was talking to a forward-proxy. Such a client will 
send requests that only a reverse-proxy or origin server can handle 
properly - because they have explicit special configuration to do so.

In all proxying cases there is special configuration somewhere. For 
forward-proxy it is in the client (or its OS so-called "default"), for 
reverse-proxy it is in the proxy, for interception-proxy it is in both 
the network and the proxy.


> What does CloudFlare or any of the other big proxy services or even 
> other proxy applications do if you send them an HTTP/1.0 or even 
> HTTP/0.9 request without the associated Host: header?
> 

The working ones deliver an HTTP/1.1 302 redirect to their companies 
homepage if the request came from outside the company LAN. If the 
request came from an administrators machine it may respond with stats 
data about the node being probed.


>> There is no "configured proxy" for this use-case.
>> 
>> Those are the two most/extremely common instances of the problematic 
>> use-cases. All implicit use of proxy (or gateway) have the same issue.
> 
> How common is the (network) transparent / intercepting / implicit use 
> of Squid (or any proxy for that matter)?
> 
> All of the installs that I've worked on (both as a user and as an 
> administrator) have been explicit / non-transparent.
> 

Almost all the installs I have worked on had interception as part of 
their configuration. It is officially recommended to include 
interception as a backup to explicit forward-proxy for networks needing 
full traffic control and/or monitoring.

I take it from your statement you have not worked on networks like 
web-cafes, airports, schools, hospitals, public shopping malls who all 
use captive portal systems, or high-security institutions capturing 
traffic for personnel activity audits.

There are also at least a half dozen nation states with national 
firewalls doing traffic monitoring and censorship. At least 3 of the 
ones I know of use Squid's for the HTTP portion.


>> I think you are getting stuck with the subtle difference between "use 
>> for case X" and "use by default".
>> 
>> ANY port number can be used for *some* use-case(s).
> 
> Sure.
> 
>> "by default" has to work for *all* use-cases.
> 
> I disagree.
> 

ACK. That is you. I am coming at this from the maintainer viewpoint 
where the entire community's needs have to be balanced.


>> Note that you are now having to add a non-default port "8080" and path 
>> "/" to the URL to make it valid/accepted by the Browser.
> 
> You were already specifying the non-default-http port via the 
> "http-alt://" scheme in your example.
> 

And you were specifying the non-default-'http-alt' port via the 
"http://" scheme in yours.
Either way these are two different HTTP syntax with different "default 
port" values.


An agent supporting the http:// URL treats it as a request for some 
resource at the HTTP origin server indicated by the URL authority part 
or Host header.

An agent supporting the http-alt:// URL treats it as a request to 
forward-proxy the request-target specified in the URL query segment, 
using the upstream proxy indicated by the URL authority part or Host 
header.


>> Clients speaking HTTP origin-form (the http:// scheme) are not 
>> permitted to request tunnels or equivalent gateway services. They can 
>> only ask for resource representations.
> 
> I question the veracity of that.  Mostly around said client's use of an 
> explicit proxy.
> 

It is clear side-effect of the fact that tunnels cannot be opened by 
requesting an origin-form URL (eg "/index.html"). They require an 
authority-form URI (eg "example.com:80").

See https://www.rfc-editor.org/rfc/rfc9110.html#name-intermediaries for 
definitions of intermediary and role scopes.
Note that it explicitly says (requires) absolute-URI for "proxy" (aka 
forward-proxy) intermediaries. Clients do not speak origin-form to 
explicit proxies.

[yes I know the first paragraph says an intermediary may switch 
behaviour based on just the request, that is for HTTP/2+. Squid being 
1.1 is more restricted by the legacy issues].


>> Port is just a number, it can be anything *IF* it is made explicit.
>> The scheme determines what protocol syntax is being spoken and thus 
>> what restrictions and/or requirements are.
>> 
>> ... and so the protocol for talking to a webcache service is 
>> http-alt://.
>> Whose default port is not 80 nor 443 for all the same reasons why 
>> Squid default listening port is 3128.
>> 
>> If we wanted to we could easily switch Squid default port to 
>> http-alt/8080 without causing technical issues. But it would be 
>> annoying to update all the existing documentation around the Internet, 
>> so not worth the effort changing now.
>> 
>> Ditto. Though the legacy install base has a long long long tail. 26 
>> years after HTTP/1.0 came out and HTTP/0.9 still has use-cases alive.
> 
> Where is HTTP/0.9 still being used?

The ones I am aware of are:
  * HTTP software testing and development
  * IoT sensor polling
  * printer network bootstrapping
  * manufacturing controller management
  * network stability monitoring systems


> 
>> Decreasing, but still a potentially significant amount of traffic seen 
>> by Squid in general.
> 
> Can you, or anyone else, quantify what "a potentially significant 
> amount of traffic" is?
> 

I doubt anyone can quantify it accurately. But worldwide use of HTTP/1.1 
is also dropping, and at a faster rate than 0.9/1.0 right now as the 
more efficient HTTP/2+ expand.


> Do these cases *really* /need/ to be covered by the /default/ 
> configuration?  Or can they be addressed by a variation from the 
> default configuration?

HTTP/1.1 specification requires semantic compatibility. So long as 1.1 
is still a thing the older versions are likely to remain as well. 
Undesirable as that may be.

Cheers
Amos