[squid-users] SSL termination problem - squid's requests using https

[Amos Jeffries]

On 18/09/19 10:22 am, Alex Rousskov wrote:
> On 9/17/19 5:02 PM, Sam Holden wrote:
> 
>> When I have protocol=http is reports:
>> 2019/09/17 20:08:55| Accepting reverse-proxy HTTP Socket connections
> 
>> When I don't set the protocol is reports:
>> 2019/09/17 20:17:38| Accepting reverse-proxy HTTPS Socket connections
> 
>> So it seems to be following the protocol= for the incoming protocol
>> rather than just the outgoing.
> 
> Agreed. That (still) looks like a bug to me. [PROXY protocol prefix
> aside], an https_port ought to expect TLS traffic, regardless of any
> port tuning options, including the poorly named "protocol" option.
> 
> FWIW, I tried to quickly figure out what is really going on in the code,
> but ran out of time -- configuration parsing code does appear to
> overwrite the data member used as the incoming protocol of a listening
> port which makes no sense to me and contradicts documentation, but I am
> probably missing something in this mess. Hopefully, somebody else can
> help you triage this further.
> 

FYI: the protocol= current behaviour is initial support for the HTTP
versions where layering is not as simple as HTTP vs HTTPS. For example;
ICY, Secure-HTTP, h2, HTTP/3.


All these *_port things are a red herring. The initial problem was
connections to the origin server using HTTPS.

Connections to originserver peer do not send URL scheme, and use the
settings on the cache_peer directive as the protocol layering and
message framing. So the http(s)_port options should be having no input
into the problem. The problem is something in the unknown cache_peer
settings, or maybe a bug in the new peer selection code.

Amos