[squid-dev] [PATCH] received_encrypted ACL

[Alex Rousskov]

On 07/20/2015 01:45 PM, Amos Jeffries wrote:
> On 21/07/2015 6:48 a.m., Alex Rousskov wrote:
>> On 07/20/2015 09:27 AM, Kinkie wrote:
>>> So in my opinion the easiest way to move the discussion forward is to:
>>
>>> 1. find one use-case which cannot be covered by existing features
>>
>> Absolute impossibility is too high of a bar, IMO. A lot of things are
>> possible with excessive amount of work and mind boggling complexity.
>> However, I can suggest this configuration sketch as one example where
>> the proposed ACL would be very handy if not essential:
>>
>> # A set of ports that may be changed depending on deployment.
>> # Some may be configured to bump traffic, some not. Some may intercept.
>> # The bumping ports do not bump everything (see ssl_bump below).
>> http_port port1 ssl-bump ...
>> https_port port2 ssl-bump ...
>> http_port port3 ...
>> https_port port4 ssl-bump ...
>>
>> # SslBumping rules (note that some of these ACLs cannot be computed
>> # until later bumping stages, some rules create fake CONNECT requests
>> # for adaptation services, and the order of rules is significant):
>> ssl_bump splice aclBump0
>> ssl_bump peek aclBump1
>> ssl_bump stare aclBump2
>> ssl_bump splice aclBump3
>> ssl_bump bump aclBump4
>>
>> # If all transaction messages were received over SSL or TLS
>> # connections, then send it to the ICAP service icapS. Otherwise,
>> # send it to icapN. The rules apply to all transactions, including
>> #  - plain http: transactions over plain connections to http_port,
>> #  - plain http: transactions over intercepted plain connections,
>> #  + plain http: transactions from bumped TLS connections,
>> #  + plain http: transactions from direct TLS connections to https_port,
>> #  + plain http: transactions from direct TLS connections to https_port
>> #  + fake CONNECT messages generated for bumped intercepted transactions


> The fake connect request was not "received over TLS".
> Conceptually it was a plain-TCP SYN received prior to TLS. No different
> in meaning to the non-fake CONNECT requests.

This is debatable for fake CONNECT requests that are based on SSL/TLS
information (SNI and such), but probably not worth discussing right now
because it is a minor issue. We should document how [different kinds of]
fake CONNECTs are classified.


>> adaptation_access icapS aclIcap
>> adaptation_access icapN !aclIcap
>>
>>
>> aclIcap can be a received_encrypted ACL. What ACL expression would you
>> suggest for aclIcap if received_encrypted is not available?
> 
> 
>   # top 5 criteria - TLS transactions
>   acl aclIcap allof HTTPS

What is "HTTPS" ACL? If it is based on the URI scheme, then AFAIK, it is
not going to work because it will not match bumped http:// requests (at
least).


>   # last 1 - the fake-CONNECTs but not the regular CONNECTs:
>   acl bumpPorts myportname port2 port4
>   acl aclIcap allof CONNECT !bumpPorts

I am not sure this is correct because there may be CONNECT requests
*inside* bumped SSL/TLS streams on port1 (at least):

 1. Receive CONNECT at http_port.
 2. Bump.
 3. Parse the first bumped HTTP request on the SSL/TLS channel.
 4. It is a CONNECT request!

Sorry, I do not remember what Squid does with these nested CONNECTs
right now, but they do exist in the wild.


> False-negative:
> 
> Imagine that icapN was REQMOD and icapS a RESPMOD service. With
> URL-rewrite, eCAP or such modification of the reply making it https://
> (tainted).

I assume you meant "making it http:// (tainted)".


> Using received_encrypted the transactions;
>  during request will match, so icapN does not get used.
>  during reply will not match, so icapS does not get used.

Kinkie has not asked for false-negatives so you are moving the goal
posts. More importantly, I do not see a false negative in your example.
Yes, an eCAP adaptation will "taint" the transaction, but it does not
lead to a "false negative", just a "true negative" (i.e., the negative
decision matches what the admin should expect in this case).

If those true negatives are not desirable, we will make that hard-coded
decision configurable by the admin (who knows whether the adaptation
service should "taint" -- Squid does not know that).


> False-positive:
> 
>  Imagine that icapS was REQMOD and icapN a RESPMOD service. Same
> modifications by url-rewriter. This time re-writing to http:// URL
> matching cached content.
> 
> Using received_encrypted the transactions;
>  during request will match, so icapS gets used.

Do you see this as a false positive? I assume you do not. If you do,
please explain why.


>  during reply will *still match*, so icapN does not get used

Cache hits do not go through RESPMOD services so this example does not work.

When/if somebody adds post-cache RESPMOD support, AFAICT, the icapN
_will_ get used because the current ACL implementation assumes that
cached content source corresponds to the cached URI scheme. Christos has
disclosed that simplification or shortcoming. Again, this is something
we can improve in the future if needed. We already have a blueprint for
better caching support actually.

I would not be surprised if you can create a false positive example if
you try harder. I am not sure we handle all the possible combinations of
URL rewriters, other adaptation services, and caching correctly today.
My point was not that false positives do not exist but that their
existence should not cause a patch rejection. It should cause
documentation improvements (and possible future work). False positives,
if they exist, do not make the feature not-useful to those who need it.


HTH,

Alex.