[squid-dev] [PATCH] received_encrypted ACL

[Amos Jeffries]

On 18/07/2015 7:08 a.m., Alex Rousskov wrote:
> On 07/17/2015 11:48 AM, Amos Jeffries wrote:
>> On 18/07/2015 3:13 a.m., Tsantilas Christos wrote:
>>> This patch adds received_encrypted ACL
>>>
>>> The new received_encrypted ACL matches transactions where all HTTP
>>> messages were received over TLS or SSL transport connections, including
>>> messages received from ICAP servers.
> 
>>> Use case: Sending everything to Secure ICAP services increases
>>> adaptation performance overhead. Folks want to send received_encrypted
>>> transactions and only those transactions to Secure ICAP services.
> 
> 
>> -1 on principle I object to making this ACL available for this use case.
> 
> 
> I must have read this wrong. You are not trying to block a useful
> feature simply because you dislike a specific use case, are you?

I am debating whether this is a "useful feature". The one (and only) use
case presented for its existence is flawed.


> 
> Given your comments below, it sounds like you misunderstood the use case
> itself, but even if you were right about that use case, blocking a
> feature based on a single use case seems a bit too harsh!
> 
> 
>> And the (very) long answer:
>>
>> This is conceptually very bad.
> 
> What exactly is "this" and why is it very bad?

what: The use-case behaviour being proposed as desirable.
why: for the reasons the rest of my mail was attempting to describe.

> 
>> * https:// scheme traffic is *supposed* to be kept secure no matter
>> what. Either they need to obey that requirement or they dont (due to
>> non-TLS security).
>>
>> * http:// and the other non-secure schemes are optional.
> 
>> Please do instead encourage using the request URI scheme ("proto" ACL)
>> to make that determination of whether ICAP security is desirable or not.
> 
> Looking at the request URI scheme does not work well: For example, the
> URI scheme may be insecure "http://" but the message has been received
> via a secure channel (e.g., https_port or SslBump).

Exactly my point. ICAPS usage on these requests is *optional*. Any use
of TLS on the inbound/outbound connections is opportunistic.

If the admin want to reduce costs they are free to send it through
icap:// services with no unexpected danger. Use of received_encrypted
would unnecessarily *raise* their ICAPS load.


> 
> 
>> In other news; HTTP is growing this thing called "opportunistc security"
>> (aka. encryption). Where http:// schemed requests will be arriving over
>> TLS, and maybe even going out via it and it traverses fully secure
>> components. HTTPbis WG are already finding problems with servers not
>> handling the schemes right in these conditions. Lets not add another
>> bunch of bad assumptions to the mix. Follow the scheme.
> 
> That seems like a counter-example to your own argument! The
> received_encrypted ACL should match if an http:// request arrived over
> TLS, and Squid may be able to offer better "security" for that
> transaction (e.g., by sending it to a Secure ICAP service or bypassing
> ICAP completely).

Only if you misunderstand the security requirements around
"oppportunistic" vs HTTPS.

Opportunistic security (http:// over TLS) means if the admin is *able*
and *willing* to pay the extra overhead costs of TLS, great. Otherwise
there is no pressure to do so.
 - in these cases the proposed patch adds nothing.

HTTPS (https://) means the admin is expected (almost mandatory) to pay
those costs. Failing to do so is a vulnerability.
 - in these cases the proposed patch adds only the ability to turn a
small vulnerability, into a bigger one. Existing ACLs already allows that.
 -if we want to be strict about hard-coding these requirements inside
Squid great. But then no need for the ACL config options.

So far its looking like there is no need for the ACL ... but lets go deeper.

> 
>> Also;
>> 1) we know about the directly connected security. But the connections
>> beyond that may be insecure. You note this yourself about eCAP. Same
>> goes for TLS connections!!
> 
> Not sure what you are implying by that. Yes, the admin only knows about
> things under his or her control. How is that related to the proposed
> ACL? In the ICAP context, the proposed ACL simply taints transactions
> received from un-encrypted sources.

NP: The proposed ACL implies that Squid is able to determine security
levels of different connections. (safe/unsafe, tainted/untained).

All three of these listed situations are cases where that implication
fails in subtle ways that can bite badly by *raising* the unnecessary
ICAPS usage for admin who want to avoid it.

> 
> We could go further and add a "this ICAP service taints messages" flag
> to [Secure] ICAP service configuration but there has not been any
> requests for that feature so perhaps adding more flags would be premature.
> 
> 
>> 2) Even when something is supposedly secure it can have wildly differing
>> degrees of security from other things. TLS itself has NULL-cipher with
>> zero security.
> 
> How is that related to the proposed ACL? Are you implying that
> "received_encrypted" is the wrong name because NULL-ciphers exist? I
> hope you would not vote -1 simply because you do not like the name, but
> better names are welcomed, of course.
> 

received_encrypted is being described as meaning the transaction is
secure. Unless one goes to almost ridiculous lengths to ensure the fine
grained details are all secure it can mean no such thing.

In the case of NULL-cipher use of TLS itself taints the transaction and
makes it insecure. That is the obvious cipher, other far less obvious
TLS features (like simply using SSLv or TLS/1.0) have the same tainting
effect. None of those are accounted for in the safe/unsafe description
being assumed in the patch ACL.
Its left to the admin to deal with. At which point we may as well use
the https:// scheme "proto" ACL match in place of received_encrypted.

> 
>> 3) non-TLS forms of connection security exist (IPSEC, VPN, stunnel, etc)
>> and may be used today without Squid knowledge.
> 
> And the admin can add rules to handle that traffic specially. The
> proposed ACL helps the admin in cases where Squid does know that the
> traffic was received over an encrypted channel.

The knowledge Squid has is not correct enough to be used for security
decisions like this.

> 
>> So any determination of "security" based on existence or lack of TLS or
>> other assumed properties is false information. We can't be sure about
>> other components real security, and it should not matter to the
>> component (ICAP service) making its decision.
> 
> The proposed ACL does not determine what is "secure". It only determines
> what was received via SSL/TLS channels, which for the lack of a better
> word, we called "encrypted". Better names are welcomed, but would not
> change what the ACL does.
> 

The need for this ACL was defined as:
"Folks want to send [messages were received over TLS or SSL transport
connections] transactions and only those transactions to Secure ICAP
services."


At REQMOD the myportname or proto ACLs meet the above criteria.

At RESPMOD the myportname, proto, and/or peername ACLs meet the above
criteria.


Whether the transaction was actually received over a TLS connection has
nothing to do with whether it is classified "secure" and needs to be
treated securly once it arrives.
 Its perfectly fine for a message for non-HTTPS traffic reeived over a
TLS connection to go to icap://.

Whether something (broken) earlier tainted it does not change its
classification to "Insecure" and has nothing to do with whether it needs
treating securely in ICAP(S).


> 
>> On the third hand (:-P), whats wrong with using a transaction annotation
>> in the HttpRequest set by insecure components if they are passed an
>> https:// request?
> 
> The annotation (effectively provided by the proposed ACL) needs to be
> set _before_ any [insecure] components see the message. The annotation
> may be used to decide whether those components will _see_ the message in
> the first place!

So does this received_encrypted ACL. The Safe/Unsafe netmask declare
"safe" at all points up until some taint happens.

Absence of the insecure annotation implies secure in *exact* equivalence
with the current patch implementaton.


> 
> In summary, I think you misunderstood the problem the ACL is trying to
> solve and have not suggested any viable alternative solutions. I hope my
> response clarified things enough for you to re-consider your -1 vote.

I understand that this proposal is trying to link "TLS encrypted" as
implying "secure transaction". The two are simply not related that way.
It is a common mistake to think so.

The logic relationshp between security and TLS is a nasty one-way
implication thing. Secure connection (HTTPS, https://) implies TLS ...
but *not* vice versa.
 Just like use of TCP implies IP protocol, but use of IP protocol
implies either UDP or TCP.

*HTTPS* (https://) already means secure transaction. Nothing else we
deal with at present does. Not even ICAPS usage.

Admin who want to minimize their ICAPS load simply configure "acl HTTPS
proto HTTPS" and use something like "allow !HTTPS" on the icap://
service. Or "deny !HTTPS" on the icaps:// service.

The tricky case is HTTPS over non-TLS connections. As you mentioned
above the admin can already add other rules to handle IPSEC, VPN,
stunnel, etc specially. Whatever those rules may use its not
received_encrypted (which will match wrongly in these cases).


Amos