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