[tor-talk] Tor transparent proxy implementation on Windows

[coderman]

On Sat, Dec 24, 2011 at 2:44 PM, Lee Fisher <blibbet at gmail.com> wrote:
> On 12/22/11 4:28 AM, andrew at torproject.org wrote:
>>...
>> https://svn.torproject.org/svn/torvm/trunk/doc/design.html.
>
> ... this statement is incorrect:
>
> "This is important in a Windows environment where capabilities like Linux(R)
> netfilter or BSD(R) packet filter do not exist."

it is not as simple, but you could create the equivalent facilities on
Windows. torvm is deprecated (an out of date proof of concept?) but
this statement would be worth updating for someone with access to that
repo.

to clarify, to implement the desired owner / application based port,
and protocol filtering, you would likely need to implement a shim with
NDIS intermediate and filter driver interfaces as well as the newer
WFP features if available to do what is needed on the intended XP
through 7 systems. this also implies driver signing and the scrutiny /
hurdles that involves for modern Windows 32 and 64bit kernels.

if you only target windows 7 the built in filter facilities, while not
equivalent on command line basis, are probably suitable. and WFP
certainly is!

this is a longer discussion, for someone interested. broken out to map
the various old intermediate APIs and support, to the newer filter
interfaces and advanced command line capabilities need to do full host
transparent proxying without a guest or aliased interface (inline),
and in tandom with one or more guest VMs to isolate Tor or its
accompanying components.



> ... But the OS interface
> to do transparent proxying has been in NT for decades, first with TDI and
> NDIS, now with WFP.

transparent proxying to the host itself is technically different
enough to matter between WFP and NDIS. that is, there is more to this
than just intercept/forward, nor just port filtering or redirect.
while there are features to do this on WFP (and to a lesser extent
with NDIS) the command line capability and full host transparent proxy
are still tricky (and worth breaking out into detail as mentioned
above, if someone is interested.)



> I also am confused by modern LibEvent performance and this comment:
>
> "For Windows platforms offloading the TCP session intensive Tor process to a
> Linux guest with edge triggered IO can significantly improve the performance
> of Tor and eliminate socket buffer problems."

presume that this is in context of relying on poor socket style
interfaces in Windows networking instead of high performance I/O
completion ports and async networking.

at the time of writing, Tor did not take full advantage of async I/O
on Windows due to libevent limitations in the 1.x series. libevent 2.x
has much improved Windows support.



> ... I would have thought a single WFP (or TDI or NDIS)
> driver would be improve the performance more than running a VM with a second
> OS and using TAP to talk to the virtual OS Linux network.

that would be ideal, but still much more work. Tor VM used existing
WinPCAP and Tap32/64 drivers, there was zero kernel side driver
development to make use of the existing transparent proxy facilities
in linux.



> Is the current Windows implementation of LibEvent still that
> performance-challenged? I thought Nick and other [GSoC] LibEvent
> contributers have improved LibEvent to be a "first class citizen" on
> Windows, and have reasonably performance event implementation these years?

yes. see above. Tor VM is nearly 3 years out of date at this point...