[squid-dev] [RFC] Secure ICAP

[Alex Rousskov]

On 02/03/2015 07:02 PM, Amos Jeffries wrote:

> 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.

We already have PeerConnector -- an async job that encapsulates most of
the security-related logic when it comes to connecting to other servers.
It is used by TunnelStateData, FwdState, and PeerPoolMgr. I doubt you
need another job that does the same.


> 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.


Sure, we would gladly reuse anything available as long as we do not have
to wait for it. AFAICT, if we use PeerConnector for Secure ICAP, and
your NG changes go inside PeerConnector, then we will not be stepping on
each other toes too much.


Thank you,

Alex.



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