Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
Hello, as tb discussed further with developers of Tor, the concept of "Reflec-Tor"s (and Exit-Nodes to be seen also as an Entry-Node) might have an impact like Snowflakes for Chat and Messaging over Tor and addresses opinions of Relay admins and university research too. Regards
---------- Forwarded message --------- Date: Di., 16. Juli 2024 um 20:36 Uhr Subject: Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes To: tor-dev@lists.torproject.org
System wrote via Tor Project noreply@forum.torproject.org:Feedback: Please submit the proposal also to tor-dev: tor-dev Info PageIntroducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflect...
==============================================================Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
*Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay |*
Hello,
I think this belongs to this core, general, relay topic-forum, as it is also a development & community issue, request and efford, I post it here into the reddit forum for your core discussion:
The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are developed futher to be also an Entry-Node.
Some may remember when gnutella got hybrid with edonkey and then also with torrent, Mike Stokes from Shareaza did that.
The idea today, 20 years later, is to add some Echo-capabilities to Tor in regard of the servers for Exit and Entry.
*Vision: Every (updated) Exit-Node is an Echo-Server - For a better Tor-Messaging.*
What does that mean?
An Echo-Server is a server for chat-messaging to send an incomming message packet again out to all connected clients at the moment. Ping-in and Ping-Out to all. That simple, that's why it is called the Echo. Like a shout in front of a forrest, all connected users can hear and get the (encrypted) shout or message or packet back from the tree wall.
There are 3 software applications for Echo-Servers:
-
https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener Tab) -
https://github.com/textbrowser/smokestack (java for Android) -
https://github.com/textbrowser/spot-on-lite (headless deamon for Linux)
Now, the Listener function with ping in and ping out should be implemented within a Tor-Exit-Node.
When it comes to Tor-Messaging, there are some pathes possible:
A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets)
B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob (Echo Tor-tunneled)
C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct connection to Echo-Server with only encypted packets)
The request here is to build and develop option A.
That is just right now also possible, by an Exit-Node of Tor running the Echo-Server-Software on the same machine in parallel. Just the port is different.
This is an idea for some might be new, but thinking Tor Messaging a bit, it comes quickly to this ideas and better soluttion.
The way to connect
D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion Server v3 - Tor-Chat-Client-Bob
is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch.
Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Don't quote me on that, but as core developers and community members you might be in contact with those who experience this.
Furthermore the Messaging clients are not advanced in functionality, nor advanced in strong encryption.
It would be third a long development way to got that route.
It is cost effective and needs cappable developers.
Some project have stamped on and made a workable client, but does that unite all our power in the sense of Tor-Messaging?
Messaging needs a Vision and Statement from the Tor-Core-Developer team with a discussion in the community in that regard with honor to the individual projects and also with support for their chosen path (Model D). At the same time we have to state that it is as it is, a HTTP-Server in the middle like in Model A is faster than Model D.
In the graph-path the Echo-Server in the middle handles only encrypted traffic, so it is just like another Relay. We can call it "Reflec-Tor". The only sense it to multiply incomming encrypted packets from one node to all connected nodes.
With that Idea, the Messenger Spot-On could be used as a Tor-Messenger.
This Messenger has stong encryption and is full of feature for messaging and also cryptography.
it is like adding Firefox to Tor-Browsing, when Spot-On is added to Tor-Messaging.
Something to read at the community forum:
https://www.reddit.com/r/Spot_On_Encryption/
Also there is a Mobile Client for Android, which also connects to Reflec-Tors, find "Smoke" Messenger at F-Droid.org.
Please, get this right, it is not about a technical view on slow and failing chat-packets to hidden servers, and it is not about those start-up clients using this inside technology, some do a good project. It is about the idea, that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this hop within the path of tor is not outside, it is always fully encryted for the messaging packets and should be seen as one Tor-Path, especially if the Listener-Ping-Back function (the Echo capabilities) is build in the Exit-Node-Tor Software.
Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only encrypted packets.
*A test is easy to make:*
(1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is running.
Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On can start.
(2) Start Spot-On on a webserver and create in the Listeners Tab a Listener on Port 4710.
(3) Start two Spot-On Instances Alice and Bob on two Laptops, in the Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to the neighbor and choose Proxy: 127.0.0.1 Port 4710.
You get the the Path:
Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob
The idea is now to integrate this a bit more:
Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob
You see, the way stays all within the Tor-Family.
For sure, in case Alice does not want to use Tor, she also can message to Bob, who is behind Tor.
Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob
The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. Then two user can simply cata over that node.
We need in times of surveillance, data retention, chat control and for sake of the needs of whistleblowser and people who want to chat privat and anonymously more decentral and open source chat server.
*The mission is: Every Tor-Exit Node is an Entry-Node for Chat.*
It should be not a lot of code to be added to the ports of an Exit-Node and displaying the Port of the Exit-Node in the Tor-Browser path icon.
This makes sense in several effects to be discussed and developed further:
-
Taking the next Development Step for Tor-Messaging: BTW, A Forum about Tor-Messaging could be made as a category here in the forum please. -
directly support Tor-based Messaging for the Spot-On Messaging client
To be developed and discussed is, if this infra-structure could help to
-
support bootstrapping of Tor -
support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over the Messenger with EPKS -
Accept, that some routing to an HTTPS internet server at the Tor-Node is faster than to an hidden onion server at the Tor Node.
Well, to add some "ping-in-and-out" for an packet is what every netcat and socat under linux can do. It is a small development step to make each Tor-Exit node a free chat server for messaging, which is a big step for mankind to have a network of free messaging chat servers.
Lets also see, how users and community will test and develop this messaging. So it is not only a discussion for developers, it is also a step forward the needs of the communities *for a free internet:*
-
*for chat and their discussions.*
A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor can start really decentral and open source and free.
*What do you think?* does this privacy-concept bring more privacy and reliability in packet delivery to messaging with Tor?
Regards
Hello,
I am a bridge relay operator. As a bridge operator, I run my bridge to allow people in countries who experience government censorship to access the real uncensored Internet. I would not be willing to add a service to my server that could compromise my users' anonymity.
I don't understand the necessity for an echo-server. What would an echo-server do that current Internet servers are currently not doing?
You mention the ability to PING. Maybe I am not understanding your intentions for this pinging, but if it is to ping a Tor user, I think this would be a very bad idea. This could allow someone (AKA evil government spy) to know when someone is using Tor or the chat service. This might also be used to identify the computer that the Tor user is using by sending sequences of pings to that user; if the adversary is also able to monitor their network traffic, then the pinged Tor user could possibly be identified.
I kind of think that you are trying to reinvent the wheel here. You want the echo-server to be a chat server on the open Internet that is accessed through the Tor network?
We already have a tried and trusted chat server network on the open Internet called Internet Relay Chat (IRC) that has been used for decades as a public chat service. IRC is very anonymous when accessed through Tor. https://en.wikipedia.org/wiki/IRC
There are IRC servers that I have used that do accept incoming chat connections from the Tor network and they do anonymize the incoming connection which hides the fact that you are accessing the server via Tor. There are even IRC servers that operate as a hidden Tor service.
I use KVirc IRC client software: https://www.kvirc.net/
For example connecting to OFTC IRC server with KVirc client:
Attempting secure connection to irc.oftc.net (OFTC) on port 6697 Attempting to 'bounce' on proxy pi on port 9050 (protocol SOCKSv5)
This routes all IRC traffic through the Tor network and the IRC server is configured to accept connections from the Tor network.
For chat servers that cache messages, there are servers such as matrix.org that can be accessed via Tor.
Pretty much any chat server software can be configured as a hidden Tor service. So, I don't understand what your new chat software would do that doesn't already exist.
I also don't like the idea of using exit servers as entrances to Tor. Exit servers are more rare as compared to other Tor servers except maybe bridges. It is easy to operate an entry node or middle relay node. Exit nodes involve more risk to the node operator.
Landon
On Wed, Jul 17, 2024 at 7:30 AM Sam alleestrasse100@gmail.com wrote:
Hello, as tb discussed further with developers of Tor, the concept of "Reflec-Tor"s (and Exit-Nodes to be seen also as an Entry-Node) might have an impact like Snowflakes for Chat and Messaging over Tor and addresses opinions of Relay admins and university research too. Regards
---------- Forwarded message --------- Date: Di., 16. Juli 2024 um 20:36 Uhr Subject: Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes To: tor-dev@lists.torproject.org
System wrote via Tor Project noreply@forum.torproject.org:Feedback: Please submit the proposal also to tor-dev: tor-dev Info PageIntroducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflect...
==============================================================Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
*Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay |*
Hello,
I think this belongs to this core, general, relay topic-forum, as it is also a development & community issue, request and efford, I post it here into the reddit forum for your core discussion:
The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are developed futher to be also an Entry-Node.
Some may remember when gnutella got hybrid with edonkey and then also with torrent, Mike Stokes from Shareaza did that.
The idea today, 20 years later, is to add some Echo-capabilities to Tor in regard of the servers for Exit and Entry.
*Vision: Every (updated) Exit-Node is an Echo-Server - For a better Tor-Messaging.*
What does that mean?
An Echo-Server is a server for chat-messaging to send an incomming message packet again out to all connected clients at the moment. Ping-in and Ping-Out to all. That simple, that's why it is called the Echo. Like a shout in front of a forrest, all connected users can hear and get the (encrypted) shout or message or packet back from the tree wall.
There are 3 software applications for Echo-Servers:
https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener Tab)
https://github.com/textbrowser/smokestack (java for Android)
https://github.com/textbrowser/spot-on-lite (headless deamon for Linux)
Now, the Listener function with ping in and ping out should be implemented within a Tor-Exit-Node.
When it comes to Tor-Messaging, there are some pathes possible:
A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets)
B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob (Echo Tor-tunneled)
C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct connection to Echo-Server with only encypted packets)
The request here is to build and develop option A.
That is just right now also possible, by an Exit-Node of Tor running the Echo-Server-Software on the same machine in parallel. Just the port is different.
This is an idea for some might be new, but thinking Tor Messaging a bit, it comes quickly to this ideas and better soluttion.
The way to connect
D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion Server v3 - Tor-Chat-Client-Bob
is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch.
Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Don't quote me on that, but as core developers and community members you might be in contact with those who experience this.
Furthermore the Messaging clients are not advanced in functionality, nor advanced in strong encryption.
It would be third a long development way to got that route.
It is cost effective and needs cappable developers.
Some project have stamped on and made a workable client, but does that unite all our power in the sense of Tor-Messaging?
Messaging needs a Vision and Statement from the Tor-Core-Developer team with a discussion in the community in that regard with honor to the individual projects and also with support for their chosen path (Model D). At the same time we have to state that it is as it is, a HTTP-Server in the middle like in Model A is faster than Model D.
In the graph-path the Echo-Server in the middle handles only encrypted traffic, so it is just like another Relay. We can call it "Reflec-Tor". The only sense it to multiply incomming encrypted packets from one node to all connected nodes.
With that Idea, the Messenger Spot-On could be used as a Tor-Messenger.
This Messenger has stong encryption and is full of feature for messaging and also cryptography.
it is like adding Firefox to Tor-Browsing, when Spot-On is added to Tor-Messaging.
Something to read at the community forum:
https://www.reddit.com/r/Spot_On_Encryption/
Also there is a Mobile Client for Android, which also connects to Reflec-Tors, find "Smoke" Messenger at F-Droid.org.
Please, get this right, it is not about a technical view on slow and failing chat-packets to hidden servers, and it is not about those start-up clients using this inside technology, some do a good project. It is about the idea, that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this hop within the path of tor is not outside, it is always fully encryted for the messaging packets and should be seen as one Tor-Path, especially if the Listener-Ping-Back function (the Echo capabilities) is build in the Exit-Node-Tor Software.
Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only encrypted packets.
*A test is easy to make:*
(1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is running.
Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On can start.
(2) Start Spot-On on a webserver and create in the Listeners Tab a Listener on Port 4710.
(3) Start two Spot-On Instances Alice and Bob on two Laptops, in the Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to the neighbor and choose Proxy: 127.0.0.1 Port 4710.
You get the the Path:
Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob
The idea is now to integrate this a bit more:
Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob
You see, the way stays all within the Tor-Family.
For sure, in case Alice does not want to use Tor, she also can message to Bob, who is behind Tor.
Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob
The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. Then two user can simply cata over that node.
We need in times of surveillance, data retention, chat control and for sake of the needs of whistleblowser and people who want to chat privat and anonymously more decentral and open source chat server.
*The mission is: Every Tor-Exit Node is an Entry-Node for Chat.*
It should be not a lot of code to be added to the ports of an Exit-Node and displaying the Port of the Exit-Node in the Tor-Browser path icon.
This makes sense in several effects to be discussed and developed further:
Taking the next Development Step for Tor-Messaging: BTW, A Forum about Tor-Messaging could be made as a category here in the forum please.
directly support Tor-based Messaging for the Spot-On Messaging client
To be developed and discussed is, if this infra-structure could help to
support bootstrapping of Tor
support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over the Messenger with EPKS
Accept, that some routing to an HTTPS internet server at the Tor-Node is faster than to an hidden onion server at the Tor Node.
Well, to add some "ping-in-and-out" for an packet is what every netcat and socat under linux can do. It is a small development step to make each Tor-Exit node a free chat server for messaging, which is a big step for mankind to have a network of free messaging chat servers.
Lets also see, how users and community will test and develop this messaging. So it is not only a discussion for developers, it is also a step forward the needs of the communities *for a free internet:*
*for chat and their discussions.*
A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor can start really decentral and open source and free.
*What do you think?* does this privacy-concept bring more privacy and reliability in packet delivery to messaging with Tor?
Regards _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thanks, Landon, so you agree that a Tor-ChatServer-Tor path is needed (which is the ReflecTor-Concept), rather than a hiddenserver-to-hiddenserver Tor-Messaging, as there 35-45 % of the messages are not working out and are lost. That is not acceptable and no model for the future.
Reflect.Tors have the aim to add strong encryption, means security, to anonymity, means proxification. (With ping-in and ping-out an encrypted hop or mirroring of packets was meant, not the classical ping.)
The Echo of a ReflecTor provides also proxification (like Tor is doing, so they are familiar) and adds real end-to-end encryption - and not hop-wise.
Sure you can add IRC or Matrix Servers in the middle, but this is a security risk, as they accept plaintext and must be administered. ReflecTors need no administration for the chat nor do they handle plaintext. This is why they could be regarded as just another hop in the secure tor-circuit.
Exit-Nodes are already Entry-Nodes as the Internet-Webserver sends the data to the Exit-Node as well - where it finds its Entry.
For the Tor-Messaging over ReflecTors the path is: Hiddenclient-Tor-ReflecTor-Tor-Hiddenclient, So this is very secure and very anonymous.
[for sure there could be the rare case that one participant does not (want to) hide behind Tor and addresses directly to the Exit-Node as ReflecTor (while the receiver of the message is still behind Tor), then we have the same situation as for surfing, where the webserver sends the data to the Exit-Node as Entry-Node. Exit-Nodes are already Entry-Nodes. But this does not matter, as the Sender could be proxified also behind federated ReflecTors and then is also proxyfied]
The system/architecture offers with the conditons - no admin needs to look at the chat-server "ReflecTor" - the chat-server ReflecTor is handling only encrypted packets
the following benefits: - strong encryption of the chatters - bringing end-to-end encryption to the chatters - offline messaing - group messaging - and overall, reliability and no latency in chat packet transfer, which is not given in the current architecture. - less coding within three current Tor-Messaging projects like Rico, Cwtch & Quiet adding own servers for these goals by using the existing code for the serverpart, rather than developing the client and serverpart new (and also going away from the holy hiddenserver-to-hiddenserver approach, which is not workable).
Some code for an Echo-Listener and how this Listener accepts a connected neighbor could be looked up here in these three Echo-Servers, which could lend code for a ReflectTor integration in Exit-Nodes:
SIMPLE LITE-LISTENER (C++) as Deamon: https://github.com/textbrowser/spot-on-lite/blob/master/Source/spot-on-lite-...
JAVA-LISTENER & NEIGHBOR (Java) for Android: https://github.com/textbrowser/smokestack/blob/master/SmokeStack/app/src/mai... https://github.com/textbrowser/smokestack/blob/master/SmokeStack/app/src/mai...
APPLICATION LISTENER & NEIGHBOR (C++) full features: https://github.com/textbrowser/spot-on/blob/master/branches/trunk/Kernel/spo... https://github.com/textbrowser/spot-on/blob/master/branches/trunk/Kernel/spo...
However, looking more into the future, it will come to the creation that friends on the Tor-Messaging-Friendslist might want to send you Tor-bootstrap-nodes and also Tor-bridges-Nodes to circumvent censorship.
Boldsuck already wrote here on August 2, that " "services" are added to hidden servers" (in general). Brings up the question: Could a bootstrap or snowflake server be loaded via a hidden server? No. It is like in gnutellium or bearshare, if you run out of bootstrappers, you are done.
It is like saying, oh, my car has no battery anymore and I need to find a gasoline station by asking the cars cockpit. You will discover all dead. It works only, if hybrid, friends, allies help with a second but integrated system: E.g. ask your navigator in your smartphone, where the next gasoline station is. And make your machine equipped with a new battery and gasoline powering it, if not pure battery driven.
That is the way, why ReflecTors and other servers of the Echo can provide Tor-Chatters bootstrappers and Relays and Snow-Smacks over the Tor-Messenger, which could fix Tor again, even if all Tor-Nodes have run out or are not working because of indexing all known nodes.
In an even more far away future P2P and F2F loading of Websites might be in parity, cf. the old Psiphone version or the Websurfing over an echoing Tor-Messenger and its friends.
Already now Google is blocking the requests by many Tor-Exit-Nodes. All Exit-nodes IP-Adresses are indexed in the meantime. If this mailing-list has 250 active people and 100 relay admins comming from ISP-background, there might be 300-500 Exit-Nodes. They are easily to index.
ReflecTors in combination of Tor-Messaging cover many aspects of these processes and are healing Tor, providing perspectives and need to be welcomed in the bubble, which is mostly done by understanding, cappable and innovative developers with a view more on the architecture and environment rather than the own place to build.
An idea could be to really test in practice - as all is there to install and to test out - the speed of incomming messages with ReflecTors in comparison of the Hidden-to-Hidden versions.
Kind regards Sam
Am Sa., 3. Aug. 2024 um 17:18 Uhr schrieb Landon reply@mynetblog.com:
Hello,
I am a bridge relay operator.
I also don't like the idea of using exit servers as entrances to Tor.
But you do realize that Tor exits also receive the Guard flag, and Guard probability assigned?
Check my server:
https://metrics.torproject.org/rs.html#details/0F8538398C61ECBE83F595E3716F7...
It mostly acts as an exit, but also has hidden services and users on it.
Kindly, George On Saturday, August 3rd, 2024 at 5:19 PM, Landon reply@mynetblog.com wrote:
Hello,
I am a bridge relay operator. As a bridge operator, I run my bridge to allow people in countries who experience government censorship to access the real uncensored Internet. I would not be willing to add a service to my server that could compromise my users' anonymity.
I don't understand the necessity for an echo-server. What would an echo-server do that current Internet servers are currently not doing?
You mention the ability to PING. Maybe I am not understanding your intentions for this pinging, but if it is to ping a Tor user, I think this would be a very bad idea. This could allow someone (AKA evil government spy) to know when someone is using Tor or the chat service. This might also be used to identify the computer that the Tor user is using by sending sequences of pings to that user; if the adversary is also able to monitor their network traffic, then the pinged Tor user could possibly be identified.
I kind of think that you are trying to reinvent the wheel here. You want the echo-server to be a chat server on the open Internet that is accessed through the Tor network?
We already have a tried and trusted chat server network on the open Internet called Internet Relay Chat (IRC) that has been used for decades as a public chat service. IRC is very anonymous when accessed through Tor. https://en.wikipedia.org/wiki/IRC
There are IRC servers that I have used that do accept incoming chat connections from the Tor network and they do anonymize the incoming connection which hides the fact that you are accessing the server via Tor. There are even IRC servers that operate as a hidden Tor service.
I use KVirc IRC client software: https://www.kvirc.net/
For example connecting to OFTC IRC server with KVirc client:
Attempting secure connection to irc.oftc.net (OFTC) on port 6697 Attempting to 'bounce' on proxy pi on port 9050 (protocol SOCKSv5)
This routes all IRC traffic through the Tor network and the IRC server is configured to accept connections from the Tor network.
For chat servers that cache messages, there are servers such as matrix.org that can be accessed via Tor.
Pretty much any chat server software can be configured as a hidden Tor service. So, I don't understand what your new chat software would do that doesn't already exist.
I also don't like the idea of using exit servers as entrances to Tor. Exit servers are more rare as compared to other Tor servers except maybe bridges. It is easy to operate an entry node or middle relay node. Exit nodes involve more risk to the node operator.
Landon
On Wed, Jul 17, 2024 at 7:30 AM Sam alleestrasse100@gmail.com wrote:
Hello,as tb discussed further with developers of Tor, the concept of "Reflec-Tor"s (and Exit-Nodes to be seen also as an Entry-Node) might have an impact like Snowflakes for Chat and Messaging over Tor and addresses opinions of Relay admins and university research too. Regards
---------- Forwarded message --------- Date: Di., 16. Juli 2024 um 20:36 Uhr Subject: Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes To: tor-dev@lists.torproject.org
System wrote via Tor Project noreply@forum.torproject.org:
Feedback: Please submit the proposal also to tor-dev: tor-dev Info Page
Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
=============================================================================================================================================
https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflect...
============================================================================================
========================
==============================================================
Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes
Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay |
Hello,
I think this belongs to this core, general, relay topic-forum, as it is also a development & community issue, request and efford, I post it here into the reddit forum for your core discussion:
The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are developed futher to be also an Entry-Node.
Some may remember when gnutella got hybrid with edonkey and then also with torrent, Mike Stokes from Shareaza did that.
The idea today, 20 years later, is to add some Echo-capabilities to Tor in regard of the servers for Exit and Entry.
Vision: Every (updated) Exit-Node is an Echo-Server - For a better Tor-Messaging.
What does that mean?
An Echo-Server is a server for chat-messaging to send an incomming message packet again out to all connected clients at the moment. Ping-in and Ping-Out to all. That simple, that's why it is called the Echo. Like a shout in front of a forrest, all connected users can hear and get the (encrypted) shout or message or packet back from the tree wall.
There are 3 software applications for Echo-Servers:
- https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener Tab)
- https://github.com/textbrowser/smokestack (java for Android)
- https://github.com/textbrowser/spot-on-lite (headless deamon for Linux)
Now, the Listener function with ping in and ping out should be implemented within a Tor-Exit-Node.
When it comes to Tor-Messaging, there are some pathes possible:
`A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets)`
`B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob (Echo Tor-tunneled)`
`C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct connection to Echo-Server with only encypted packets)`
The request here is to build and develop option A.
That is just right now also possible, by an Exit-Node of Tor running the Echo-Server-Software on the same machine in parallel. Just the port is different.
This is an idea for some might be new, but thinking Tor Messaging a bit, it comes quickly to this ideas and better soluttion.
The way to connect
`D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion Server v3 - Tor-Chat-Client-Bob`
is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch.
Similar to Briar, even developers of such clients above tell the loss of messages and low reliability of the hidden to hidden path. Some of you might know, that there were use cases with missing messages in a range of 35-45 %. Don't quote me on that, but as core developers and community members you might be in contact with those who experience this.
Furthermore the Messaging clients are not advanced in functionality, nor advanced in strong encryption.
It would be third a long development way to got that route.
It is cost effective and needs cappable developers.
Some project have stamped on and made a workable client, but does that unite all our power in the sense of Tor-Messaging?
Messaging needs a Vision and Statement from the Tor-Core-Developer team with a discussion in the community in that regard with honor to the individual projects and also with support for their chosen path (Model D). At the same time we have to state that it is as it is, a HTTP-Server in the middle like in Model A is faster than Model D.
In the graph-path the Echo-Server in the middle handles only encrypted traffic, so it is just like another Relay. We can call it "Reflec-Tor". The only sense it to multiply incomming encrypted packets from one node to all connected nodes.
With that Idea, the Messenger Spot-On could be used as a Tor-Messenger.
This Messenger has stong encryption and is full of feature for messaging and also cryptography.
it is like adding Firefox to Tor-Browsing, when Spot-On is added to Tor-Messaging.
Something to read at the community forum:
Also there is a Mobile Client for Android, which also connects to Reflec-Tors, find "Smoke" Messenger at F-Droid.org.
Please, get this right, it is not about a technical view on slow and failing chat-packets to hidden servers, and it is not about those start-up clients using this inside technology, some do a good project. It is about the idea, that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this hop within the path of tor is not outside, it is always fully encryted for the messaging packets and should be seen as one Tor-Path, especially if the Listener-Ping-Back function (the Echo capabilities) is build in the Exit-Node-Tor Software.
Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only encrypted packets.
A test is easy to make:
`(1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is running.`
`Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On can start.`
`(2) Start Spot-On on a webserver and create in the Listeners Tab a Listener on Port 4710.`
`(3) Start two Spot-On Instances Alice and Bob on two Laptops, in the Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to the neighbor and choose Proxy:` 127.0.0.1 `Port 4710.`
You get the the Path:
`Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - Tor-Chat-Client-Bob`
The idea is now to integrate this a bit more:
`Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob`
You see, the way stays all within the Tor-Family.
For sure, in case Alice does not want to use Tor, she also can message to Bob, who is behind Tor.
`Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob`
The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. Then two user can simply cata over that node.
We need in times of surveillance, data retention, chat control and for sake of the needs of whistleblowser and people who want to chat privat and anonymously more decentral and open source chat server.
The mission is: Every Tor-Exit Node is an Entry-Node for Chat.
It should be not a lot of code to be added to the ports of an Exit-Node and displaying the Port of the Exit-Node in the Tor-Browser path icon.
This makes sense in several effects to be discussed and developed further:
- Taking the next Development Step for Tor-Messaging: BTW, A Forum about Tor-Messaging could be made as a category here in the forum please.
- directly support Tor-based Messaging for the Spot-On Messaging client
To be developed and discussed is, if this infra-structure could help to
- support bootstrapping of Tor
- support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over the Messenger with EPKS
- Accept, that some routing to an HTTPS internet server at the Tor-Node is faster than to an hidden onion server at the Tor Node.
Well, to add some "ping-in-and-out" for an packet is what every netcat and socat under linux can do. It is a small development step to make each Tor-Exit node a free chat server for messaging, which is a big step for mankind to have a network of free messaging chat servers.
Lets also see, how users and community will test and develop this messaging. So it is not only a discussion for developers, it is also a step forward the needs of the communities for a free internet:
- for chat and their discussions.
A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor can start really decentral and open source and free.
What do you think? does this privacy-concept bring more privacy and reliability in packet delivery to messaging with Tor?
Regards
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
George Hartley -
Landon -
Sam