[squid-dev] [RFC] Secure ICAP

[Amos Jeffries]

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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>