[squid-dev] [PATCH] received_encrypted ACL

[Alex Rousskov]

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
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?


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!


HTH,

Alex.