Initial Research on Implementation

[Walter]

To get the ball rolling on implementation, here's a few things I've
discovered so far. Nothing particularly exciting but it's a start.

The TUN/TAP interface (functional on Linux, FreeBSD and Solaris) may
be a good way to set up a Phantom interface at the OS level. From the
documentation (/usr/src/linux/Documentation/net/tuntap.txt):

TUN/TAP provides packet reception and transmission for user space
programs.
It can be seen as a simple Point-to-Point or Ethernet device, which,
instead of receiving packets from physical media, receives them from
user space program and instead of sending packets via physical media
writes them to the user space program.

The idea would be that an outgoing communications request (eg: TCP
connect) to a certain IP address would cause the automatic
establishement of a Phantom routing path / routing tunnel to the
target phantom node's AP address. The phantom daemon running the TUN/
TAP interface would know which AP address to connect to, since it
would maintain a memory of previous DNS lookups on .phantom (see
below) and the temporarily assigned non-routable address it responded
with, which would be the destination of the outgoing IP packet.

Regarding my idea for a local DNS server that allows access to phantom
for standard applications without requiring a simple per application
'on/off' switch (by resolving the .phantom top level domain through to
a normally non-routable address space such as 127.255.x.x, each node
of which is then assigned a local route through the TUN/TAP
intrface.), it looks like the 'pipe' backend support for PowerDNS
(which runs on BSD, Solaris, Linux, MacOS and Windows) is one possible
solution here. This would mean that requests for name resolution
could be passed to a dedicated resolver-daemon via a pipe, which then
either:

1. Resolved the address normally over the regular internet

2. Noticed a .phantom top level domain or non-routable address space
IP (such as 127.255.1.1) in the query, and did a phantom-specific
lookup. In the case that it was a .phantom address, it would assign a
temporary, non-routeable address and remember the association. In the
case that it was one of the non-routable address space IPs, it would
return the associated key-hash and AP address with the .phantom
suffix, ie: <keyhash>.1.2.3.4.phantom. (The reason for this scheme
was that it would hopefully ensure that links to specific hosts could
not be usurped by other hosts registering their AP in the phantom
distributed hash table (DHT), since their key hashes would be
different. Incidentally this is only possible if an entry expires
from the DHT.)

Well, it's not a lot to contribute but with the list fairly silent re:
implementation I figured it'd be worth throwing something out there.
I'm not exactly a low-level coding legend but I think with the above
we can definitely cobble together an initial implementation, which
would be a big step forward.

Let me know what you think.

FYI there is a basic Ruby TUN/TAP implementation here:
http://labs.mudynamics.com/2007/12/04/ruby-tuntap-interface/
Also, there is a Ruby DHT implementation here:
http://rubyforge.org/projects/opendht/

- Walter

[Walter]

Short note - just discovered that TUN/TAP also works on other
platforms. From Wikipedia:

TUN/TAP drivers are available on at least the following platforms:

* FreeBSD
* Linux, starting around version 2.1.60
* Mac OS X
* NetBSD
* OpenBSD
* Solaris Operating System
* Microsoft Windows 2000/XP/Vista

With PowerDNS working on BSD, Solaris, Linux, OSX and Windows,
we'd have at least those platforms covered.

- Walter

[Christian Granström]

I think these are good ideas Walter. I have been investigating the tun/tap-idea aswell.

/Christian

2009/3/6 Walter <walter....@gmail.com>

--
Christian Granström
Tjursåker 2 Rutenlund
S-74595 Enköping
Sweden
mob: +46 (0)703 - 784971
skype: christian.granstrom

[Walter]

> I think these are good ideas Walter. I have been investigating the
> tun/tap-idea aswell.

Great!

Err, I just thought of a practical technique that could make those
using web browsers to access .phantom URLs more secure. It's
probably not original - I think something like this may have been
done for Tor - which I haven't really played with.

The idea is that we could install a web proxy like squid and have
it use the PowerDNS (or whatever DNS server) instance to do
its name resolution, while the rest of the system didn't.

Then, an existing browser plugin such as 'foxyproxy' for firefox
could be used to switch between 'phantom mode' and 'normal
web mode' by enabling/disabling use of the proxy.

In 'phantom mode', the locally running nameserver would
be called by the proxy server and would be configured to
reject the resolution of all non-phantom URLs, thereby
removing the possibility that a link to a regular web URL
could be used to reveal the identity of the browser.

It would also be possible to guard against this sort of
attack via a transparent proxy mechanism on all outgoing
TCP connections, though this would be more difficult
since websites running on non-default ports would have
to be caught and at the same time non-web services
that wanted to make outbound TCP connections would
have to be left alone .. so it would be a bit of a dodgy
hack... and likely infeasible to implement reliably.

- Walter

[Magnus Bråding]

Wouldn't it be problematic to make 100% sure that certain applications
only use this special interface, and doesn't ever "leak over" to the
"normal" interface sometimes? This must never be allowed to happen of
course.

The reasoning behind the original design of hooking the applications on
socket API level was to first avoid any messy driver code of any kind,
and also to make sure, in a simple way, that nothing can ever leak over
to the real internet connection.

Regards,
Magnus

Christian Granström wrote:
> I think these are good ideas Walter. I have been investigating the
> tun/tap-idea aswell.
>
> /Christian
>

> 2009/3/6 Walter <walter....@gmail.com <mailto:walter....@gmail.com>>

[Walter]

> Wouldn't it be problematic to make 100% sure that certain applications
> only use this special interface, and doesn't ever "leak over" to the
> "normal" interface sometimes? This must never be allowed to happen of
> course.

Good point.

After some consideration...

I think there is such a variety of existing IP applications that we
can't
actually anticipate the operational requirements of each... it's quite
an
ambitious goal to have any arbitrary application 'just work' on
phantom
and never have any cross-over (with regards to stored data, caches,
program state, or whatever).

Take the case of some applications that require resolution of a
particular domain name in order to function (localhost, software
update servers, commercial software auth servers, etc.).

Forcing such applications on to phantom from some lower level
as you suggest could be difficult or impossible to do automatically
while retaining functionality, since there will be issues (eg: name
resolution for an auth server would fail entirely and the program
would fail to start.).

The case of localhost is interesting too, since most servers
will default to wanting access to localhost/127.0.0.1 and may
sometimes either:

1. Provide a potential leak opportunity via the local host,
via arbitrary program state (very hard to assume on a
generic level of 'all IPv4 software ever written'), or
any network-related caches (same).

2. Fail entirely.

I'm not sure at what level of which operating system you suggest
fiddling with sockets or whatever... but to be honest I think this
approach is doomed to be painful and not 100% reliable due to
the variety of software that is out there, plus the mix of OSs.

Of course if there's some hack you could do to make certain
applications think that they were binding or connecting to
127.0.0.1 but actually connect to
127.<random-phantom-specific-prefix>.0.1, for example, then
that'd be great ... but the difficulties of implementing such
hacks with reliability on a wide variety of operating systems
may be(?) significant (to be honest I don't really know, I
don't write software at this level - it's just my gut feeling).

For a base requirement for most applications (point to point
communications over TCP, such as FTP/HTTP/SMTP, and
point to point communications over UDP, such as VOIP)
then I think the approach suggested would be reliable and
easy enough to implement on a range of platforms. And
for the more complex / interesting / popular case of web
browsing, the proxy/nameserver/plugin combo would
definitely work - provided that the browser actually did
use the proxy for every single connection (I'm not sure
how browsers are written, but I suspect this may not
be a 100% valid assumption.).

We probably can't get away from requiring
program-specific reconfiguration to use non-routable
(eg: 127.x.x.x) IPs that are mapped to APs and go
out through a phantom TUN/TAP interface once
people actually want to run services on the network.

The 'per program switch' concept is still a good idea for
implementing phantom (dis)connection for simplistic
non-browser programs. Particularly if there's some
way that the pipe backend to the nameserver
(eg: PowerDNS) is able to ascertain which program has
queried it, then it probably wouldn't be all that hard to
implement. (But there's probably still detail issues with
multi-process daemons... eg: many SMTP daemons)

How would a per-program switch work? One of those
preload library tricks would do it under Linux, though
I'm not sure how this carries over to OSX or 'doze.

Argh.

Perhaps it's just a fact of life that a perfectly simple
'click this button to phantomise this entire application'
concept cannot easily easily be realised, and the most
that is easily possible is to make that happen for most
(ie: simpler) programs. Later, we could bundle drop-in
configurations (with auto-detection routines) to handle
the case of more common software that cannot be
handled by the most simplistic changes (eg: daemons
that are not single process, commercial software
requiring auth servers that needs particular domain
names resolved - even responses spoofed, etc.).

Anyway I don't know the answers.

Just thinking out loud! :)

- Walter

[Walter]

> The 'per program switch' concept is still a good idea for
> implementing phantom (dis)connection for simplistic
> non-browser programs.  Particularly if there's some
> way that the pipe backend to the nameserver
> (eg: PowerDNS) is able to ascertain which program has
> queried it, then it probably wouldn't be all that hard to
> implement.

Reading the pipe backend protocol specification here:
http://doc.powerdns.com/backends-detail.html#PIPEBACKEND-PROTOCOL
... it says that with pipebackend-abi-version = 2 you
also get the local ip address on which the nameserver
was queried, which means if multiple instances of the
local nameserver are started (one for each local
program that is connected to phantom), then this
is possible.

- Walter

[Magnus Bråding]

First of all, I think that the main focus for the first implementation
should be the Windows platform, since it's here that you will find the
masses of users and interest, which will be cruical for a project like
this (of course design for compatibility with the other platforms should
still be a concern though!).

Second, the things we're discussing now are only "peripheral", and can
be made and tested in many different ways once we have a working
protocol core. Thus, the focus should probably be on that.

Finally, some details about the hooking: It should suffice to hook all
Winsock APIs (on user level) in Windows, and this is easy indeed.

Regards,
Magnus

[Goldy]

Agreed. Tun/Tap is a good way to go. We used this is Tor VM with a
customized version of QEMU that lets you do raw network bonding in
Windows. This is the same as VMware's Bridged network adapter.

http://www.janusvm.com/tor_vm/

[Goldy]

Negative.

By statically setting the IP config on the primary network interface
to a "dead" IP range and making sure not to set the route, you can
force the OS to use the Tun/Tap adapter. Basically, if the only route
out is through the Tun/Tap adapter, then the traffic will flow through
that interface.

Martin and I addressed this issue while working with the Tor Project.
The other advantage of doing it this way is security.
Here is an example.

Before Tor VM (or phantom in this case), my network adapter (let's say
Local Area Connection) settings would be:
Interface: Local Area Connection
IP: 192.168.1.100
Mask: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.1

So we know my internal network is 192.168.1.X.

Now, with a Tap/Tun device, we can make sure that all the traffic is
routed through the Tun/Tap device, AND PREVENT ANY POSSIBLE INTERNAL
NETWORK COMPROMISE (ie, protect the network from XSS, CSRF, Malware,
etc...).
Interface: Local Area Connection
IP: 10.123.255.52 (<- Random, not used IP or network)
Mask: 255.255.255.0
Gateway: <NULL>
DNS: <NULL>

Interface: Tap/Tun
IP: 10.111.222.2
Mask: 255.255.255.0
Gateway: 10.111.222.1
DNS: 10.111.222.1

Since the only interface at this point that has a gateway set is the
Tun/Tap, that is the ONLY way that data will be routed out. The Tun/
Tap interface would most likely be bonded to a application (phantom)
or virtual machine (phantom VM). Obviously there is a bit more detail
here that I'm not getting into (like the damn windows networking
stack, routing metric, etc.....grrr)

This makes your configuration 100% leak proof.
We've spent many years looking into this, and this is the best model
we've been able to produce between JanusVM and Tor VM.

Socket level API's can be bypassed with the right side channel
attack. I'm working on a site right now (another project) that will
be showing several examples of this.
It really is best to capture all the data at a lower level (OSI layer
3...or better yet....layer 1 :), and route it through a VM.
Applications (like phantom) can be protected in a VM too.

Thoughts?

On Mar 6, 1:37 am, Magnus Bråding <magnus.brad...@fortego.se> wrote:
> Wouldn't it be problematic to make 100% sure that certain applications
> only use this special interface, and doesn't ever "leak over" to the
> "normal" interface sometimes? This must never be allowed to happen of
> course.
>
> The reasoning behind the original design of hooking the applications on
> socket API level was to first avoid any messy driver code of any kind,
> and also to make sure, in a simple way, that nothing can ever leak over
> to the real internet connection.
>
> Regards,
> Magnus
>
> Christian Granström wrote:
> > I think these are good ideas Walter. I have been investigating the
> > tun/tap-idea aswell.
>
> > /Christian
>

> > 2009/3/6 Walter <walter.stan...@gmail.com <mailto:walter.stan...@gmail.com>>

[Magnus Bråding]

> By statically setting the IP config on the primary network interface
> to a "dead" IP range and making sure not to set the route, you can
> force the OS to use the Tun/Tap adapter. Basically, if the only route
> out is through the Tun/Tap adapter, then the traffic will flow through
> that interface.

The main problem with this is that you lost 99,8% of the world's
potential users in that first sentence... :-) :-/ One of the design
goals, and hopefully winning concepts of Phantom is for it to be easy to
use, and to be easy to use with all (or at least most) existing
programs, with the mere "flick of a switch".

I really don't want people to have to mess with their network config
(they might not even be able to, due to insufficient privileges), or
other "scary" stuff like e.g. running a separate VM, just to be able to
use Phantom for some application. There are already nice products that
do that, e.g. Janus VM. ;-) Nothing would of course stop anyone from
building such a VM based on Phantom too, but I just really want the
"main" version to be free of such requirements.

Makes any sense?

Equally techie-sexy? No.

Much more likely for mass adoption and thus in the end better anonymity,
speeds and functionality? Yes!

> Socket level API's can be bypassed with the right side channel
> attack. I'm working on a site right now (another project) that will
> be showing several examples of this.
> It really is best to capture all the data at a lower level (OSI layer
> 3...or better yet....layer 1 :), and route it through a VM.
> Applications (like phantom) can be protected in a VM too.

It will indeed be very interesting to see this project of yours, and I'm
sure it will be as good and clever as usual. Luckily though, I'm quite
sure that you can help us counter such attacks in the Phantom design
too. ;-)

Regards,
Magnus