[squid-users] ICAP and HTTPS

Tue Oct 6 21:05:10 UTC 2015

Hello Paul, Eliezer, Alex,

We (diladele ICAP) have an open bug /feature requests for this:
	https://github.com/ra-at-diladele-com/qlproxy_external/issues/731
	https://github.com/ra-at-diladele-com/qlproxy_external/issues/726

As Alex described most probably we will do the 2b approach - although the work has not started yet.
Hope to be able to have something by the end of this year!

P.S. The http://docs.diladele.com/faq/squid/cannot_connect_to_site_using_https.html describes why the blocked message is not shown in simple words.

Best regards,
Rafael Akchurin
Diladele B.V.

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Paul Carew
Sent: Tuesday, October 6, 2015 10:21 PM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] ICAP and HTTPS

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.
>
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users