[squid-users] https full url

[Alex Rousskov]

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