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 service_req deny CONNECT adaptation_access service_req allow all Although I haven't tested this thoroughly yet, it appears to allow the initial tunnel creation but allow filtering of subsequent requests within those tunnels. Although I guess this will only work for bumped connections. Thanks Paul On 6 October 2015 at 18:05, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > 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 >> Pragma: no-cache >> Cache-Control: no-cache >> Location: http://192.168.0.10/block?session=12345678 >> >> <html> > ... >> </html> > > >> Chrome and IE just error upon receiving this response. In the case of >> Chrome I get an ERR_TUNNEL_CONNECTION_FAILED error. I could be wrong >> but I would imagine this error is by design, as Chrome will only >> respond to a proxy authentication request or SSL handshake in response >> to a HTTP CONNECT? > > Yes, this is by ["lazy"] browsers design (not specific to Chrome or IE). > > >> If that's correct, I was wondering if there is a way to get this to >> work, with peek and splice possibly or any alternative method? > > Yes, you have a few options: > > 1. Do not block CONNECT. Block the HTTP request after CONNECT instead. > This does not require Squid modifications, but may require ICAP service > modifications, including keeping state between HTTP requests. > > > 2. If you do not care about the actual error message displayed to the > user OR are OK with using [customizable] Squid error messages instead of > the ICAP-generated error messages, then you may: > > 2a. Teach Squid to treat certain ICAP responses as an instruction to > "block the virgin HTTP message". Squid eCAP client already supports that > (see 2d below). Squid ICAP client needs more work, including a decision > on how to define those "certain responses" in the ICAP context (should > probably be done via a new ACL-driven squid.conf directive). > > 2b. Teach the ICAP service to allow the CONNECT request but add an > extension HTTP header to it. Use adapted_http_access to block the > adapted CONNECT request. > > 2c. Teach Squid to use non-standard ICAP response headers as transaction > annotations (eCAP can do that already). Use adapted_http_access to block > the CONNECT transaction with your "blocking" annotations. > > 2d. Switch from ICAP to eCAP and use the existing > libecap::host::Xaction::blockVirgin() API. This option does not require > Squid development. > > > 3. If you must use ICAP-generated error messages and cannot use option > #1 above, then you can do either #2a or #2d _and_ also teach Squid to > save and serve the custom error message returned by the adaptation > service. This option requires [very] difficult Squid development work > (in addition to easier development work required by #2a), but it is > possible. > > > All of the above options require bumping the connection. There is no > other way to serve an error message to the user (because of the browsers > design). > > In the above text, "teach X to do Y" means "modify X code to > [optionally] do Y", including finding somebody who can perform those > source code modifications for you if needed. > > I believe the above options are reasonable/valid, but I have not tested > any of them with a recent stock Squid. YMMV. > > > HTH, > > Alex. > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
