[squid-users] ICAP and HTTPS

Tue Oct 6 17:05:11 UTC 2015

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.