On 6/01/2016 1:31 a.m., Amos Jeffries wrote: > On 5/01/2016 5:25 a.m., Christos Tsantilas wrote: >> 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. >> > > What I meant was that it should not be necessary at all. Its very > existence increases the number of variables used to say whether the > connection is encrypted. But... > >>> >>> 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. >> > > Okay. Thats a pretty nasty design problem. Fair enough on keeping the > member then. Just add a // comment about why it exists. >
Actually. Along these lines a single YesNoNone should be used instead of two bools. I am currently testing some changes that should make it more useful. But the existing trunk implementation should already be fine for this patches needs. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
