On 17/01/16 06:16, xxiao8 wrote:
> Basically I'm trying to see how to get the http-header info from a
> bumped ssl connection and use them directly inside
> squid.conf(including external acl), otherwise icap/ecap is unavoidable
> for bumped ssl http header analysis.
You must have done it wrong. Fi
On 01/16/2016 10:16 AM, xxiao8 wrote:
> I understand the step1/2/3 for sslbump and Squid extracts the domain
> name at various steps(SNI, client hello, server hello,etc) and there is
> no guarantee which step will get what I want.
The stages I was talking about are not directly related to SslBump
Again thanks for the explanation.
I understand the step1/2/3 for sslbump and Squid extracts the domain
name at various steps(SNI, client hello, server hello,etc) and there is
no guarantee which step will get what I want.
Assuming the ssl is fully bumped(not spliced), that means their http
re
On 01/15/2016 07:52 PM, xxiao8 wrote:
> Just found out ssl::server_name_regex that should cover url_regex, for
> urlpath_regex and referer_regex I think I can not get them for
> https/sslbump, to get them an icap/ecap has to be used to read the
> decrypted content at the moment, will squid plan to
On 16/01/2016 3:52 p.m., xxiao8 wrote:
> Just found out ssl::server_name_regex that should cover url_regex,
> for urlpath_regex and referer_regex I think I can not get them for
> https/sslbump, to get them an icap/ecap has to be used to read the
> decrypted content at the moment, will squid plan to
Just found out ssl::server_name_regex that should cover url_regex, for
urlpath_regex and referer_regex I think I can not get them for https/sslbump,
to get them an icap/ecap has to be used to read the decrypted content at the
moment, will squid plan to provide directives similar to
urlpath_rege
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
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, o
Keep reading icap... it can modify a HTTP request (encapsulated and send
to icap server by squid's icap client), does this mean after sslbump I
can send a just-decrypted-clear-text http request-line and the related
header/message-body to icap server, or not?
Basically I wonder if the decrypted
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
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 http
11 matches
Mail list logo
