Global Socket v1.4.16 releases: allows two users behind NAT/Firewall to establish a TCP connection
Global Socket
Moving data from here to there. Securely, Fast, and trough NAT/Firewalls.
Global Socket allows two users behind NAT/Firewall to establish a TCP connection with each other. Securely.
Features:
- Uses the Global Socket Relay Network to connect TCP pipes
- End-2-End encryption using (OpenSSL’s SRP / RFC 5054)
- AES-256 with a 4096 Prime
- No PKI required.
- Perfect Forward Secrecy
- TOR support (optional)
Abandon your thinking that an IP Address is needed to communicate with somebody. Instead, start thinking that two Users should be able to communicate with each other as long as they know the same secret (key/password). The Global Socket Library handles the rest: It locally derives temporary session keys and IDs and finds the other User in the Global Relay Network. Once found the library then negotiates a secure TLS connection (End-2-End) using OpenSSL’s SRP protocol. The Relay Network sees only the encrypted traffic.
The library comes with example tools. Gs-netcat is a re-implementation of netcat. It supports the well-loved -e option and spawns a true PTY/interactive command shell on a remote host. Effectively an AES-256 encrypted reverse backdoor via TOR (optional) and without the need of a Command & Control server. It can also be used to tunnel a friend into your local network or give somebody temporary shell access to your workstation.
Crypto / Security Mumble Jumble
- The security is end-2-end. This means from User-2-User (and not just to the Relay Network). The Relay Network relays only (encrypted) data to and from the Users.
- The session key is 256 bit and ephemeral. It is freshly generated for every session and generated randomly (and is not based on the password).
- The password can be ‘weak’ without weakening the security of the session. A brute force attack against a weak password requires a new TCP connection for every guess.
- Do not use stupid passwords like ‘password123’. Malice might pick the same (stupid) password by chance and connect. If in doubt use gs-netcat -g to generate a strong one. Alice’s and Bob’s password should at least be strong enough so that Malice can not guess it by chance while Alice is waiting for Bob to connect.
- If Alice shares the same password with Bob and Charlie and either one of them connects then Alice can not tell if it is Bob or Charlie who connected.
- If Alice shares the same password with Bob and Malice and Alice stops listening for a connection then Malice could start to listen for the connection instead. Bob (when opening a new connection) could not tell if he is connecting to Alice or to Malice. Use -a <token> if you worry about this. TL;DR: When sharing the same password with a group larger than 2 then it is assumed that everyone in that group plays nicely. Otherwise use SSH over the GS/TLS connection.
- SRP has Perfect Forward Secrecy. This means that past sessions can not be decrypted even if the password becomes known.
- I did not invent SRP. It’s part of OpenSSL :>
Changelog v1.4.16
-
Merge pull request #3 from hackerschoice/Debian
-
blitz and gs-sftp
