[squid-dev] [PATCH] received_encrypted ACL

[Amos Jeffries]

On 21/07/2015 9:42 a.m., Alex Rousskov wrote:
> 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).

Good you have seen those. That is what the HTTPbis WG call
"opportunistic encryption" traffic.

This is where the security requirements and your ACL use-case differ.
Security requirements for those requests is that they be handled as per
any other http:// - any encrytpion or security applied is *optional*.
recieved_encrypted ACL seems to assume they are broken HTTPS and matches
for them.

What I'm getting at here is that these are more good candidates for the
performance-oriented admin to skip ICAPS processing if they want. Even
though they were bumped. The new ACL fails to let that happen (in a good
way, but still).


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

No, this example eCAP taints it but leaves it as https://. So both the
inbound and outbound connections are fully using TLS. But the ACL
matches as if it were non-TLS connections.
 This will conflict with later cached handling, and logging info. Which
properly treats is as fully TLS received.


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

They expect that two fetches of the same URL from the same client one
MISS gets marked non-TLS-received the other HIT as TLS-received ?
 I see complaints in that future.

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

The original request that got cached never attached the ACL so whatever
processing was desired for applying to secure responses was never applied.
 The ACL is matching this insecure and tainted response as if it were
TLS received. So the non-secure processing that was suppsed to have been
omitted for it whas been done.

This is another situation where HIT vs MISS have opposite ACL reactions
for the same URL and content.


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

No. Christos wrote this:
"
NOTE: Currently there is not any mechanism to indicate if a cached
object came from secure source or not, so we assume that all hits for
secure requests are secure too.
"

The cache hits rely on the request markings to determine the HIT
matching. In this case we have a https:// (secure, TLS-received) marked
request being re-written with non-TLS URL and delivered a HIT originated
from a non-TLS server.



Amos