Re: [tor-talk] [Cryptography] Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

[Mirimir <mirimir@xxxxxxxxxx>]

On 01/25/2019 04:32 AM, Alec Muffett wrote:
> On Fri, 25 Jan 2019, 10:43 Mirimir <mirimir@xxxxxxxxxx wrote:
> 
>>
>> I don't do audio on this box.
> 
> 
> I'll wait; most questions about "what do [I] mean?" are answered in that
> video.

OK. Hopefully you point to some resources for learning that stuff.

> Let's say that I have a bunch of VPS, running Tor and OnionCat. Each has
>> the others' OnionCat IPv6 addresses in its /etc/hosts. Now I can use any
>> app that talks TCP/IP, without customization (except re latency).
>>
> 
> How are you going to inhibit leaks and connections to "promiscuous" service
> listener-sockets over the LAN interface? Perhaps firewalls? Yet more /
> additional server misconfiguration opportunities?

Yes, with OnionCat, you're on an open LAN. So I use restrictive iptables
rules for IPv6. Just as I do for IPv4. I drop all packets by default,
and allow only required addresses and ports.

> Safer, instead, for the client to be clear and explicit about what manner
> of network address it wishes to connect to.

I suppose. But way back when, one could have used the same argument
against development of TCP/IP. Perhaps you do. But damn, it'd be a very
different Internet. And perhaps you would have preferred that. Yes?

> I'm sure that one could write code that did all the same stuff, using
>> actual v3 onion hostnames.
> 
> 
> 
> I've done similar hacks using /etc/hosts:
> 
> https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md
> 
> ... but that is mostly a server-side convenience, and not strictly
> necessary.

OK, thanks.

> .What do you mean by "services"?
> 
> 
> As above.
> 
> 
> If all you have is SOCKS5, you're pretty
>> limited.
> 
> 
> My experience suggests otherwise, and I am calling for expansion in this
> space.
> 
> 
> you use shims like AF_X25. I never had to use that, but I'm sure that
>> OnionCat is far less hassle.
>>
> 
> How many systems do you have using it?
> 
> -a

My friends and I use OnionCat quite heavily. We're interested in
reliable private networking for mutually anonymous servers. Primarily as
a capability, and not for any particular application. But for example,
say that one must transfer filesystem images or VMs, for backup or
sharing. We've found that bbcp (using the MPTCP kernel, with multiple
OnionCat interfaces) works very well for that.

Stuff that requires UDP transport is especially problematic with Tor.
Private Docker registries, for example. We've tested a few VPNs in TCP
mode, but nothing has proved as reliable as OnionCat. It is necessary to
use custom wrappers, I admit, because the stock systemd service is quite
fragile. Or maybe it's just that OnionCat is no longer maintained.

In recent years, my friends and I have played with various P2P networks
(such as Freenet, BitTorrent and various VoIP apps) and distributed
filesystems (such as LizardFS, QFS and Tahoe-LAFS). The P2P stuff tends
to work well enough with Tor+OnionCat. But high latency tends to be
problematic for distributed filesystems (albeit less so for Tahoe-LAFS).

I appreciate concerns about overloading the Tor network. However, it's
arguable that increased traffic among onions, as chaff, would actually
improve anonymity for other users. And it's my understanding that it's
exit bandwidth that's most limited. But OnionCat puts no explicit load
on exit-only relays.

From https://metrics.torproject.org/bandwidth-flags.html I get that
relays without the exit flag (middle relays and most guards) are
underutilized. Currently, 110 Gbit/s out of 240 Gbit/s is consumed.
That's less than 50%, on average. Also, it's my impression that, given
Tor's relay-selection logic, only the fastest non-exit relays get much
use at all. And based on a recent thread on tor-relays, even some
high-speed non-exit relays see only ~20% utilization.

Anyway, that's why I value OnionCat. If I had to, I could learn to use
v3 onion sockets. But I fear that it would be painful.
-- 
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