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..
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
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 TX/RX bytes
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 to support source
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
is which ACL types people would like
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 also
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 TX/RX bytes
