[squid-users] ICAP and HTTPS

Tue Oct 6 20:20:35 UTC 2015

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 at measurement-factory.com> 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.
>