[squid-dev] [PATCH] received_encrypted ACL

[Amos Jeffries]

On 21/07/2015 6:48 a.m., Alex Rousskov wrote:
> On 07/20/2015 09:27 AM, Kinkie wrote:
> 
>> sorry for butting in but I am a bit confused by this discussion, as it
>> seems to be straying from the technical merit; this is my attempt at
>> getting back to the core of the topic.
> 
> 
> Thank you for your help!
> 
> 
>> Amos claims that its stated objective can be achieved by other,
>> already-existing, features, and that it this proposal has a high
>> false-positive rate.
>>
>> 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.

Anyhow ...

> 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

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



> 
> IIRC, the deployed configuration (before received_encrypted was
> implemented) used "all" ACL for aclIcap because the admin could not come
> up with anything much better using existing ACLs.
> 
> 
>> 2a. claim that the false-positive scenarios found by Amos are either
>> intentional or not incorrect, OR
>> 2b. find ways to reduce the false positives in the scenarios hihglighted
>> by Amos, OR
>> 2c. rework the existing features (if possible) to allow the "early
>> detection" which is in my understanding the most touted benefit of the
>> proposed solution
> 
> I do not know what false positives you are talking about specifically,
> but in the above specific example, occasional false positives (if any)
> are OK. They simply increase the load on the icapS service. If there is
> a large number of them, then we may want to do more work, but keep in
> mind that we only need to improve the 100% "all" case that contains a
> huge number of false positives!

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).

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.


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.
 during reply will *still match*, so icapN does not get used


Amos