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