[squid-users] ICAP and HTTPS

Wed Oct 7 00:50:05 UTC 2015

On 10/06/2015 06:05 PM, Rafael Akchurin wrote:
> 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!

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.

For Skype, SSH tunnels and other protocols that also use CONNECT
the ICAP server must block the CONNECT (if configured to do so).
There are even sites that use SSL+other protocol, so bumping such site may
initially seem OK since the SSL handshake was done without problems,
but since it is not followed by an HTTP protocol request, the ICAP server
will never see a followup HTTP GET/POST and hence will never be able to
block the site after it allowed the CONNECT.
So if the site must be blocked, the ICAP server must already decide what
to do when it receives a CONNECT request:
a) guess that the CONNECT is for SSL+HTTP, pass the CONNECT and wait for the followup GET/POST to be blocked, or
b) guess that the CONNECT is for a site that does not use SSL+HTTP and block the CONNECT.

Because of the above, I had a discussion a long time ago with the Squid developers
to extend Squid to send the (non-HTTP) content to the ICAP server in case
that the CONNECT tunnel does not have SSL+HTTP, but the implementation effort
was considered to be too much at that time.
If, however, this feature is implemented, the ICAP server no longer has to guess
and can always pass the CONNECT and decide later, knowing that it will either
receive an HTTP request or the non-HTTP content.

Best regards,
Marcus

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