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 _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev