[tor-talk] Tor transparent proxy implementation on Windows
blibbet at gmail.com
Thu Dec 29 01:47:30 UTC 2011
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
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
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.
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.
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.
More information about the tor-talk