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@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Paul Carew
Sent: Tuesday, October 6, 2015 10:21 PM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: 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@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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
