[squid-users] deny_info and CONNECT for https request gives SSL error

[Amos Jeffries]

On 18/10/18 1:08 AM, Amish wrote:
> On 17/10/18 10:37 AM, Amos Jeffries wrote:
>> On 17/10/18 3:15 PM, Amish wrote:
>>> My proposal for would be to add "-n" (nobump) option to deny_info.
>>>
>>> If -n is specified then squid will send 307 directly instead of 200.
>>>
>>> Case 1)
>>> deny_info http://192.168.1.1/blocked.html denyit
>>>
>>> Return with 200 and bump it (existing behaviour)
>>>
>>> Case 2)
>>> deny_info 3xx:http://192.168.1.1/blocked.html denyit
>>>
>>> Return with 200 and bump it (existing behaviour)
>>>
>>> Case 3)
>>> deny_info -n http://192.168.1.1/blocked.html denyit
>>>
>>> Return with 307 Temporary Redirect and Location: header
>>>
>>> Case 4)
>>> deny_info -n 302:http://192.168.1.1/blocked.html denyit
>>>
>>> Return with 302 Found and Location: header.
>>>
>>> Case 1 and 2 above applicable only for sslbump cases.
>>>
>>> For non-sslbump it already behaves as 3) and 4) above.
>>>
>>>
>>> This would not change anything for existing users who want existing
>>> behaviour.
>>>
>>> But allow people like me to *NOT* bump connection when deny_info is
>>> activated.
>>>
>> IMO the deny_info is very much the wrong place to be making such
>> decisions. Its purpose is to supply the *content* of the denial message
>> itself. Nothing about how that message gets delivered.
>>
>> If anything this would be an additional ssl-bump option on the port line
>> to say that traffic is not really being ssl-bump'ed despite the presence
>> of the ssl-bump setting.
> 
> If its additional ssl-bump option then it would become a global thing.
> 
> If its on deny_info then for some ACLs I can select to bump and for
> others not. (i.e. gives finer control)
> 
>> So think about that - why bother putting "ssl-bump" on the port in the
>> first place if the behaviour that option enables is not wanted to ever
>> happen?
> 
> I need SSL bump because I am bumping few domains and splicing rest.
> 

... and you have a third case:

 Replace TLS ServerHello with a plain-text HTTP 3xx response.

Your intended redirect of the CONNECT tunnel includes traffic where the
client has already sent the 0-RTT TLS clientHello along with the CONNECT.


> But for blocked domains I prefer browser to show "Proxy refused the
> connection" instead of SSL error.

When the proxy is *actually* refusing (403) the connection, that makes
sense. All the other non-200 status responses, including your 3xx
redirect also show that error page generated by the Browser.

Bumping is forced on us by that Browser behaviour. Without the bump your
redirect response has zero chance of working as you obviously want it
to. If you were happy with the Browsers error page you would not be
trying to redirect the CONNECT.


> 
> Also browsers not respecting code other than 200 or 407 is actually a
> browser bug. Hopefully corrected in future someday.
> 

We call it a bug they call it intentionally designed behaviour.

Browsers used to support non-200 responses. That support has actively
and systematically been removed.



> May be browsers will start supporting 302/307 Location header someday,
> for CONNECT requests too?

They used to support 301 until early 2010's. Then it was replaced with
that blanket "Proxy is refusing connections" error message on grounds
that MITM proxies were using 301 to display content to users.


> 
> (ofcourse I am not RFC expert so I may be completely wrong to interpret it)
> 

These issues have nothing to do with the RFCs (which mandate proxy
support), and everything to do with Browser folks interests and design
choices being different from other folks needs and interests.

Amos