[squid-dev] [PATCH] received_encrypted ACL

[Amos Jeffries]

On 23/07/2015 3:32 a.m., Alex Rousskov wrote:
> On 07/21/2015 04:25 AM, Amos Jeffries wrote:
>> On 21/07/2015 9:42 a.m., Alex Rousskov wrote:
>>>>> 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.
> 
> 
> I bet many (most?) of them are actually regular HTTP requests sent over
> TLS/SSL connections. There is nothing opportunistic about them.

That is the very definition of "opportunistic" in the related HTTP
documentation.

[Sorry wording gets flicked from "security" to "encryption" in those WG
threads a lot, didn't mean to bring it over here too].

RFC 7435 section 1.2 - A New Perspective
"
   "Opportunistic Security" (OS) is defined as the use of cleartext as
   the baseline communication security policy, with encryption and
   authentication negotiated and applied to the communication when
   available.
"

[Note that *when available* wording.]

http://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-02
"
   Serving "https" URIs require acquiring and configuring a valid
   certificate, which means that some deployments find supporting TLS
   difficult.  This document describes a usage model whereby sites can
   serve "http" URIs over TLS without being required to support strong
   server authentication.

   Opportunistic Security [RFC7435] does not provide the same guarantees
   as using TLS with "https" URIs; it is vulnerable to active attacks,
   and does not change the security context of the connection.
   Normally, users will not be able to tell that it is in use (i.e.,
   there will be no "lock icon").
"
[Note that *serve "http" URIs over TLS without being required* and *does
not change the security context of the connection* wording.]

Both HTTP and HTTPS are regular message syntax. Both MAY transit over
TLS. The *only* difference is the URL scheme name indicating whether TLS
layer security is mandatory or optional/opportunistic.

> 
>> 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*.
> 
> No requirement can _force_ something to be optional! If the use case

I think you misunderstand me.

The forcing applied is: optional->mandatory.

It is done by using the received_encrypted ACL. Apparently without admin
intending to.


> demands that requests received over TLS are sent to icapS service, then
> they should be sent to the icapS service, even if some of the
> corresponding request owners would not mind to see their requests going
> to the icapN service.

If you recall my very first words on this thread. I question the use-case.

 "I object to making this ACL available *for this use case*."
[new emphasis].


Look closely:

+    if (!(filled->request->sources & HttpMsg::srcUnsafe)  ||
+        (filled->reply && !(filled->reply->sources & HttpMsg::srcUnsafe)))
+        return 1;
+
+    return 0;

The permutations of match/non-match vs traffic source vs mask setters is
counter intuitive.

eg. when policy wants traffic only from TLS sources to use icapS the
rest to use icapN.

aka.
  adaptation_access icapS allow aclReceivedEncrypted
  adaptation_access icapN allow !aclReceivedEncrypted

aka.
 icapN to get used on the inverted union of whether both request and
reply are not unsafe.

aka.
   if (!0 || !0) ... icapS HTTPS proper handling (okay)
   if (!1 || !0) ... icapS opportunistic security (oops)
   if (!0 || !1) ... icapS opportunistic security (oops)
   if (!1 || !1) ... icapN HTTP normal handling (okay)


While I personally like the outcome (more security). Its clearly not
matching the use case presented as *sole* reason for the ACLs existence.
Nor the apparent admin policy in adaptation_access.


So I ask; why are we bothering with this ACL?
 Just use an https:// scheme match, which will only be true in the top
line of above if()-matrix. Admin *wanting* "opportunistic security"
should not be the ones trying to avoid using icapS in the first place.


[I think that sums up what we are debating over. So I will refrain from
replying to the other sidetrails we got into.]

Amos