I've been expecting this to come up for a while now, but had hoped the crypto generalization would be a bit further along. Oh well.
My plan for the Crypto-NG / libsecurity work already in audit was to followup with a Security::Encryptor AsyncJob that could be passed the Comm::Connection object from a newely opened connection plus the Security::PeerOptions from squid.conf and initiate TLS/SSL on the connection. That model is reusable for cache_peer, DIRECT connections, ICAP, and any other protocols which use the X-over-TLS protocol layering. Without any major changes to the existing code - we just update the appropriate Comm callback to kick off the new Security::Encryptor job once the server FD is opened. I would like to push that update forward rather than anyone writing another protocol-specific connection setup pathway. A good chunk of the preparation work is already done, so the time to completion would also be faster than a new project. Amos On 4/02/2015 9:52 a.m., Alex Rousskov wrote: > Hello, > > We would like to add support for "Secure ICAP" -- ICAP services that > require SSL/TLS encryption for transport connections. Some other popular > proxies support that feature already, I have seen a trickle of admin > requests for it, and the feature often becomes essential when filtering > bumped traffic using external ICAP services (to preserve the overall > security of the entire message delivery chain). > > Today, it is possible to emulate Secure ICAP using connection wrappers > like stunnel. Needless to say, that workaround is not a production- > quality solution. > > > I think Secure ICAP can use configuration knobs and server validation > logic already implemented for secure HTTP peers (the cache_peer > directive with an ssl option). > > To mark an ICAP service as secure in squid.conf, we can use an "icaps" > service URI scheme. The industry is using "secure ICAP" term for this > feature, but "icaps" seems more appropriate/standard for a scheme name > compared to "sicap". > > > We will not support dynamic "upgrades" from plain to secure ICAP > connections because: > > * there are no ICAP servers that support that (AFAIK); > * there are no ICAP clients that support that (AFAIK); > * such support does not seem to be needed in practice given a rather > tight/long-term bonding between a proxy and an ICAP service (unlike a > relationship between an HTTP client and an origin server); > * such support can be added later, if needed, without redoing much of > the proposed work. > > I also do not anticipate changes to the existing ICAP service > _selection_ configuration and related features, implementation of the > ICAP protocol itself, and eCAP. > > > If there are any objections to adding Secure ICAP support or high-level > suggestions regarding implementation, please let me know! > > > Thank you, > > Alex. > _______________________________________________ > squid-dev mailing list > squid-dev@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-dev > _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev