[squid-users] blockVirgin Works for CONNECT but Custom Response does not work

[Alex Rousskov]

On 10/09/2014 11:57 PM, Jatin Bhasin wrote:

> adaptation_masterx_shared_names X-Virus-ID
> acl toBump note X-Virus-ID yes
> ssl_bump client-first toBump

OK.


> My eCap adapter functions which returns yes for the X-Virus-ID are:
> =================================================================
> const libecap::Area Adapter::Xaction::option(const libecap::Name &name) const
> {
> std::string str = "yes";
> return libecap::Area(str.data(), str.size());
> }

Two bugs here:

* You are returning a pointer to str, which is a temporary, on-stack
storage. Use libecap::Area::FromTempString() instead.

* You are returning "yes" value for all option names. The return value
should be conditional on name parameter being lequal to
libecap::metaVirusId ("X-Virus-ID").

These two bugs may not actually affect you (for several reasons), but
you should fix them anyway.


> --------------------------------------------------------------------------------------------------------------------
> void Adapter::Xaction::visitEachOption(libecap::NamedValueVisitor
> &visitor) const
> {
> std::string str = "yes";
>     visitor.visit(libecap::metaVirusId, libecap::Area(str.data(), str.size()));
> }

There is no need for std::string in this case, but the above code is not
buggy, just inefficient.


> Looking at cache.log I see that X-Virus-ID is set to yes but the eCap
> adapter functions. But I do not know that how it will be picked up
> note acl. Please suggest.

I agree that Squid seems to receive the X-Virus-ID:yes metaheader from
the eCAP adapter, but your toBump ACL still does not match. I cannot
tell why that is [not] happening by looking at the cache log, unfortunately.

You may want to add debugging to ACLNoteData::match and
ACLNoteData::matchNotes in src/acl/NoteData.cc to see if the ACL code
has access to the eCAP history with X-Virus-ID metaheader.

The only theory I can offer right now is that the code handling
annotations for CONNECT requests is broken and does not store or does
not preserve annotations received from eCAP adapters. CONNECT requests
are treated specially in Squid. You can try to test that theory by
annotating GET requests, for example.

Another good test is to log your annotation to access.log using %note
logformat code. If it is not logged, Squid probably lost it. If it is
logged, then the ACL code does not have access to the information for
some reason. This test can be done for both CONNECT and GET requests.


HTH,

Alex.



> On Sat, Aug 23, 2014 at 10:24 AM, Alex Rousskov wrote:
>> On 08/21/2014 07:06 PM, Jatin Bhasin wrote:
>>
>>> So, can somebody suggest me if there is a way to pass a flag to squid
>>> from ecap adapter to decrypt a site regardless of what ACL says. For
>>> example if I have an acl as below which says do not decrypt
>>> www.888.com but If my ecap adapter could pass a message to squid
>>> asking it to decrypt www.888.com (for that session only) and ignore
>>> the below acl.
>>> Is it possible?
>>
>>
>> Given a recent-enough Squid version, an adaptation service can control
>> Squid behavior via the annotations mechanism and the "note" ACL
>> associated with it. For example, your eCAP adapter can return an
>> X-Bump:yes annotation(**) that Squid can then match using the note ACL.
>> Something along these untested lines:
>>
>>   acl note toBump X-Bump yes
>>   ssl_bump server-first toBump
>>   ssl_bump server-first ...
>>   ssl_bump none all
>>
>> This mechanism should be supported for ssl_bump ACLs but I have not
>> tested that claim myself.
>>
>>
>> HTH,
>>
>> Alex.
>> (**) In eCAP terminology, an X-Bump:yes annotation is an adapter
>> transaction option named X-Bump with a "yes" value. See
>> libecap::Options, which is a parent of libecap::adapter::Xaction.
>>