On 10/06/2015 06:50 PM, Marcus Kool wrote:
> The 2b) option a.k.a "simply always allow the CONNECT www.example.com and
> later block GET https://www.example.com/index.html"; _only_ works for
> correctly SSL-bumped sites and does not work sites that do not use
> SSL+HTTP.
If you want the user to se
message is not shown in simple words.
Best regards,
Rafael Akchurin
Diladele B.V.
-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf
Of Paul Carew
Sent: Tuesday, October 6, 2015 10:21 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [s
.
-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf
Of Paul Carew
Sent: Tuesday, October 6, 2015 10:21 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ICAP and HTTPS
Thanks Alex, Dieter & Eliezer
I've been trying t
Thanks Alex, Dieter & Eliezer
I've been trying to prevent the CONNECT request being processed by
ICAP and the following configuration in Squid 3.5.9 alongside a
standard SSL peek and splice config appears to work:
acl CONNECT method CONNECT
http_access deny CONNECT !SSL_ports
adaptation_access s
On 10/06/2015 10:14 AM, Paul Carew wrote:
> when accessing a blocked site over HTTPS the following ICAP
> response is received:
>
> ICAP/1.0 200 OK
> ISTAG: "PRODUCTNAME"
> Attribute: Blocked Sites
> Encapsulated: res-hdr=0, null-body=533
>
> HTTP/1.0 403 Blocked
> Content-Type: text/html
> Prag
Hey Paul,
From what I have seen until now I believe that the ICAP service
response is for a CONNECT request.
From security reasons browsers are not allowing or rather then not
implanting support for a direct HTTP response to a CONNECT(tunnel) requests.
This is why you see this reaction from th
