icap/ecap are both for content-adaptation instead of being a redirector,
which implies they can work on decrypted https content(after "bump")
that includes the "effective URL", i.e. the full request URL.
what's the right approach to do content analysis when https/MITM is
turned on in squid, it has to happen after the connection is bumped, to
do things like virus-scanning, content translation,etc, all need access
to the decrypted content, not just the authority-form URI.
Dansguardian does not do https, e2guardian only does explicit https,
icap is a tcp/ip connection so that may also need to be "encrypted"
again to make sure the clear-text bumped ssl traffic is not leaked
furthermore(assuming icap is installed remotely sometimes), maybe ecap
should be used for this?
http://www.icap-forum.org/documents/glossary/icap_cats.html
"ICAP for HTTPS : Decrypt/Re-encrypts HTTPS connections and sends the
HTTP messages to ICAP servers. "
https://answers.launchpad.net/ecap/+question/169016
Thanks,
xxiao
On 01/15/2016 04:49 AM, squid-users-request@xxxxxxxxxxxxxxxxxxxxx wrote:
On 15/01/2016 2:08 p.m., xxiao8 wrote:
>In Squid http-redirector can get access to the full url, for https
>sslbump only gives us the host(https://host), to get a full
>url(https://host/path), are the only choices icap/ecap for content
>filtering? in this case I really don't care about the https content
>payload, just its http header that contains the full URL.
ICAP/eCAP has nothing to do with it.
The URL path is encrypted, so only available*after* the "bump" decrypt
has happened.
Before the decrypt Squid only has access to the authority-form URI.
<http://tools.ietf.org/html/rfc7230#section-5.3.3>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
