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
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
