[Tahoe-dev] Tahoe/Foolscap use of SSL

[Brian Warner]

>> I am a little disappointed that Foolscap is just using SSL rather than
>> end-to-end encryption. More worrying is the lack of any mention of NAT
>> traversal.

Howdy Wes.. as the author of Foolscap, I'd be interested in hearing your
thoughts about how it uses SSL. What sort of thing would be less
disappointing?

For reference, Foolscap uses a "secure reference" model, in which a so-called
"FURL" (Foolscap URL) identifies an endpoint. This FURL contains the hash of
the SSL certificate used by the target process, and is verified after the
STARTTLS step, protecting it against man-in-the-middle attacks. We ignore the
CA structure entirely, and Foolscap generates/uses self-signed certificates
by default. When one node is talking directly to another (no NAT or
relaying), I think this provides end-to-end encryption.. if not, I'd like to
understand why.

The current tahoe release makes no attempt to accomodate nodes that are stuck
behind a NAT box. (well, they'll connect to all of the publically-visible
nodes, but none of the other NAT-bound nodes will see them, so they'll just
see a subset of the full mesh).

Our vague plans to address this will start with building some relay
functionality into/on-top-of Foolscap. One form of relay would be a
man-in-the-middle "application-level" relay, in which the NAT-bound node A
registers an endpoint with a relay server B, then advertises the FURL that
points to that relay's object instead of its own. This would use a "membrane"
on B to translate any of A's other objects into proxies that live on B. The
initial setup of this is pretty easy to build, the membrane less so. And of
course the relay gets to see all of the traffic.

The better form of relay is a connection-based one, in which the relay is
conveying crypttext bytes instead of plaintext plaintext messages. The setup
for this is slightly more difficult (and with PyOpenSSL it requires the use
of an additional loopback socket), but it removes the need for the membrane
and doesn't give the relay server access to the message plaintext. I intend
to add this functionality into Foolscap once we figure out how we want to use
it.

The next step beyond that would be actual NAT traversal. We're still looking
for decent ways to accomplish that, probably based off of a more
datagram-oriented form of Foolscap, plus STUN. Getting a functional UPnP
client working may help somewhat, but from what I've read, most UPnP routers
are broken.

Incidentally, our existing commercial (non-free-software) product uses relay
and UPnP exclusively.


thanks for your comments!
 -Brian