qs-lite is a alternative lightweight implementation of qs-netcat utility with Rust language. It allows redirecting true PTY sessions with reverse connections over the QSRN, effectively accessing systems under NAT networks or firewalls.
Warning
This tool is in its early alpha development stage, featuring experimental functionality that may lack backwards compatibility, and users are advised to exercise caution and not use it in production environments.
Tool | Build From Source | Docker Image | Binary Release |
---|---|---|---|
qs-lite | cargo install qs-lite |
Download | Download |
qs-lite currently supports 3 architectures and 4 operating systems, check Supported Platforms below for detailed table.
Supported Platforms
Platform | AMD64 | 386 | ARM | ARM64 | MIPS | MIPS64 | MIPS64LE | PPC64 | PPC64LE | S390X |
---|---|---|---|---|---|---|---|---|---|---|
Linux | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Darwin | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Windows | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
OpenBSD | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
NetBSD | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
FreeBSD | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Android | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
IOS | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Solaris | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Illumos | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Dragonfly | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
AIX | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Usage: qs-lite [OPTIONS]
Options:
-s, --secret <SECRET>
secret. (e.g. password) [default: ]
-e, --exec <EXEC>
program to execute [default: "bash -il"]
-f, --forward-addr <FORWARD_ADDR>
forward address (IP:PORT) for traffic forwarding [default: ]
-x, --proxy-addr <PROXY_ADDR>
user socks proxy address for connecting QSRN [default: ]
-X, --cert-fingerprint <CERT_FINGERPRINT>
hex encoded TLS certificate fingerprint for validation [default: ]
-n, --probe <PROBE>
probe interval for connecting QSRN [default: 5]
-C, --no-encryption
disable all (TLS+E2E) encryption
--no-e2e
disable End-to-End encryption
-i, --interactive
initiate a full PTY (interactive) shell
-l, --listen
server mode. (listen for connections)
-g, --generate
generate a random secret
-T, --use-tor
use TOR network for connecting QSRN
--qr
generate a QR code with given stdin and print on the terminal
-q, --quiet
quiet mode. (no stdout)
-v, --verbose
verbose output mode
-h, --help
Print help
-V, --version
Print version
- Log in to Workstation A from Workstation B through any firewall/NAT
$ qs-lite -l -i # Workstation A
$ qs-lite -i # Workstation B
Crypto / Security Mumble Jumble
- The connections are end-2-end encrypted. 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 QSocket uses SRP with SPAKE2 and ChaCha20 for ensuring perfect forward secrecy. This means that the session keys a re always different, and recorded session traffic cannot be decrypted by the third parties even if the user secret is known.
- 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).
- A brute force attack against weak secrets requires a new TCP connection for every guess. But QSRN contains a strong load balancer which is limiting the consecutive connection attempts.
- Do not use stupid passwords like 'password123'. Malice might pick the same (stupid) password by chance and connect. If in doubt use qs-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.
- Assume Alice shares the same password with Bob and Malice. When Alice stops listening for a connection then Malice could start to listen for the connection instead. Bob (when opening a new connection) can not tell if he is connecting to Alice or to Malice.
- We did not invent SRP. It's a well-known protocol, and it is well-analyzed and trusted by the community.