[squid-users] deny_info page not shown

[Alex Rousskov]

>> Amos Jeffries <squid3 at treenet.co.nz> wrote:
>>> CONNECT is a request to open a TCP connection. Delivering an HTTP
>>> page, or even a URL redirect in response to a TCP connection request
>>> is completely the wrong type of result.

>>> Like asking someone to open a door because you have a load of things
>>> needing to go through it - and they instead throw a basket of apples
>>> at you. Not want you expected, and more harm than good. 


On 8/28/20 4:31 AM, Matus UHLAR - fantomas wrote:
> when you ask via HTTP for HTTP page and get HTTP answer, it is different
> than asking via HTTP for CONNECT and getting CONNECT denied via HTTP.
> 
> in the latter case it is clear that the request was denied by proxy and
> since secure content was requested, the insecure response must not be
> shown.
> 
> That's the security provided.


I believe the above explanations and analogies are rather misleading!
There are no conceptual or protocol problems with HTTP error responses
to HTTP CONNECT requests. The browser knows where the response is coming
from. The browser knows that the response is an error. The browser
already anticipates and processes some error CONNECT responses specially
(think proxy authentication). There is no confusion, harm,
inappropriateness, or some new insecurity here!

What is actually happening (AFAICT) is that browser folks do not want to
spend their resources on properly informing the user of the error. There
are ways to do it, but they all require non-trivial work in a
controversial area, and browser folks simply do not consider this
specific use case important enough to support. At the end of the day,
you are not their customer. They do not want you as their customer. You
lost.


While opinions on the underlying causes may differ, the end result is
still the same -- a forward proxy cannot display an error page to a user
behind a popular browser in a modern environment (without bumping the
browser connection first).


Cheer,

Alex.