search

textbrowser / spot-on

Complexity is beautiful. Anywhere, anyone. AMD, ARM, Alpha, PowerPC, Sparc64, etc. Completed.
https://textbrowser.github.io/spot-on/
Other
72 stars 14 forks source link

Wedding planning: A new tunnel for neighbors. #38

Open alexlenn opened 2 days ago

alexlenn commented 2 days ago

A possible architecture to run Spot-On Messenger e.g. as a WhistleBlower Messenger over Tor has three options:

A) Two Spot-On instances are connected over localhost 127.0.0.1 and the port of the Tor-Tool (e.g. Torbrowser or Ricochet-Refreshed which report in the Tor-Tab “Opened Socks listener connection (ready) on 127.0.0.1:55298” (hence not: control port)) to the Tor-network and then the Spot-On Messenger connects immediately to an IP of a Spot-On / Echo-Server in the Internet. This runs very well. Each Spot-on Messenger is hidden behind Tor and this is ideal in a use case for Wistleblowers wanting to reach a PostBox, which is a Spot-On Key. Just the Internet based Echo-server is exposed to those who want to erase or monitor it, though all is encrypted. The setting has been tested with and without SSL-Listener: Tor-Exit-Points accept SSL-Traffic.

B) An Echo-Server is created within the Tor-Network as hidden service. This requites to run a hidden server and also the clients need to be bound to onion-addresses. As seen in # nineteen Spot-On does not include free servers as hidden service (B). Private and Decentralized Servers in the Internet (A) need to be set up: For WhistleBlowser probably done at Newspaper Portals also providing a communication key.

C) The P2P feature of Spot-On as shown here: https://www.reddit.com/r/Spot_On_Encryption/comments/1dtfy81/p2p_serverless_connections_with_spoton_over_tor/
requires - if run over Tor - to bind the Listener to the same localhost-port for Tor as the outgoing neighbor over Tor. Hence, the Listener is not green. And the neighbor-connection, which is the Tor Exit-Point, is required to be picked up at the webserver for the incoming IP.

If Spot-On does not include free servers, at least an endpoint for a tunnel as protocol could be included:

Another such idea, probably better idea, is to get rid of the Listener and Server architecture and the NAT Port Forward handlings and send all the Echo-Traffic optional over the Ricochet-Channel.

Ricochet does not use a single server as hidden service, instead each participant is a hidden onion V03 service/server itself and has one ID: e.g.:

ricochet:swvacbxrs4a4zs5pmlclhsx7ycpz3j75uobmxxqrva6vq4pc6unfc2yd

As described here: https://github.com/blueprint-freespeech/ricochet-refresh/blob/main/doc/protocol.md https://github.com/blueprint-freespeech/ricochet-refresh/blob/main/doc/design.md

For an implemetation, that does not require changes in the Listener Tab. An Echo Instance of Spot-On gets also a ricochet ID. Which automatically gets active, in case Tor is running over Localhost.

In the Gui just two changes in the Neighbours Tab are required: The copy-keys-button gets another key, which is the Ricochet-ID.

Next to IPv4 / IPv6 another Readiobutton is added: [x] “Tor”. Then only three values can be added:

Be aware, that ricochet is also Speek speek : swvacbxrs4a4zs5pmlclhsx7ycpz3j75uobmxxqrva6vq4pc6unfc2yd https://github.com/Speek-App/Speek

So from the GUi part there are just three minimal changes required:

For the neighbours tunnel function is it under the gui for sure some work, which might be worth and user friendly!

Though some paket loss is known from Birar and also Rico and Speek over Tor, probably a switch to Half Echo could be provided in this case the Tor-Network is not able to deliver all the Echo pakets in a reliable way. That needs to be tested with stable cirquits and depends on the users connection (as the user is the hidden server): https://www.reddit.com/r/TOR/comments/1dho5wl/why_are_tor_hidden_services_impossibly_slow/ https://status.torproject.org/affected/v3-onion-services/

When it comes to a wedding planning, parents often welcome to integrate a choosen and well known son in law:

What about adding such a tunnel-ID for the Echo-packets?

Otherwise (both) users can use the Messenger still behind Tor, but need as shown in A) an Echo-Server in the Internet. That can be made easier, if a Tor-Tunnel from Rico to Rico is used. Sending the Ciphertext just as Chat over a Ricochet connection.

As to be seen, there are not much secure messaging tools over Tor:

- `     Briar: https://github.com/briar/briar
-   Cwtch: https://git.openprivacy.ca/cwtch.im
-       Onionshare with Chat: https://github.com/onionshare/onionshare
-   Quiet: https://github.com/TryQuiet/quiet
-   RicoChet Refreshed: https://github.com/blueprint-freespeech/ricochet-refresh
-   SecP2P: https://github.com/miIiano/SecP2P
-   Speek!: https://github.com/Speek-App/Speek
-   Spot-On Messenger over Tor: https://github.com/textbrowser/spot-on 
-   TorChat: https://github.com/prof7bit/TorChat
-   Tox over Tor: https://wiki.tox.chat/users/tox_over_tor_tot

`

https://www.reddit.com/r/Spot_On_Encryption/

alexlenn commented 3 hours ago

A Tor-Tunnel via "hidden-onion-server-services" v3 like in "Rico Refreshed" brings much benefits to Spot-on users and processes in regard of no need in the first place for Echo-Servers and NAT-Port-Forwarding. Though all the apps report missing messages depending on users and attacks to Tor and slow established routes at the beginning, it would bring more network options to run Full (and not Half) Echo over it, as Echo-Servers and Tor-Tunnels respective Tor-Tunneled-Neighbours could be combined and Tor can then also tunnel the Echo, also to Echo-Servers.

Are friends as neighbor over Tor-Tunnels generating less metadata than Echoed Friends? Probably not, if it is not Half Echo. Hence the Tor Tunnel needs the Full Echo.

From architecture all these below listed apps have the V3 Hidden Service String like Ricochet and report that connections to Websites (means also to Echo-Servers) over Tor are faster than a hidden service to a hidden service.

Means: Echo-Servers within Tor are prooven to be faster than Hidden Servers with service for Chat. (Why not adding the Echo-Server to the Tor network right now and starting the Chat farming? - as hidden servers/services for Chat within Tor are much slower than Echo-Servers for Chat within Tor - or is that a farma?)

Important is to add: When it comes to messaging to offline friends, it is to be assumed, that none of the Tor-Chat-Apps is cappable to do that besides a plugin for Briar, which might still have the old v2 onion service. However, as Spot-on is able to message to offline friends, especially with an Echo-Server reached by a Tor-Exit node, this would be a definately needed feature in the world of Chat over Tor, as given here.

Interesting would be that an to the client added bunch of Spot-keys with one integrated Tor-String adds also one neighbor (Tor-Tunnel-Entry-node) to Spot, probably not indicated over the status bar icon for Echo neighbors. But as the Spot-Key tunneled over Tor would work, the friend is online though as (Tor-proxied) neighbour. So probably indicated also as Neighbor-Connection. Friends turn via Tor tunneling to Neighbors if not also an intermediate Echo-Server is inbetween, respective a Listener online at that node. Clients can be both, Neighbour, or ideally Echo-Server and also friends.

Also the contact request (in the RicoChet Refreshed fork "Speek" it is an own tab, in Ricochet a not to be missed pop-up window) would then appear to Spot-neighbors like accounted Spot-neighbors.

All-Tor-tunneled Tor-Hidden-Neighbors would be inactive as long as no Spot-On localhost-Proxy is bound to Tor. The Spot-on-Function of "Local Private Interfaces" ("Patch Points", sending the app through the Echo) would apply for a Tor-Tunnel (sending the Echo through Tor). Means: Tor-Tunnels are also Echo-Patch-Points, as two Tor-Hidden-Services would tunnel the Echo.

What happens more, if Echo is partly sent over Tor? Probably nothing more as if Echo is sent over Bluetooth and then connecting to an Echo-Server.

Have you tried to Patch-Point Rico to Tor?

R2 [- PP - Echo - PP -] Tor.exe - Tor.exe - R2

Complexity is so beautiful? It is.

If Rico can be run over Tor and also over Echo-Patch-Points, then Rico is not a tunnel, but an Echo-Messenger? If two Rico users - after coding it in - add Magnets for Patch-Points to Rico, is Rico then still an Echo-Messenger or a refreshed one?

And in case a Patch-Point connection includes a Tor tunnel, Ricochet is sending a message over Ricochet!? Multi-Encryption is also beautiful.

Would a Human Proxy behind a Tor-Tunnel loose its function? No.

Here the relevant Messengers over Tor with the same Tor-String and just a different gui and programming.

[ https://github.com/Speek-App/Speek (abandoned fork of RicoChet Refreshed with added Groupchat and functional Android client) https://github.com/prof7bit/TorChat (abandoned) https://wiki.tox.chat/users/tox_over_tor_tot (inactive) https://github.com/briar/briar (old onion v2 service, new desktop client next to android, offline messaging only with plug) ]

in summary: Offline Messaging would be introduced to Tor-Messaging and Spot-On gets easier connection to neighbors right out of the client - without the need to maintaining Ports and IP-Addresses. (by just running the Tor Browser parallel).