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

[Amish]

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.

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

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

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

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

In any case thank you for your responses. I have more clarity now.

Regards,

Amish.