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

Sat Oct 11 03:03:41 UTC 2014

Hi Alex,

I changed my ACL's a bit to see annotations in access.log file. My web
browser is point to squid port 3127.

So squid.conf is as below:  (first two lines are for note logging as
you suggested.)
---------------------------------------------
logformat with_note %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %[un
%Sh/%<a %mt %note
access_log /var/log/squid/access.log with_note
adaptation_masterx_shared_names X-Virus-ID
acl toBump note X-Virus-ID yes
acl p3127 myportname 3127
ssl_bump client-first p3127          (Hence all requests will be bumped.)

I made changes to the eCap adapter as you had suggested. But I do not
see any annotations in access.log file.

1412995864.045      7 10.100.249.11 TAG_NONE/200 0 CONNECT
www.bwin.com:443 - HIER_NONE/- - -
1412995867.108   2573 10.100.249.11 TCP_MISS/200 10122 GET
https://www.bwin.com/ - HIER_DIRECT/195.72.134.135 text/html -

Now i I introduce another paramter in the squid.conf file as below:

note X-Virus-ID yes p3127

And I get following in access.log  (so this is definitely not coming
from my eCap adapter but because of the note directive above)

1412996265.992      7 10.100.249.11 TAG_NONE/200 0 CONNECT
www.bwin.com:443 - HIER_NONE/- - X-Virus-ID:%20yes%0D%0A
1412996266.159     87 10.100.249.11 TAG_NONE/200 1400 GET
https://www.bwin.com/ - HIER_NONE/- - X-Virus-ID:%20yes%0D%0A

Now, this makes me feel that annotations from my eCap adapter are not
travelling to squid for both CONNECT and GET.

So, would my eCap adapter has to do something else to let squid know
that the annotations its providing is a note.

Thanks,
Jatin

On Sat, Oct 11, 2014 at 2:18 AM, Alex Rousskov
<rousskov at measurement-factory.com> wrote:
> 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.
>>>
>