Re: Demonstration of a tinc network linked through Tor v3 onions
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.
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.
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.
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. See also OnionBalance regarding overall subject.
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.
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 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.
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.
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"
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. 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. Anyway, happy hacking :)
On Monday, April 29, 2019 5:06 AM, grarpamp <grarpamp@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.
On 4/29/19, Ann Brown <annobrown@protonmail.com> wrote:
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.
OnionCat doesn't talk to tor controller to "open" and manage its own circuits, it's subject to SocksPort circuitry in tor(1). onion to onion uses same circuit, while circuit remains valid. usefeature extended_events verbose_names setevents stream circ
But it's still voluntary, right? So one can random walk until non-blocking
Yes. Some relay operators may be staying on those older versions for that reason.
On Thursday, May 2, 2019 2:09 AM, grarpamp <grarpamp@gmail.com> wrote:
On 4/29/19, Ann Brown annobrown@protonmail.com wrote:
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.
OnionCat doesn't talk to tor controller to "open" and manage its own circuits, it's subject to SocksPort circuitry in tor(1). onion to onion uses same circuit, while circuit remains valid. usefeature extended_events verbose_names setevents stream circ
OK, thanks. My best guess then is differences in how Tor handles v2 vs v3 onions. I can't test OnionCat with v3 onions, so I'll do tinc with v2 onions, and see how it works. > > But it's still voluntary, right?
But it's still voluntary, right? So one can random walk until non-blocking
Yes. Some relay operators may be staying on those older versions for that reason.
Right. Sent with ProtonMail Secure Email.
Non corporate? >>> non navy how bout ? It has been analyzed that USG is Authoritarian Capitalism and a hybrid of corp and gov ... > interlocked in a special way ... hand in hand ... BFF... heart emojis Why navy need you on tor network? Cover On Mon, 29 Apr 2019 at 08:07, grarpamp <grarpamp@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.
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.
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.
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.
See also OnionBalance regarding overall subject.
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.
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 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.
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.
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"
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.
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.
Anyway, happy hacking :)
-- <https://about.me/carimachet?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb> cari machet about.me/carimachet <https://about.me/carimachet?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
participants (3)
-
Ann Brown -
Cari Machet -
grarpamp