[squid-dev] [PATCH] connections_encrypted ACL

[Christos Tsantilas]

On 01/02/2016 05:23 AM, Amos Jeffries wrote:
> On 2015-12-30 23:23, Christos Tsantilas wrote:
>> This patch initialy discussed in squid-dev under the thread "[PATCH]
>> received_encrypted ACL" some months ago:
>> http://lists.squid-cache.org/pipermail/squid-dev/2015-July/002680.html
>>
>> The "received_encrypted" was the original name of a new ACL which in
>> this patch (t7) renamed to connections_encrypted
>>
>> I am reposting here as new patch.
>>
>> (New) Patch description:
>>
>> The new connections_encrypted ACL matches transactions where all HTTP
>> messages were received over TLS transport connections, including
>> messages received from ICAP servers.
>>
>> Some ICAP/eCAP services receive data from unencrypted sources. Some
>> ICAP/eCAP services are "secure". By default we assume that all eCAP
>> services and all ICAP services on TLS transport connections  are
>> "secure" unless the user uses the "connection_encryption" option in
>> service configuration line.
>>
>> This is a Measurement Factory project.
>
>
> in src/acl/ConnectionsEncrypted.h:
>
> * the #ifndef wrapper string s/ENTRYPTED/ENCRYPTED/
>
> * please use a space between "operator="
>
> * please add empty line between end of namespace and file wrapper #endif
>
>
> in src/adaptation/ServiceConfig.h:
>
> * something seems wrong about the use of connectionsEncryptedSet member.
>   - it is using twice as much memory to configure a boolean option than
> it should be able to.

Probably the connectionsEncryptedSet should renamed to 
overwriteConnectionsEncrypted os something like that.


>
>
> The options are documented as being configured *after* the service URI.
> So it seems to me that the service URI should set the flag default based
> on the icap/icaps (or ecap/ecaps) nature. Then the user option set/unset
> it later if they want to override. No need for a separate "user set it"
> member, or for special casing of ICAP/eCAP non-S.


An ICAP service can configured to use TLS even if the icaps is not used 
in URI scheme. Just the "tls" option in icap_service configuration line 
is enough to enable TLS for service.


The ecaps is not used in ecap URIs, the ECAP services by default 
considered always as secure because no connection to external sources is 
required.

The final decision about encrypting or not the ICAP connections in the 
ICAP related squid code does not taken while the configuration line is 
parsed, but in later step, just before the service configured and starts.


>
> On the dumpCfg() side the service URI type could be checked to see if it
> the value needs to be dumped out or not. The user setting it to the
> default is a no-op.

hmm.....
The Adaptation::Config::dumpService() functions which prints an
adaptation service looks wrong ...

If no problem I will not touch this method now, and I will make a new 
patch which fixes this method.

>
> in src/cf.data.pre:
>
> * the documentation implies that connection_encrypted=on turns the taint
> check *OFF* for ICAPS connections. But does not un-taint ICAP
> connections. The code does not seem to match.

You are right I confused too reading these lines.

* For secure ICAP service the  connection_encrypted=on option is the 
default, the user can use the connection_encrypted=off to change the 
default behaviour.
* For plain ICAP services the default is the connection_encrypted=off 
and the user can use the connection_encrypted=on to change the default 
behaviour.

Are the following lines enough for ICAP service:
"The default is "on" for Secure ICAP services (i.e., those with the 
icaps:// service URIs scheme) and "off" for plain ICAP services."

The existing related documentation line for ECAP looks OK to me.

>
> Amos
>