Demonstration of a tinc network linked through Tor v3 onions

[Ann Brown]

On Monday, April 29, 2019 5:06 AM, grarpamp <grarpamp at gmail.com> wrote:

> > > It can be communitied, or forked.
> > > Seems unlikely.
>
> Either can work if people want them to,
> that is the very point of opensource if so merited.

True. Still seems unlikely.

> > > > Reported bugs have been closed without action.
> > > > What ticket numbers are of interest?
>
> > https://trac.torproject.org/projects/tor/ticket/24902
> > https://trac.torproject.org/projects/tor/ticket/19966
> > https://trac.torproject.org/projects/tor/ticket/24973
>
> > I can't find the one where they explicitly said that it's not worth fixing
> > v2-specific bugs.
>
> Statements always nice to have for reference.
> Bugs not needing architecture rework should be fixed.

Agreed. I'll see if I can find more abandoned tickets.

> > > > Fetches of v2 rendezvous descriptors fail, and so OnionCat services are "unavailable".
> > > > Analysis? Not really, just lots of notices logs. Basically the same stuff as
> > > > in #19966. Lots of it.
>
> Any tickets should be revalidated using current release
> on unix, then bumped if still valid to get them fixed.
> The version issues below can be gamed as needed if applicable.

I was focusing on getting something that worked well. Not on validating Tor tickets. Perhaps I'm too cynical, but I doubt that Tor Project is much interested in supporting stuff like this.

> > how tinc uses onion circuits vs how OnionCat does.
>
> They're just apps bound to onions, no special knowledge of tor.
> There can be things like layer 2/3/+ keepalive packets, etc
> going on depending on the app. Circuit timeout settings, etc.

I was wondering whether OnionCat opens a new circuit for each packet stream, and whether tinc (like OpenVPN) instead uses circuits on longer timescales. I suppose that I could log that, and see.

> See also OnionBalance regarding overall subject.

That would be an interesting tweak. I'll look into it.

> > Or maybe v3 onions work better than v2 onions, either because
> > they're better designed, or better supported.
>
> v2 is still in the code and will be for a long time,
> even possibly modularized for third parties indefinitely.
> So if there are v2 problems, ticket them, join together,
> and get them fixed.

True. I'll do some more testing.

> > It's also possible that I've tested them differently. With OnionCat, I was
> > using Freenet. And with tinc, I've used bittorrent. So maybe Freenet and
> > bittorrent have different enough packet dynamics.
>
> Tests should only change one variable at a time.

I know that. But here, once I'd decided to try tinc, using v3 onions seemed like the better option. But yes, I'll do some more testing.

> > I initially picked that IPv4 range because of ChaosVPN. But maybe it'd be
> > better to integrate with dn42, and use IPv6
>
> IPv4 is dead, IPv6 gives much more room for people to play
> without colliding with each other or other things... lots of
> people's stacks and private usage treat RFC1918 as their own,
> not that of some third party apps (which really need to use their
> own space outside of RFC1918, etc). So you need more space.
> Overlays can use either 4/6 on clearnet and emulate either
> 4/6//N-bits for internal use, and can also setup separate instances
> integrating into each. IPv6 has some space options, and lots
> of unallocated slack space. But also search "AF_OVERLAY"
> for a grander more universal overlay interop scheme than
> even IPv6 can ever provide.

OK, I'll look into it. The internal network is pretty much irrelevant to how tinc (and so this setup) works.

This is now at https://github.com/annymous/oniontinc, by the way. It's very easy to test. All that's needed is a Debian stretch x64 VM.

> > What worries me is that the Tor community will see this
>
> Though exit is and should be a priority in tor at the moment
> given the gamut of todays overlays, tor does not, should not,
> and won't have exclusive claim to that functionality in both other
> currently developing and future overlay networks.

True. And overlays that don't use exits, and provide alternate exits, are useful.

> > as DDoS, and implement blocks.
>
> tor-0.3.2.9 was the last version without some statistical blocking
>
> changelog 0.3.2.10: "denial-of-service mitigation"

But it's still voluntary, right? So one can random walk until non-blocking guards are found. I have scripts for that, but didn't need them for this.

> > I wonder whether they've done that with OnionCat.
>
> No. Tor can't pick out apps like that, only patterns,
> those can be really hard for an overlay (like tor) to
> discern, and impeding of many false positive users.

Patterns like "Hidden service [x] exceeded launch limit with 10 intro points in the last [x] seconds. Intro circuit launches are limited to 10 per 300 seconds." aren't that hard to find.

> Fork tor if tor censors people (they've already tried to
> censor relay operators and posters for speaking freely).
> Say to a non-corporate more globally volunteer opensource tor.
> Or simply support the development of and migrate to
> better more resistant overlay networks going forward.
> Diversity in designs, and with more deployed overlay
> networks in live competition, are important.

I doubt that Tor will get forked. And why should it, really? It would be far better to implement something that does a better job against traffic analysis.

> Anyway, happy hacking :)

Thanks.

Sent with ProtonMail Secure Email.