Hi Alex,
I think I have found the reason that why the annotation from eCap
adapter NOT being passed to NoteData.cc. But I still need your
suggestion to fix this.
So here is my analysis:
1) In src/acl/NoteData.cc function ACLNoteData::match(HttpRequest *request)
if (request->notes != NULL && matchNotes(request->notes.getRaw()))
(This is used when there is note directive in
squid.conf file)
return true;
if (ah != NULL && ah->metaHeaders != NULL &&
matchNotes(ah->metaHeaders.getRaw())) (This is used
when there is adaptation_meta in squid.conf file)
return true;
2) In src/adaptation/ecap/XactionRep.cc function
Adaptation::Ecap::XactionRep::start()
if (ah != NULL) {
// retrying=false because ecap never retries transactions
adaptHistoryId = ah->recordXactStart(service().cfg().key,
current_time, false);
typedef Notes::iterator ACAMLI;
for (ACAMLI i = Adaptation::Config::metaHeaders.begin(); i !=
Adaptation::Config::metaHeaders.end(); ++i) {
const char *v = (*i)->match(request, reply);
if (v) {
if (ah->metaHeaders == NULL)
ah->metaHeaders = new NotePairs();
if (!ah->metaHeaders->hasPair((*i)->key.termedBuf(), v))
ah->metaHeaders->add((*i)->key.termedBuf(), v);
}
}
}
As per the above code ah->metaHeaders will only be populated if
adaptation_meta option is present in squid.conf file.
So in my case ah->metaHeaders is NULL (And when I added
adaptation_meta X-Virus-ID yes all in squid.conf then I could get a
match on my toBump acl and hence my CONNECT transaction was bumped.
But I want to achieve the same behavior using eCap adapter)
Also I changed the squid.conf file for access.log as below:
logformat with_note %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %[un
%Sh/%<a %mt %note %adapt::<last_h
And I could see that eCap adapter X-Virus-ID:yes in the access.log
(%adapt::<last_h)
So, I think I am very close to pass X-Virus-ID:yes as a meta header.
Can you suggest me how I can do it. (I think it may require a code
change in XactionRep.cc but I am not sure.) Please suggest.
Thanks,
Jatin
On Sat, Oct 11, 2014 at 2:03 PM, Jatin Bhasin <jbhasin83@xxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxxxxxxxxxx> 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.
>>>>
>>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
