for https/sslbump I can use sni::server_name to replace the "dstdomain"
directive, what about others URL-related directives, e.g., url_regex,
urlpath_regex, referer_regex,etc. Do they make sense at all when
https-url is concerned? or I have to ignore them when sslbump is activated?
Thanks for the helps, while I could get the ssl::server_name to work but
not the url* directives so far.
xxiao
On 01/15/2016 04:39 PM, Alex Rousskov wrote:
On 01/15/2016 02:38 PM, xxiao8 wrote:
I wonder if the decrypted https message after sslbump is used
by icap/ecap client code in squid,
It is.
or special handling is needed comparing to http-only proxying.
Normally, no special handling is required apart from bumping
transactions (which, of course, comes with a huge bag of headaches).
From an ICAP or eCAP service point of view, bumped HTTPS transactions
look pretty much like regular HTTP transactions (with an https URI
scheme, but that scheme is not unique to bumped transactions).
HTH,
Alex.
On 01/15/2016 11:56 AM, squid-users-request@xxxxxxxxxxxxxxxxxxxxx wrote:
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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
