[squid-dev] [PATCH] received_encrypted ACL

[Amos Jeffries]

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.
> 
> Some eCAP services receive data from unencrypted sources. Some eCAP
> services are "secure", but we assume that all are not "secure" until we
> add a configuration option to mark secure eCAP services.
> 
> 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.


And the (very) long answer:

This is conceptually very bad. Good citizens don't take a mugging victim
and throw in a few more punches simply because they were mugged. Other
far better reasons would be necessary instead.


The protocol level signals are simple and quite clear already:

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

What other components of Squid are doing with the message has no
relevance to whether those criteria apply. If one of them is being
insecure compounding the problem is undesirable.

Please do instead encourage using the request URI scheme ("proto" ACL)
to make that determination of whether ICAP security is desirable or not.

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.


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!!
(again: URI scheme is supposed to tell us the end-to-end situation anyhow.)

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.

3) non-TLS forms of connection security exist (IPSEC, VPN, stunnel, etc)
and may be used today without Squid knowledge.
 - this is where admin configurability of whether to let https://
traffic go or not to a icap:// service comes in handy. But matters not
for icaps:// services.

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.



On the other hand the mechanics behind it could be of some use outside
the security area. You may have noticed I'm currently working on getting
LogTags to be a flag set. Part of this is logging accuracy. Part of it
is completing the ancient feature request for an ACL that matches
against "HIT" or "MISS" etc.
 TLS listening port is already planned to be one new tag there. The
other sources your patch is marking are good candidates as well. So the
result_code ACL (or whatever its called in the end) will overlap a lot
with what this "received_encrypted" is doing.


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?
 Would probably be a good thing to do simply for logging trouble spots
regardless of "received_encrypted" existence.



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

Again here the URI-scheme used to cache the object in the first place
already tells us it was (at least supposed to be) from a guaranteed
secure source.

How that security differs between now and when it was fetched may vary
even if the same components were used only a short time ago (think what
a "patch tuesday" could do to servers on auto-update).


(Phew, sorry for the length of that)

Amos