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

[Jatin Bhasin]

Hi Alex,

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.


2014/10/10 22:50:55.341 kid1| HttpHeader.cc(1272) putExt:
0x7fff1d656f80 adds ext entry X-Virus-ID : yes
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(1525) HttpHeaderEntry:
created HttpHeaderEntry 0x1722650: 'X-Virus-ID : yes
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(907) addEntry:
0x7fff1d656f80 adding entry: 77 at 0
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(442) clean: cleaning hdr:
0x1722538 owner: 3
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(818) delByName: deleting
'X-Virus-ID' fields in hdr 0x1722538
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(533) update: Updating
header 'Other:' in cached entry
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(1525) HttpHeaderEntry:
created HttpHeaderEntry 0x1722720: 'X-Virus-ID : yes
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(907) addEntry: 0x1722538
adding entry: 77 at 0
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(818) delByName: deleting
'X-Virus-ID' fields in hdr 0x1722568
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(533) update: Updating
header 'Other:' in cached entry
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(1525) HttpHeaderEntry:
created HttpHeaderEntry 0x17227f0: 'X-Virus-ID : yes
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(907) addEntry: 0x1722568
adding entry: 77 at 0
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(442) clean: cleaning hdr:
0x7fff1d656f80 owner: 3
2014/10/10 22:50:55.341 kid1| HttpHeader.cc(1531) ~HttpHeaderEntry:
destroying entry 0x1722650: 'X-Virus-ID: yes'

On Fri, Oct 10, 2014 at 4:57 PM, Jatin Bhasin <jbhasin83 at gmail.com> wrote:
> Hi Alex,
>
> I used the annotation mechanism as you had suggested. My squid
> configuration files looks as below: (For now I am using X-Virus-ID to
> see if the concept works for my case)
>
> adaptation_masterx_shared_names X-Virus-ID
> acl toBump note X-Virus-ID yes
> ssl_bump client-first toBump
>
>
> 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());
> }
> --------------------------------------------------------------------------------------------------------------------
> void Adapter::Xaction::visitEachOption(libecap::NamedValueVisitor
> &visitor) const
> {
> std::string str = "yes";
>     visitor.visit(libecap::metaVirusId, libecap::Area(str.data(), str.size()));
> }
> =================================================================
>
> Now looking at the log file I see the following. Also, from cache.log
> toBump does not seem to be getting matched probably because X-Virus-ID
> is not set to yes.
> 2014/10/10 14:51:21.431 kid1| client_side_request.cc(1551)
> sslBumpNeed: sslBump required: none
>
> I have placed debug statements in my eCap adapter function to confirm
> if I am seeing CONNECT requests for a URL and also that I am setting
> X-Virus-ID to yes. But I am not to understand that what I could be
> missing.
>
> Can you please suggest me what I could be missing.
>
>
>
> Thanks,
> Jatin
>
> On Sat, Aug 23, 2014 at 10:24 AM, Alex Rousskov
> <rousskov at measurement-factory.com> 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.
>>