[squid-users] https full url

[xxiao8]

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 at lists.squid-cache.org 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 at lists.squid-cache.org 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 at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>