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:
On 17/10/18 8:28 PM, Alex Rousskov wrote:
Very true, but based on my interpretation of browser makers' feedback on
the HTTP WG mailing list, I doubt that will happen in the foreseeable
future: Adding a proxy "security context" (in addition to the existing
"insecure" and "origin" contexts) is not
On 10/16/2018 08:15 PM, Amish wrote:
> http_port 8080 ssl-bump ...
> http_access deny ...
> ssl_bump splice all
> In this case one would expect that squid would not bump the connection
> and return with 307 instead of 200.
FWIW, I do not think "one would expect" can be the driving argument for
d
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 bum
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)
>
On 16/10/18 10:07 PM, Alex Rousskov wrote:
On 10/16/2018 10:01 AM, Amish wrote:
Thing is that squid behaves differently for 2 exactly same CONNECT
request with only difference being ssl-bump
Yes, Squid behaves differently when configured differently.
* My original response was specific to Ssl
On 10/16/2018 10:01 AM, Amish wrote:
> On 16/10/18 9:05 PM, Alex Rousskov wrote:
>> On 10/16/2018 06:29 AM, Amish wrote:
>>> In my opinion correct flow should be like this:
>>>
>>> 1) Browser sends CONNECT request
>>> 2) Check ACL
>>> 3) If denied, return with 307 (or 302)
>>> 4) If allowed, go ahe
On 16/10/18 9:05 PM, Alex Rousskov wrote:
On 10/16/2018 06:29 AM, Amish wrote:
In my opinion correct flow should be like this:
1) Browser sends CONNECT request
2) Check ACL
3) If denied, return with 307 (or 302)
4) If allowed, go ahead with tunneling / bumping as applicable
Unfortunately, t
On 10/16/2018 06:29 AM, Amish wrote:
> It seems that current algorithm for ssl-bump is:
>
> 1) Browser sends CONNECT request
> 2) Squid sends status 200 Connection Established
> 3) Check ACL
> 4) If denied, bump the connection with squid certificate
> 5) If allowed, go ahead with tunneling / bump
Further to this:
I have ssl-bump setup on port 8080.
If I remove ssl-bump squid works just like I mentioned in my earlier e-mail.
> curl -ix 192.168.1.1:8080 https://google.com
HTTP/1.1 307 Temporary Redirect
Server: squid/4.3
Mime-Version: 1.0
Date: Tue, 16 Oct 2018 12:01:41 GMT
Content-Type:
Hello
I have this simplified ACL in squid.conf
acl denyit src all
deny_info http://192.168.1.1/blocked.html denyit
http_access deny denyit
The purpose is to block everything and redirect to
http://192.168.1.1/blocked.html
It works fine with http (non-secure) CONNECT request ...
> curl -ix 1
11 matches
Mail list logo
