[squid-dev] [PATCH] received_encrypted ACL

[Alex Rousskov]

On 07/19/2015 05:35 AM, Amos Jeffries wrote:
> 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".


No, you are not. If you wanted to debate the usefulness of a feature,
then you would have not voted at all or voted -0 or above. Your -1 vote
is not a debate, it is a [blocking] resolution a.k.a. a veto.


>>> This is conceptually very bad.
>>
>> What exactly is "this" and why is it very bad?
> 
> what: The use-case behaviour being proposed as desirable.

The desirability of that behavior is a fact -- Squid admins desire it.
We rarely spend a few days implementing something theoretically
desirable. The proposed feature satisfies real desires of real Squid admins.


> why: for the reasons the rest of my mail was attempting to describe.

I do not think the rest of your email explains why sending "received
encrypted" traffic to Secure ICAP services is "conceptually very bad".
You talked about

* the need to keep https:// traffic secure
  (no one argues against that!)

* identifying "secure" traffic using ports and URI schemes
  (ports/schemes do not work well enough or we would not add this ACL)

* Squid's knowledge being limited to direct connections
  (true but admins often know more and can use ACLs accordingly)


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

The admin needs to send messages received via a SSL/TLS channel to a
Secure ICAP service. This routing is not optional. This routing is
required! There is nothing opportunistic or optional here.

You may argue that the admin's requirement itself is wrong, but you are
unlikely to win that argument. It may not be perfect, but it is very
reasonable in many environments.


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

Perhaps you have some other use case in mind, but in the use case at
hand, the admin cannot send received-encrypted traffic to just any
service. The external requirements outside our control or knowledge
require the admin to route received-encrypted traffic to special ICAPS
services.

It is easy (IMO) to think of many other use cases for the same feature:

* Use a special adaptation service for received-encrypted traffic.
* Do not adapt received-encrypted traffic at all.
* Do not log received-encrypted traffic.
* Do not cache received-encrypted traffic.
* Do not limit received-encrypted traffic bandwidth.
* Route received-encrypted traffic to a special cache peer.
* etc.


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

I do not think so: The proposed ACL would help the admin to extend the
"security opportunity" to certain traffic. Whether to do that would
still be admin's choice (it is an ACL, not a hard-coded behavior!).
Without this ACL, making that decision becomes much harder because Squid
does not supply the necessary information in an easily accessible form.
That is why admins want this ACL!


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

OK.

>  - in these cases the proposed patch adds nothing.

Except it helps the admin to decide for which traffic Squid should pay
the extra overhead. The new ACL may not be the final answer, of course.
It is just one of the variables that some admins may want to look at
when making "Am I willing to pay?" decisions.


> HTTPS (https://) means the admin is expected (almost mandatory) to pay
> those costs. Failing to do so is a vulnerability.

As discussed earlier, "https://" URIs is not the only case where the
admin is expected to pay those costs. The new ACL helps the admin to pay
the costs when the payment is due (and avoid paying when the payment is
optional and not worth the gain).


>  - in these cases the proposed patch adds only the ability to turn a
> small vulnerability, into a bigger one.

An ACL is just a function returning true or false. It does not make any
vulnerability worse. While anything can be abused, we should focus on
the correct/expected usage. When used correctly, the new ACL may help
the admin to reduce vulnerabilities by, for example, using ICAPS or even
avoiding adaptation completely.


>  -if we want to be strict about hard-coding these requirements inside
> Squid great. But then no need for the ACL config options.

We cannot hard-code: The requirements (and the means to satisfy them)
differ from one deployment to another.


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

No. The ACL only knows about SSL/TLS connections. It does not know about
safety, security, or any other higher-level concepts. The word "tainted"
is applied here because a single non-SSL/TLS source is enough to flip
the ACL value even when the other 10 sources were TLS. I think that
wording is appropriate and does not imply too much, but better wording
is welcomed if you disagree.


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

Perhaps you are comparing a with-ACL configuration with some ideal case
that does not exist? Here is the correct comparison (for one of the
discussed use cases):

* Without the ACL: Send everything to ICAPS (100%)
  because we cannot easily identify what should not be sent and
  we do not want to risk missing a few important cases.

* With the ACL: Send received-encrypted to ICAPS (X%)
  because we know that covers all the important cases (at least).

In most deployment environments, X is [a lot] less than 100 so the new
ACL is [very] useful.

Please note that there is no claim here that X cannot be decreased
further. With more ACLs (existing or future), it can be.


> received_encrypted is being described as meaning the transaction is
> secure. 

It was not intent to describe any transactions as secure. The proposed
commit message does not call any transactions secure. It only uses the
word secure in two contexts:

* "Secure ICAP" phrase, which is an existing protocol name (nothing we
can do about the word Secure there!)

* Secure eCAP services, which is a possible future concept. Since eCAP
is not a network communication protocol, it cannot use SSL/TLS
connections. Instead, the admin is going to mark eCAP services
appropriately (from the admin point of view). We can reword that eCAP
paragraph if you think the word "secure" is misleading there. The word
is already in "quotes" to indicate an imprecise meaning.

The ACL description in src/cf.data.pre does not use the word "secure".

There is a NOTE in the email introducing the patch that says "secure
source/request". It should have said "encrypted source/request". Sorry.

None of the above changes what the ACL does, of course.


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

None of those cases need to be accounted for in most real use cases AFAIK:

Yes, the current implementation does not account for unencrypted TLS
connections, but this is only a problem with the name of the ACL, not
with the implemented and documented functionality. The implementation
and documentation do not define or assume what is "secure" or even
"encrypted". The implementation just checks whether the message was
received over the SSL/TLS channel. It does not claim to do more.

Fortunately, the proposed implementation is enough to offer the vast
majority of admins dealing with these problems what they want. If some
admin wants to discriminate null cyphers and similar features, they can
petition for parameterizing this ACL or adding another one. It would
certainly be possible to do that. The current inability of the ACL to
detect null cyphers cannot be a valid reason to reject the ACL.

Again, if you can think of a better name for the ACL, we would gladly
rename! "received_encrypted" is just the best we could come up with. For
example, if you think "received_over_tls" is much better, we can rename
to that.


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

The https:// scheme does not work for an important case of http:// URLs
received over perfectly secure TLS connections. The admins have tried
that and did not like the outcome. That is why they requested
received_encrypted.

The lack of null cypher (and similar esoteric cases) support is going to
hurt virtually nobody. It is not a problem the [vast majority of] admins
would need to deal with! And it can be added later if needed.



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

The admins say the functionality allows them to make the decisions they
want to make. You have provided no example where a reasonable
configuration would lead to incorrect decisions related to security.
AFAICT, the best you could imply so far is that some unencrypted traffic
received over TLS (NULL cyphers and such) will go to a Secure ICAP
service. This is not a problem admins actually worry about!


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


Yes, this is one of many use cases.


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

No, they do not. For example, an http:// request could be received on an
http_port inside a bumped TLS CONNECT tunnel. With the proposed ACL, it
is easy to route the bumped request to a Secure ICAP service, as
required. Without the new ACL, the routing decisions become complex and
error-prone.

There are other, more complex, examples where port and scheme ACLs are
not good enough.



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

Whether it has nothing or everything to do with TLS is not our decision
to make. The admin decides that. Yes, it is possible to create examples
where TLS is irrelevant. That does not matter because there are enough
examples where it is relevant [to the admin and her decisions/requirements].


> Its perfectly fine for a message for non-HTTPS traffic reeived over a
> TLS connection to go to icap://.

Not our decision. We do not define adaptation routing rules. Admins do.


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

Again, this is admin's decision, not ours. The proposed ACL does not
support such decisions (the "conservative tainting" logic is currently
hard-coded), but future ACL parameters can address this as needed with
little code changes. The right code infrastructure will be there.


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

Perhaps I was not clear:

* received_encrypted ACL marks the transaction without exposing it to
  any adaptation services first. This "early marking" is an important
  requirement.

* annotations set by [insecure] components (your proposal) do not
  satisfy that requirement.


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

Absence of an insecure annotation does not tell the admin whether the
transaction may or may not be sent to a given adaptation service. The
admin in our use case makes that decision based, in part, on which
channel the transaction came from (TLS or not). The annotation you
propose only tells the admin that the transaction has not been sent to
an insecure annotation service yet.


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

No, it does not. The proposed ACL only marks "TLS encrypted"
transactions. Nothing more. It is the admin that decides what to do with
those marked transactions. Many admins want to treat them specially. If
used correctly, the ACL does not weaken security.


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

Many admins want to do X to https:// and http:// transactions received
over TLS channels. The proposed ACL allows them to do that. "X" can be a
lot of things, including sending to a Secure ICAP service.


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

Does not work for non-https:// transactions that are received over TLS
channels and need to go to the secure ICAP service (per admin rules).


In summary:

* You seem to have constructed a simple use case that can be addressed
without received_encrypted ACL. The ACL was created for more complex
cases discussed above, and it may actually work better than a
combination of the ACLs required for all but the very simplest cases.

* You say that the new ACL defines what is "secure" or "encrypted". It
does not. "Received over SSL/TLS" is as far as it goes. This limited
definition covers many known use cases well (from admins point of view).

* You might be implying that Squid can define which adaptation services
are appropriate for https:// (or other) transactions. I believe that
decision lies with the admin, not us. We cannot hard-code it, and admins
need the new ACL to configure it.

* You are also trying to attack the proposed feature because it does not
know about NULL cyphers and other encryption/security exceptions. That
knowledge can be added later if somebody actually needs it. It is not
important for the known use cases.

Hope this clarifies and removes your objections.


Thank you,

Alex.