[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor transparent proxy implementation on Windows



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
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk