[tor-talk] Tor transparent proxy implementation on Windows

[Lee Fisher]

On 12/27/11 4:35 PM, coderman wrote:
[...]
> 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.

Thanks, Coderman, for clarifications. I didn't realize the trunk doc was 
3yrs old.

I agree with your conclusion about TorVM being the right technology 
choice for Windows.

I just didn't think that the 'there are no alernatives' part could be 
clarified a bit. :-)

I think a native driver could help with Tor performance, if that really 
was an issue -- -erhaps transparency issues aside -- to be addressed at 
some level by Tor's sponsors.

But a Windows driver solution would be hard in a variety of ways:

1) to develop. You'll need NT driver skills, not LSB/POSIX/eLinux skills.

And unlike having source access, and using IRC for help like with FOSS 
tech, the proper approach for WDK dev, if you can't figure it out 
yourself or on NTDev list, would require paying $ to MS Tech Support for 
answers, and I laugh at the thought of that ever happening (with most 
FOSS community in general, nothing with Tor in particular). :-)

2) to build. You'll need to use MSC and KD/Windbg, not GCC and GDB. 
Given Tor service is built with MinGW, and GCC doesn't generate PDB 
symbols that KD/Windbg expect, and GDB doesn't debug drivers. So 
debugging kernel mode IRP interactions with an NT service with no 
symbols would not be fun. I wish MinGW's GCC could generate PDBs!

Also, the DDK/WDK tools are curently freeware, but at times they were 
commerical only, by paying for MSDN, and pulled from online free 
download for a while. I sadly expect that Win8 will change for the worse 
in this area. This might also be an issue for the OpenVPN driver.

3) to support. When Tor users have BSODs and ask for help... Having to 
deal with NT kernel dumps would be an increase in resources. Having to 
document how to install a driver, deal with driver signing, locked down 
systems that don't allow drivers, dealing with crashes, would require a 
large doc project.

In addition to time needed to build a new driver, a new NDIS/WFP driver 
would need time to test and mature, whereas most of the TorVM FOSS 
components are mature and wouldn't have this problem. IRP stability, as 
well as transparency testing. Which would of course be much easier if a 
foreign OS is used for isolation.

As for maintaining legacy versions of Windows platforms, you can only 
track Windows versions so long, until vendor doesn't provide security 
patches for it, then it's a worthless platform for anything that needs 
privacy/security.

IMO, low-end hardware like Atom netbooks are going to have a hard time 
using a Linux VM. And, upcoming Win8 is targetting ARM hardware, so I 
presume handsets and tablets, as well as netbooks. However, these boxes 
will likely be locked down by MS and carriers, and neither a TorVM or an 
external kernel driver would likely be allowed, unless rooted. So, 
neither solution will probably work on those targets, even if/when MinGW 
targets Windows ARM binaries.

I also asked around, to see if there was any more NT guidance for 
specific driver model recommendations. It appears the NDIS "raw IP 
medium" type (NdisMediumIP)" driver is one to investigate. In addition 
to WFP. Some NDIS driver models are being deprecated for WFP, but I'm 
not sure if NDIS NdisMediumIP drivers are on that list.
http://www.osronline.com/showthread.cfm?link=217920

Also, I'm not sure if WFP is technically able to handle all transproxy 
needs. There are 2 WDK samples for WFP that seem like a good place to 
start, if anyone is interested.

Thanks,
Lee

PS: The Tor tor-win32-mingw-creation.txt is about a year outdated. The 
MSYS and MSYS DTK distribution filese have changed, and the legacy 
package names that the Tor doc refers to are no longer available for 
download from SourceForge mirrors. It should probably be updated to 
include information using the mingw-get and mingw-get-inst tools. I'd 
rather see the Debian Mingw cross-compile instructions, if those're what 
is actually being used to generate the released binaries.
https://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=doc/tor-win32-mingw-creation.txt