[squid-dev] Fake CONNECT requests during SSL Bump

[Alex Rousskov]

On 09/24/2015 11:08 AM, Eliezer Croitoru wrote:

> I think that in the design of such a service or "interface" there should
> be some marking of such eCAP-enabled ACLs to allow the helper do it's work.

The interface for eCAP-enabled ACLs is simple:

  acl <name> ask_adaptation_service <existing adaptation service name>

A REQMOD service receives a request header. A RESPMOD service receives
request and, if available, response headers. If the service responds
with ICAP 204 or equivalent, the ACL "matches". If the service does not
respond or responds with a different status, the ACL does not match.

Future enhancements may include:

1. configurable status (e.g., to treat 200 OK responses as a "match")
2. ICAP service support
3. fast ACLs support (see below)
4. custom deny_info responses via service responses
5. virgin body preview
6. full virgin body transfer

We could start by supporting only slow/async ACLs. They would be much
easier to support because the current adaptation service interface
itself is asynchronous.


> Just out of curiosity, what ACLs modules do you have in mind?

* The beginning of this email thread gives you one example.

* Virtually any existing eCAP or ICAP service currently used for
blocking messages. As Markus email on this thread says, most ICAP
services today are used for access control...

We have seen many problems where an ACL would be the best solution but
an external_acl helper is not (because it does not easily get the virgin
headers, does not get the virgin body, and/or cannot produce an HTTP
response message).

Alex.


> On 24/09/2015 18:12, Alex Rousskov wrote:
>>> >Most admins would be able to understand and write external_acl helpers
>>> >rather than an ICAP services.
>> This is not a sufficient reason to ban introduction of eCAP-enabled
>> ACLs, especially since one does not have to write an ICAP or eCAP
>> service to use it.
>>
>> Alex.
>>