[squid-users] ICAP and HTTPS

Tue Oct 6 16:57:21 UTC 2015

Hey Paul,

 From what I have seen until now I believe that the ICAP service 
response is for a CONNECT request.
 From security reasons browsers are not allowing or rather then not 
implanting support for a direct HTTP response to a CONNECT(tunnel) requests.
This is why you see this reaction from the browsers.
using peek and splice would not change the behavior of the browsers and 
client and there for it will not change anything for this specific scenario.

However you can implement the inspection on the https level and not the 
CONNECT level which would work.
If somehow you will find the right way to pass or to not pass CONNECT 
requests to the ICAP service you might get to a situation which the 
CONNECT by itself is allowed(and not inspected by the ICAP service) and 
peek+splice would bump the connection and then the adaption(ICAP) 
service will analyze the wrapped http level inside the CONNECT request.
This way the browser will receive the ICAP service response on the http 
level and will show to the client the block page.

I know it is possible and Diladele solution does that already so there 
is some light for you.

The issue is that I have not implemented it yet and there for cannot 
give you instructions on how to implement it.

Eliezer

On 06/10/2015 19:14, Paul Carew wrote:
> Hi
>
> Just a quick question regarding SSL bump and ICAP.
>
> I have integrated Squid 3.5.9 with a commercial product that provides
> an ICAP service. It works fine for HTTP.
>
> Upon recieving an ICAP query for a blocked HTTP site the following
> ICAP response is returned.
>
> ICAP/1.0 200 OK
> ISTAG: "PRODUCTNAME"
> Attribute: Blocked Sites
> Encapsulated: res-hdr=0, null-body=148
>
> HTTP/1.0 302 Moved
> Location: http://192.168.0.10/block?session=12345678
> Pragma: no-cache
> Cache-Control: no-cache
>
> and the block page is correctly displayed in the users browser
>
> However, 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>
>    <head>
>      <meta http-equiv="refresh"
> content="0;url=http://192.168.0.10/block?session=12345678">
>      <title>Blocked</title>
>    </head>
>    <body>
>      <h4>You have been blocked.</h4>
>      <p>Click <a
> href="http://192.168.0.10/block?session=12345678">here</a> for
> details</p>
>    </body>
> </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?
>
> 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?
>
> Thank you
>
> Paul
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>