I would like to know if anyone here has been experimenting with
server to server peering over Tor.
If you've been working on this or are interested in working on
this, please reply or shoot me an email.
I would like to know if anyone here has been experimenting with server to server peering over Tor.
From my experience with running Tor onion services, it's quite easy to set up a
server that can receive traffic over Tor. However sending traffic over Tor is another issue. It requires either setting up system proxies for outgoing traffic or wrapping the INN binaries in the torsocks application.
If you've been working on this or are interested in working on this, please reply or shoot me an email.
I have done this and it works fine. My previous partner in this project (rocksolid), trw, wrote a script to handle peering over tor and it works well. I'll post the script below. If you want to test, I'll be happy to
test with you. Again, credit to trw for the script.
On Wed, 18 May 2022 09:12:42 +0000, Retro Guy wrote:
I have done this and it works fine. My previous partner in this project
(rocksolid), trw, wrote a script to handle peering over tor and it works
well. I'll post the script below. If you want to test, I'll be happy to
test with you. Again, credit to trw for the script.
Hi Retro Guy,
Thanks for the script, I will look into this. I'll first try to establish
a connection between two VMs and then I may come back to you about peering
if everything works.
I wonder if creating a system service (e.g. systemd) would be more
beneficial than just having a bash script running in the background.
I have done this and it works fine. My previous partner in this
project (rocksolid), trw, wrote a script to handle peering over tor
and it works well. I'll post the script below. If you want to test,
I'll be happy to test with you. Again, credit to trw for the script.
socat TCP4-LISTEN:"$localport",reuseaddr,fork SOCKS4A:"$proxyip":"$onion":"$onionport",socksport="$proxyport"
On 5/18/22 3:12 AM, Retro Guy wrote:
I have done this and it works fine. My previous partner in this
project (rocksolid), trw, wrote a script to handle peering over tor
and it works well. I'll post the script below. If you want to test,
I'll be happy to test with you. Again, credit to trw for the script.
My concern about peering over Tor is the absence of sending system identification. It is typical for peering privileges to be associated
with the source IP. So, based on the very nature of Tor -- as I
understand it -- anyone that knows the Tor hidden service address will
be viewed as the same source and thus have the same privileges.
Does this mean that people will be using something else at the NNTP
level to manage peer identification and permissions therein?
Or is there some sort of Tor restriction on clients that can connect to
a Tor hidden service?
socat TCP4-LISTEN:"$localport",reuseaddr,fork >> SOCKS4A:"$proxyip":"$onion":"$onionport",socksport="$proxyport"
I don't see anything in the socat command to belay my concern.
It seems as if the command simply stands up a local listening socket
that passes through the Tor network to a news server that's behind a Tor hidden service.
What am I missing?
Yes, that's true. I2P makes it much easier.
While I'm not sure if using or understanding it correctly, I use a
'password' in innfeed and incoming.conf. While it seems to work
ok, I'm not sure why you can set a username in innfeed, but not incoming.conf. It's been a while since I've spent much time on this.
The newer v3 tor addresses are a bit better, as they shouldn't be
known to anyone unless you provide them the address. I do use a
different address for each peer.
Yes, that's exactly what it's doing, nothing more.
All your concerns are valid, so I don't think you're missing anything.
On 5/20/22 9:50 PM, Retro Guy wrote:
Yes, that's true. I2P makes it much easier.
Would you please elaborate on what I2P does that's different?
The newer v3 tor addresses are a bit better, as they shouldn't be
known to anyone unless you provide them the address. I do use a
different address for each peer.
If I understand correctly, Tor v3 is effectively a larger address /
search space. Read: Bigger hey stack to hide in. ;-)
All your concerns are valid, so I don't think you're missing anything.
As I see it, there should be something that provides client
authentication at the Tor layer or the INN / NNTP layer (preferably
something more than /just/ a password).
I suppose that you could add an additional VPN layer between Tor and
INN. Though now things are getting really complicated, and one needs to ponder what the complication provides.
So I'll back up and ask what is the motivation for running / peering
with INN via a Tor hidden service?
On 5/20/22 9:50 PM, Retro Guy wrote:
While I'm not sure if using or understanding it correctly, I use a
'password' in innfeed and incoming.conf. While it seems to work
ok, I'm not sure why you can set a username in innfeed, but not
incoming.conf. It's been a while since I've spent much time on this.
I don't know. That's probably a question for those that know INN better
than I do.
The newer v3 tor addresses are a bit better, as they shouldn't be
known to anyone unless you provide them the address. I do use a
different address for each peer.
If I understand correctly, Tor v3 is effectively a larger address /
search space. Read: Bigger hey stack to hide in. ;-)
As I see it, there should be something that provides client
authentication at the Tor layer or the INN / NNTP layer (preferably
something more than /just/ a password).
So I'll back up and ask what is the motivation for running / peering
with INN via a Tor hidden service?
TLS itself (which hopefully one who cares about privacy uses on their
NNTP servers!) allows authentication via client-side certificates too.
I do not think inn implements that possibility directly (at least it did
not when I last looked at it in more detail - which was admittedly long
ago).
Although AUTHINFO password is probably just fine for most use cases (if
it is of reasonable complexity).
I know /of/ I2P, but very little about it. Most of that is
that the client is written in Java, which is a bad thing IMHO.
[...]While I'm not sure if using or understanding it correctly, I use a
'password' in innfeed and incoming.conf. While it seems to work
ok, I'm not sure why you can set a username in innfeed, but not
incoming.conf. It's been a while since I've spent much time on this.
Although AUTHINFO password is probably just fine for most use cases (if it is of reasonable complexity).
That is assuming that incoming.conf AUTHINFO feature actually works correctly :-)
Hi Matija,
[...]While I'm not sure if using or understanding it correctly, I use a
'password' in innfeed and incoming.conf. While it seems to work
ok, I'm not sure why you can set a username in innfeed, but not
incoming.conf. It's been a while since I've spent much time on this.
Although AUTHINFO password is probably just fine for most use cases (if it is
of reasonable complexity).
That is assuming that incoming.conf AUTHINFO feature actually works correctly :-)
Yes, I confirm AUTHINFO works fine in both innfeed and innd.
I thoroughly tested it when implementing NNTP v2.
The reason behind that behaviour is historical. Prior to INN 2.6.0,
released in 2015, a remote peer could just send "AUTHINFO PASS" (without
a previous "AUTHINFO USER" command), which is contrary to RFC 4643, to
be authenticated.
innd does not historically take into account a username, but only a
password.
innd does not historically take into account a username, but only a
password.
Thank you for the info and confirmation. It works for me also, but I
just never understood if I was using it correctly due to USER only
being available on one end.
Sure - as are *all* username/password schemes (and even RSA keys,
TLS etc)...
As long as attacker can try a "key", and see if worked, the system is suspectable to brute force attacks. It is all about bigger haystack,
to make bruteforcing non-viable.
TLS itself ... allows authentication via client-side certificates too.
I do not think inn implements that possibility directly (at least it
did not when I last looked at it in more detail - which was admittedly
long ago).
Although if inn is in dedicated container (or other services do
not mind), one could probably choose to trust only their local CA
(i.e. remove all other CAs from /etc/ssl/certs), and sign only trusted
peer certs with that local CA.
Or one could use external TLS wrapper for inn (like stunnel)
to accomplish that client certificate verificaton (i.e. stunnel "verifyPeer=yes").
There are two features in I2P that help with this.
This is something I've considered. It shouldn't be too difficult,
but I haven't felt the need to put time into it. Maybe in the future.
The motivation is the same as why I run my own news servers instead of
use someone else's. Why I run my own mail server. Why I develop a web interface for usenet newsgroups, and my own php news server. Because
it's fun, a challenge, and keeps my brain busy.
None if this will change the world, it's just a hobby that I enjoy.
i2pd - a full-featured C++ implementation of the I2P router
On 5/21/22 12:00 AM, Retro Guy wrote:
The motivation is the same as why I run my own news servers instead of
use someone else's. Why I run my own mail server. Why I develop a web
interface for usenet newsgroups, and my own php news server. Because
it's fun, a challenge, and keeps my brain busy.
Okay. I can get behind that. But where does the academic exercise end
and practicality take over? E.g. is establishing peers via I2P and / or
Tor something that people are interested in? Or is this truly an
academic exercise.
Aside: I can get behind purely academic exercises. I just want to know
if that's all this will be or if there is more to this.
I would assume that my peers in I2P, I have three, probably do so for
the same reasons that I do, because we can. You will find, for example,
a poster in this group that runs their own server and peers through
mine via I2P.
You can't trace them, and they are making valid and useful posts, so
there are people in these networks that are valuable to the community,
and enjoy the exercise of trying something different.
One reason for me is to stay in touch with alternative networks. It
keeps me up to date on I2P and Tor.
These networks may get a bad reputation from some bad players, but
they are functioning networks, and there are plenty of people using
them for very valid purposes.
I'm old enough to remember (and I would guess many of us in this
group are), when using a BBS or the internet made you suspect.
In the early 90s, my wife at the time found me talking (voice) to
someone online using powwow and accused me of all sorts of stuff. It
was new to me, voice over internet, and I just had to mess with it. I
still have that same interest and excitement doing things online.
From my experience with running Tor onion services, it's quite easy to set up a
server that can receive traffic over Tor. However sending traffic over Tor is another issue. It requires either setting up system proxies for outgoing traffic or wrapping the INN binaries in the torsocks application.
On 2022-05-17, Jason Evans <jsevans@mailfence.com> wrote:
From my experience with running Tor onion services, it's
quite easy to set up a server that can receive traffic over
Tor. However sending traffic over Tor is another issue. It
requires either setting up system proxies for outgoing
traffic or wrapping the INN binaries in the torsocks
application.
Late to the party I know, but I thought I might mention Yggdrasil:
Late to the party I know, but ...
... I thought I might mention Yggdrasil:
https://yggdrasil-network.github.io/
Yggdrasil is an IPv6 global mesh network. It is always end-to-end
encrypted, and each node's IPv6 address is derived from its public key.
You can therefore do IP-based auth in traditional ways (in INN's config
or with firewalls). Yggdrasil shows up as a tun-type interface on
your system.
Yggdrasil's goals are somewhat different than Tor's; it doesn't aim
to provide the kind of strong anonymity that Tor does, but rather
it aims to be a performant first-class network with modern security
and routing.
I run NNCP over it and therefore already offer Usenet via NNCP over
Yggdrasil for those interested in that kind of peering.
There is no reason that you couldn't run INN over Yggdrasil because
it's just another interface to the system. Yggdrasil's design nicely
avoids a lot of problems with traditional IP networks (giving you a
"direct" unfiltered connection to the network, the IP address follows
the device wherever it goes, etc.)
<grin> I'm glad :-)
Ah, I see I'm not the only one that had that thought!
Feel free to ask me also, by email or whatever newsgroup would be
appropriate (let me know if you go to a different group so I can make
sure to subscribe)
I think they would put it slightly different; that the overlay network
is one of the key features, but is a bit limiting in terms of how to
think about it.
Say, for instance, that you have a bunch of nodes using ad-hoc wifi,
and they're running Yggdrasil. Some of the laptops at, say, the
northern end of the location aren't within RF range of the ones at the southern end. But since nodes within a broadcast domain auto-discover
(via broadcast beacons) each other and form a mesh, every node can communicate with every other node, using go-betweens when necessary.
All it takes is one node to have access to other nodes and suddenly
all of them do. If one node has access to the Internet, then all
of them can reach the global Yggdrasil network. It will overlay
across the public Internet when it's the best path, but you don't
even have to have a DHCP server for them to talk on a LAN (it uses
IPv6 link-local addresses in that case).
There's nothing that says that when you peer over the Internet,
you must peer with one of the public peers. If you only peer with
private peers, then you can effectively build an auto-meshing VPN.
As an aside, I love it for laptops. Yggdrasil+mosh is the perfect
remote terminal; close the laptop at home, open it up at a coffee
shop or whatever, and the laptop still has the same Yggdrasil IP,
has discovered that it needs to relay via the Internet instead of the
LAN to its mosh/ssh destination at my home network, and the session
just keeps going; all that's different is higher ping times. Go back
home and it goes, "oh hey, now I can talk to you directly again,
let's do that" and ping times go back down.
It's also on my list. I run INN inside Docker and would like to run Yggdrasil inside Docker as well, and that is a little more complicated
due to the kernel permission structure around tun devices. But it's
on my list for sure.
It is one of those "wow, this makes security so much easier" kinds
of things. Like, all those techniques from the 80s and 90s of IP-based security suddenly work again :-)
On 6/14/22 6:34 PM, John Goerzen wrote:
Late to the party I know, but ...
ON topic and less than a month late, seems /okay/ to me.
Aside: Interesting (partial) name collision between "Yggdrasil Network"
and "Yggdrasil Linux" fro a VERY long time ago.
I have a lot of questions, many of which I suspect will be answered when
i read about Yggdrasil Network at the link you provided.
My initial assessment is that it's trying to be an overlay network.
Fair enough.
Presuming that my assumption is close and that I don't find anything
that disturbs me, I'll probably look at implementing Yggdrasil Network support.
My gut reaction is that this is creating what I presume to be
point-to-point tunnels and using source & destination IP addresses
therein. Maybe it's lightweight tunnels that don't have dedicated
interfaces and choose encryption based on source & destination IP addresses.
As an aside, I love it for laptops. Yggdrasil+mosh is the perfect remote terminal; close the laptop at home, open it up at a coffee shop or whatever, and
the laptop still has the same Yggdrasil IP, has discovered that it needs to relay via the Internet instead of the LAN to its mosh/ssh destination at my home
network, and the session just keeps going; all that's different is higher ping
times. Go back home and it goes, "oh hey, now I can talk to you directly again,
let's do that" and ping times go back down.
Feel free to ask me also, by email or whatever newsgroup would be
appropriate
I have a lot of questions, many of which I suspect will be answered when
i read about Yggdrasil Network at the link you provided.
Grant Taylor wrote:
On 5/20/22 9:50 PM, Retro Guy wrote:
Yes, that's true. I2P makes it much easier.
Would you please elaborate on what I2P does that's different?
There are two features in I2P that help with this. One is that you
can tie a client key (generated by the client) to a server tunnel.
You can whitelist key(s) for this tunnel, and only allow specific
clients to connect.
Den 2022-05-21 skrev Retro Guy <retro.guy@rocksolidbbs.com>:
Grant Taylor wrote:
On 5/20/22 9:50 PM, Retro Guy wrote:
Yes, that's true. I2P makes it much easier.
Would you please elaborate on what I2P does that's different?
There are two features in I2P that help with this. One is that you
can tie a client key (generated by the client) to a server tunnel.
You can whitelist key(s) for this tunnel, and only allow specific
clients to connect.
Sorry for coming in so late, but I want to point out that Tor does
support client keys with for onions. You can generate keys and
configure Tor to only allow connections from clients with specific
keys.
It is a useful feature that can definitely increase security should
your onion address leak for some reason so I thought it worth
mentioning.
There are instruction available from the Tor project at https://community.torproject.org/onion-services/advanced/client-auth/.
What addresses does Yggdrasil Network use? It looked to me like they
were using IPv6 addresses that aren't currently routed globally. I
think I saw a few different /16 xx:xx::/xx networks listed in
documentation. But I didn't see anything that actually clearly sated
what Yggdrasil Network uses.
I naively assume that standard destination based routing is used such
that the kernel sends traffic for various destinations into the tun0 /
ygg0 / etc. network interface and the Yggdrasil Network daemon handles
the rest.
My opinion is that the Yggdrasil Network's website is lacking a
significant amount of technical documentation.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 64:57:34 |
| Calls: | 6,712 |
| Files: | 12,244 |
| Messages: | 5,356,203 |