[squid-dev] [RFC] Secure ICAP

[Kinkie]

I also have (of course) no objection with the proposed course of
action, and share the hope that the generic crypto library will be
useable for this.

On Wed, Feb 4, 2015 at 3:02 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> 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
>>
>
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev



-- 
    Francesco