> ons 2007-06-20 klockan 11:52 +1200 skrev [EMAIL PROTECTED]:
>
>> I would need those above and also dstdomain and external ACL support (at
>> least IP and domain passed to helper).
>
> There won't be any domains on such intercepted connections, just IP, and
> if you are lucky the reverse lookup of
ons 2007-06-20 klockan 11:52 +1200 skrev [EMAIL PROTECTED]:
> I would need those above and also dstdomain and external ACL support (at
> least IP and domain passed to helper).
There won't be any domains on such intercepted connections, just IP, and
if you are lucky the reverse lookup of that IP..
> Gah, I got another email about transparent https interception.
>
> I guess this means I'll just have to bloody write it. My main question
> is which ACL types people would like to support. Initially it'd be
> easy to support source and destination IP, logging the tra
tis 2007-06-19 klockan 23:25 +0800 skrev Adrian Chadd:
> If I do this I could also implement the tunneling from Steven Wilton
> for "transparent" tunneling of unparseable HTTP requests; with similar
> ACLing.
>
> What do you think?
Sure. Would help transparent setups quite a bit. Especially if a
On Tue, Jun 19, 2007, Henrik Nordstrom wrote:
> tis 2007-06-19 klockan 17:37 +0800 skrev Adrian Chadd:
> > Gah, I got another email about transparent https interception.
>
> Heh..
>
> > I guess this means I'll just have to bloody write it. My main question
> &
tis 2007-06-19 klockan 17:37 +0800 skrev Adrian Chadd:
> Gah, I got another email about transparent https interception.
Heh..
> I guess this means I'll just have to bloody write it. My main question
> is which ACL types people would like to support. Initially it'd be
> easy
Gah, I got another email about transparent https interception.
I guess this means I'll just have to bloody write it. My main question
is which ACL types people would like to support. Initially it'd be
easy to support source and destination IP, logging the transaction
time and T