[squid-dev] [PATCH] received_encrypted ACL

[Alex Rousskov]

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?

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?


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


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


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

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.


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


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


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


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.


Thank you,

Alex.