You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stealth is now pretty failsafe to come around NAT environments that block IPs and/or ports via delegating traffic to networked Peers. In future (after the MDNS implementation) this will also be fully autonomous, as Peers can be locally discovered via the DNS-based service discovery resolutions of the _stealth_wss.tholian.local entries.
Now to take this further in regards to more aggressively getting an internet connection, it might make sense to implement these network protocols in future - in order to allow stealthy transport layers that can be used additionally to TOR, I2P and/or Peers via SOCKS relayed connections.
As SOCKS is pretty easily identifiable and also has the problem that it's a TCP-RST packet blockable connection, it might make sense to use dgram-based or other network management protocols that cannot be blocked.
The current ideas for protocol implementations are:
SOCKS Connection should include the newer protocols (dnss, mdns).
This will allow to relay UDP DNS traffic in a more reliable manner and allow to do NAT discovery or edge-detection of the network via relaying multicast network traffic across discovered Peers.
It might make sense to extend the SOCKS protocol for this with respect to the UDP section of RFC1928, but as of now it doesn't have many benefits. The DNS over TLS requests can be relayed already, which are TCP, so it's just for the sake of completeness.
HTTPSviaDNS Connection that uses TXT entries to encapsulate network traffic.
HTTPSviaMDNS Connection that uses multicast DNS to have an "ensured" backup on other Peers (e.g. when disconnecting or relaying downloads).
HTTPSviaWS Connection that uses a Peer as a Proxy service, but via WS protocol.
HTTPSviaSNMP Connection that uses PWNAT-based crafted frames to abuse network hopping capabilities to relay traffic to other Peers and/or Servers.
The text was updated successfully, but these errors were encountered:
Stealth is now pretty failsafe to come around NAT environments that block IPs and/or ports via delegating traffic to networked Peers. In future (after the MDNS implementation) this will also be fully autonomous, as Peers can be locally discovered via the DNS-based service discovery resolutions of the
_stealth_wss.tholian.local
entries.Now to take this further in regards to more aggressively getting an internet connection, it might make sense to implement these network protocols in future - in order to allow stealthy transport layers that can be used additionally to TOR, I2P and/or Peers via SOCKS relayed connections.
As SOCKS is pretty easily identifiable and also has the problem that it's a TCP-RST packet blockable connection, it might make sense to use dgram-based or other network management protocols that cannot be blocked.
The current ideas for protocol implementations are:
This will allow to relay UDP DNS traffic in a more reliable manner and allow to do NAT discovery or edge-detection of the network via relaying multicast network traffic across discovered Peers.
It might make sense to extend the SOCKS protocol for this with respect to the UDP section of RFC1928, but as of now it doesn't have many benefits. The DNS over TLS requests can be relayed already, which are TCP, so it's just for the sake of completeness.
HTTPSviaDNS Connection that uses TXT entries to encapsulate network traffic.
HTTPSviaMDNS Connection that uses multicast DNS to have an "ensured" backup on other Peers (e.g. when disconnecting or relaying downloads).
HTTPSviaWS Connection that uses a Peer as a Proxy service, but via WS protocol.
HTTPSviaSNMP Connection that uses PWNAT-based crafted frames to abuse network hopping capabilities to relay traffic to other Peers and/or Servers.
The text was updated successfully, but these errors were encountered: