Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stealth: Exfiltration Protocols (aka NAT breaking Protocols) #69

Open
1 of 5 tasks
cookiengineer opened this issue May 21, 2021 · 0 comments
Open
1 of 5 tasks

Stealth: Exfiltration Protocols (aka NAT breaking Protocols) #69

cookiengineer opened this issue May 21, 2021 · 0 comments

Comments

@cookiengineer
Copy link
Member

cookiengineer commented May 21, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant