[tor-talk] playing with OnionCat, VPNs and stuff

[Mirimir <mirimir@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For the past couple months, I've been playing with OnionCat, exploring
its capabilities and potential use cases. Overall, I'm very impressed.
Basically, it enables point-to-point links between onion servers, in a
common IPv6 /48. And it's trivial to overlay VPNs, running in IPv6 UDP
mode, when you want full routing.

It's true that some of the use cases that I've explored involve
substantial traffic among onions. However, there are no exit relays
involved, and it's my impression that onions are underutilized. And
indeed, it's arguable that additional internal traffic improves
anonymity generally for Tor users.

A trivial use case is two onion servers, linked with OpenVPN (mode
p2p, proto udp6) via OnionCat. VPNs in UDP mode tolerate latency and
jitter well, and using UDP via TCP doesn't trigger retransmission
insanity. Latency between onions is typically 500ms to 1500ms, with at
most 10% packet loss.

For example, one can run a server (web, torrent tracker, or whatever)
on one onion. It can be reached at its onion hostname (directly, and
via OnionCat) and also through the OnionCat/VPN-linked onion, which
serves as a reverse proxy, at its public IP address or hostname.

The reverse proxy is discoverable, of course. However, it knows only
the OnionCat IPv6 address of the server, which is derived from its
OnionCat hostname. The server binds to the VPN tunnel, so the proxy
doesn't see its public IP address. And the proxy contains no content,
or user information. The proxy's host and ISP can log traffic, of
course. But that's the trade-off for providing open Internet access.

I also have a Freenet onion. It's fully reachable by opennet and
darknet peers, both at its OnionCat IPv6 address, and through its
reverse proxy on the open Internet. Latency is borderline high for
Freenet, and that causes ForwardRejectedOverload errors with some
peers. But I don't see errors in connections with my other test nodes,
which also have high connection timeouts. And so I suspect that this
could be resolved if connecting peers increased connection timeouts.

One can also connect many onion servers via full-mesh VPN in UDP mode,
such as tinc or PeerVPN. That works well enough with some distributed
file systems. Tahoe-LAFS and LizardFS work. They're slow, but they can
be tweaked to tolerate the latency and jitter. Unfortunately, LizardFS
only seems to work in chunk-replication mode, and not with erasure
coding or XOR goals. I expect that QFS would also work, and maybe even
Cleversafe, if its erasure coding handles latency well enough.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYATFLAAoJEGINZVEXwuQ+0fcH/16S+RsRGgY7fAsoy5w4Sx5O
49qUL2NZGugCVnsgNim9Ruj5xigAO2sazhXRpsIsgU14eZKDDnjwn1zt5hRkAeJu
tSCK/y00xtQ7tLeOcP9vCsQ3Vsk3/p4ygcAovvmXeO8Kz74JtqYh5AyVKmLBzOZC
v+3AnM0+KiDaTldzn86RyJ59HIfqY54dkk5AnIVpww83d+c1B/KY/Fgi6c4/JMU+
s3LI738DAz1V0IwhgkqUWo6bDeJpvFnGtf3ffHtXMjcVGHZtcKH8yV9n6bSDcKuV
Rfun2LJeoBiK0mDjvI9PCbQQ13F8JfF3Ijr5qGL4UVYMucFkdSxfOZdB/26BT+4=
=NhGC
-----END PGP SIGNATURE-----
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk