gsocket replaces IP addresses and ports with a shared secret and a relay network

The addressing model is the idea: a secret instead of an address

The Global Socket Toolkit allows two users behind NAT or a firewall to establish a TCP connection with each other, securely. The way it does that is the interesting part, and the README states it as a principle: abandon the thought of IP addresses and port numbers, and instead think that two programs should be able to communicate with each other as long as they know the same secret, rather than each other's IP address and port number.

The library facilitates that. It locally derives temporary session keys and IDs and connects two programs through the Global Socket Relay Network, the GSRN, regardless of and independent of the local IP address or geographical location. Once connected, the library negotiates a secure TLS connection end to end. The secret never leaves the workstation, and the GSRN sees only the encrypted traffic.

That is a genuinely different model from port forwarding, from a VPN, or from a hosted tunnel service. The user-facing artefact is a passphrase, and the two ends find each other through the relay, which is a free cloud service that the README says is free to use by anyone.

The mechanism is what makes it usable in the case that motivates it. Neither machine needs an inbound port, a static address or a public hostname. That is the situation every developer hits when they want to reach a laptop behind a corporate NAT, and the usual answers are a VPN, a tunnel service with an account, or asking the network team for a port forward.

The crypto is SRP, a 4096-bit prime and forward secrecy

The feature list names the security properties, and they are specific enough to check against a threat model.

End-to-end encryption uses OpenSSL's SRP, the Secure Remote Password protocol, with RFC 5054. SRP is what makes the shared secret work as the authentication factor: the client proves knowledge of the password to the server without sending it, and the exchange is mutually authenticated, so a man in the middle cannot substitute their own session. That is precisely the property a secret-keyed tunnel needs, since there is no PKI to check a certificate against.

The README lists AES-256 and key exchange using a 4096-bit prime, no PKI required, and Perfect Forward Secrecy. The last of those means that recording the encrypted session does not let an attacker recover the traffic later, because the session keys are derived fresh and the long-term secret is not what decrypts the traffic.

The 4096-bit prime is a group parameter for the Diffie-Hellman style exchange, and it is on the large side for a tool of this kind, which is a reasonable default given that the exchange happens once per session.

TOR support is listed as optional. The point of the TOR option is that it changes the path to the relay, so a local network observer does not see which relay endpoint the traffic is heading for.

Five tools ship in the box, and each one is a different tunnel

The toolkit is a set of tools, and the set covers the common cases where two machines need to reach each other.

gsocket makes an existing program behind a firewall or NAT accessible from anywhere in the world. It does so by analyzing the program and replacing the IP layer with its own Gsocket layer, and a client connection to a hostname ending in .gsocket is then automatically redirected, via the GSRN, to that program. This is the piece that lets the library be dropped in front of an existing daemon rather than requiring the daemon to be modified.

gs-netcat is described as netcat on steroids. It can be turned into an AES-256 encrypted reverse shell via TOR, optional, with a true PTY and interactive command shell, with the invocation gs-netcat -s MySecret -i. It also does integrated file transfer, can spawn a Socks4, 4a or 5 proxy, can forward TCP connections, and can give somebody temporary shell access.

gs-sftp is an sftp server and client between two firewalled workstations, used as gs-sftp -s MySecret. gs-mount accesses and mounts a remote file system, as gs-mount -s MySecret ~/mnt/warez. blitz copies data from workstation to workstation, as blitz -s MySecret /usr/share/*.

The common pattern across all of them is the -s flag carrying the secret. Every tool derives the same way of finding the peer, so the difference between them is what the payload is: a shell, an SFTP session, a mounted filesystem, a file copy, or a forwarded port.

A forward and an SSH replacement are two more examples of the same tunnel

The usage examples in the README show the mechanism applied to ordinary tasks, and they are the clearest way to see what the library replaces.

The simplest case is an interactive session between two workstations. On workstation A you run gs-netcat -l -i, and on workstation B you run gs-netcat -i, and you are logged in to A from B through any firewall or NAT.

The second case is a TCP forward, which is a small program on each side:

$ gs-netcat -l -d 127.0.0.1 -p 22  # Workstation A
$ gs-netcat -p 2222                # Workstation B
# A connection on B's port 2222 will end up on A's port 22
$ nc -vn 127.0.0.1 2222

The third case is the one that will matter most to a sysadmin, SSH from workstation B to workstation A through any firewall or NAT:

$ gsocket /usr/sbin/sshd     # Workstation A
$ gsocket ssh r

The gsocket wrapper starts your existing sshd under the Gsocket layer, so the SSH protocol, the host keys and the authentication all stay exactly as they were. Only the address resolution changes. That is a materially different design from a tool that reimplements SSH, and it means an existing ssh_config, existing certificates and existing key management keep working.

The examples directory in the repository holds these as separate programs, and the README lists OpenSSH via GSRN, WireGuard via GSRN, a root shell via GSRN through systemd, and an IRCd via GSRN under port forwarding. The WireGuard example is the most interesting for a networking engineer, because it means a full VPN can be tunnelled without touching the tunnel's own configuration format.

Binaries, packages and Docker cover most platforms, Windows partly

Distribution is the part of the README with the most detail, and it tells you where the tool will and will not run smoothly.

Static pre-compiled binaries are published for AMD64, ARM64, MIPS and more, and a source tarball is available for Linux, MacOS, FreeBSD, OpenBSD and Solaris. Debian packages are provided for x86_64 and aarch64, with more architectures listed.

Windows is the exception, and the README is precise about it: gs-netcat only, or use Docker or Cygwin. That is a real limitation rather than an oversight, since the project originates in the Linux world and the tooling is built around POSIX sockets and process control.

Docker is a first-class path, with two images referenced:

docker run --rm -it hackerschoice/gsocket
docker run --rm -it hackerschoice/gsocket-tor # gs via TOR

The TOR variant is the interesting one for a containerised deployment, because it gives the relay path the same privacy property the native TOR support provides.

For packaging from source, the repository layout is a GNU autotools project rather than a modern one: configure.ac, Makefile.am, a bootstrap script and an install.sh, plus a deploy/ directory whose README holds the per-operating-system installation instructions the README links to. There are also man pages published for gsocket(1), gs-netcat(1), gs-mount(1), gs-sftp(1) and blitz(1).

The relay is a third party, and that is the boundary

Everything above depends on a service the project does not run: the GSRN, described as a free cloud service and free to use by anyone. The security argument holds because the relay only sees encrypted traffic and the secret never leaves the workstation, but the availability argument does not, because the relay is in the path of every connection.

That is the wrong-tool case. If your environment forbids outbound traffic to an unknown third party, or if the connection must work when that third party is down, gsocket is the wrong answer. In that setting the alternatives are a mesh VPN where you operate the rendezvous yourself, an SSH reverse or local forward to a host you control, or a hole-punching library that establishes a direct path with a third party only for the handshake.

The distinction between gsocket and the direct hole-punching approach is worth being explicit about. A hole-punching library negotiates a direct peer-to-peer path and the traffic never leaves your two machines, which is a stronger privacy property and a weaker reliability property, because NAT types that block punching will defeat it. gsocket trades that for reliability by routing through a relay, and the encryption keeps the relay from learning anything.

The other thing to weigh is the offensive tooling in the box. gs-netcat with a TOR-encrypted reverse shell and temporary shell access is genuinely useful for a red team exercise and genuinely abusable, so a corporate security team will have opinions about it, and the SSH-hijacking video in the README is a reminder that the same primitives are used defensively and offensively. That is a reason to think about where the binaries live, not a reason to avoid the library.

On the project side, the licence is BSD-2-Clause, which is permissive and carries no copyleft obligation. The maintenance picture is more nuanced: the last push was on 2026-10-19, but the most recent tagged release is v1.4.43 from 2024-05-22, so the source tree is receiving work that has not yet produced a new release artefact.

Editorial conclusion

gsocket fits a developer or operations team that needs to reach a host with no inbound connectivity and would rather share a secret than configure port forwarding, and it does not fit an environment that forbids traffic through a third-party relay or that needs the connection to be survivable if that relay is unavailable. Before adopting it, read the threat model on the project site, because the secret is what authenticates the pair and the relay only ever sees encrypted traffic, and check the release gap, since the last tagged release is v1.4.43 from 2024-05-22 while the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. hackerschoice/gsocket on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases