The Internet as we know it is in danger and democracy is under attack. Around the world state censors are working to restrict access to information, and prevent people from sharing their own. With growing access to technology, we need to ensure that information remains free at serious infrastructure scale – and we think we can help.

FreeSocks is our flagship VPN service that launched in 2023 with over 60,000 access keys issued to date. FreeSocks has helped tens of thousands of people access the open Internet through our open source control plane (freesocks-control-plane), and vast network of servers around the world. However, as censors began to crack down on the open Internet even more and begin to more effectively block VPN & proxy protocols designed to circumvent Internet censorship, we realized we needed to build FreeSocks from the ground up via a highly flexible system. It’s now time to release it and punch more holes in the closed Internet.

FreeSocks v2 – the next generation

v2 of the freesocks-control-plane (FCP), the system that orchestrates the issuance and management of access keys has evolved into a fully-fledged all-in-one VPN orchestration system. It’s built on Convex, an open-source reactive backend platform, using TypeScript – a complete shift away from our v1 architecture running on serverless platforms using JavaScript. Convex combines a transactional database, server functions, scheduling, and realtime data sync into a single system, which lets FCP v2 handle the entire lifecycle of an access key – issuance, monitoring, rotation, revocation and more – in one place instead of stitching together separate serverless services. Without the power of Convex, we’d spend more time writing migrations, trying to improve caching and general troubleshooting – but Convex just works.

We self-host the Convex backend on our own infrastructure, so no part of FreeSocks depends on a third-party cloud platform anymore. Like v1, the entire control plane is open source under GPL-3.0, and it’s built so that anyone can deploy their own instance and run a FreeSocks-like service themselves. We think this is huge, and genuinely what makes our platform different than others. Whether you’re a single person, or a trusted organization running infrastructure at scale – you could run your own VPN-distribution platform. As time goes on, we plan to continue decoupling static components of the FCP and making them admin-configurable, essentially becoming a content management system (CMS) for VPN services.

New protocols

v1 of FreeSocks only supported Outline (Shadowsocks) proxies. Unfortunately, censors in several countries have gotten much better at detecting and blocking Shadowsocks traffic. FCP v2 supports pluggable proxy backends, and our primary backend is now Xray (managed via Remnawave), which supports multiple modern protocols that are much harder to detect and block. Outline is still supported, and we can run both side-by-side if needed.

Once you have an account, you can choose between two connection modes for your key – one designed to circumvent censorship, and one designed for maximum privacy. You can also pick which server location your key lives on, or let the system automatically place your key on the least busy server. If the censors adapt and start blocking a protocol, we can adapt too, without rebuilding the whole system again.

Client apps

FreeSocks works with any compatible client app, and you’re free to use whichever one you prefer. After you create your key, the site suggests client apps to try for your platform, with notes on how easy each one is to set up and whether it’s open source. In the future, we intend to build our own native FreeSocks VPN app to make setup even easier – stay tuned!

Hardware that we own

FreeSocks v2 is launching fully on hardware that we own, colocated in Kansas City, MO. Over the past couple of years, we’ve been purchasing and colocating our own hardware instead of renting servers from hosting providers, and FreeSocks is now part of that effort. Many popular VPN providers host their infrastructure on rented servers. Owning the hardware means we have full control over the machines that power the service, even the network stack and down to the metal. Going forward, every new FreeSocks location we add will only use hardware that we own.

Anonymous accounts

v1 of FreeSocks had no accounts at all – you received an access key, it expired after a period of time, and you had to request a new one. v2 introduces member accounts, so that your key can be regenerated, moved to a different server, or switched to a different protocol whenever you need. We designed the account system to collect zero personal information. There is no email, no phone number, and no password.

To create an account, your browser solves a small proof-of-work challenge from Cap, an open-source captcha alternative that we host ourselves. Once solved, you’re issued a randomly generated 32-digit account number. That account number is your only credential, and it’s shown to you exactly once – the site requires you to download it and paste it back before continuing, because if you lose it, we cannot recover it. On our side we only store a keyed hash of the account number, so our database contains nothing that can be used to sign in as you. There’s also a separate non-secret support ID that you can share with us if you ever need help, without exposing your account number. If you want the convenience, you can optionally add a passkey to your account to sign in with.

No IP logging, anywhere

In our original launch post we said that we don’t log the IPs of active users. In v2, we went much further. The application never stores a client IP address anywhere – not even hashed – and the reverse proxy and captcha service in front of it are explicitly configured to discard IPs as well. The rate limiting that prevents abuse of free account creation uses short-lived counters that expire on their own, so there is no lasting record tying an account to an IP address.

This extends down to the proxy servers too. The control plane automatically inspects the logging configuration of our Xray panels and disables access logging if it’s found to be enabled. The full details, along with a checklist for anyone deploying their own instance, are documented in docs/privacy.md in the repository.

CDN fronting, HPKE & proof-of-possession

To stay reachable in heavily censored countries, the FreeSocks website and API are fronted through a large CDN. Blocking shared CDN IPs takes thousands of unrelated websites down along with ours – and while we’ve seen in Iran that censors are sometimes still willing to accept that damage, fronting makes blocking us much harder and much more costly for them. We also benefit from Encrypted Client Hello (ECH) when fronting through a CDN. Normally, the domain name you’re connecting to is sent in plaintext at the start of a TLS connection, even though everything after it is encrypted. ECH encrypts the domain name too, so a censor watching the wire can’t tell a connection to FreeSocks apart from a connection to any other website behind the same CDN.

Beyond the CDN, the website depends on nothing external. There are no third-party scripts and no external fonts – the fonts, the captcha widget and its WebAssembly are all bundled and served by us under a strict content security policy. Third-party endpoints are a liability in censored countries; if a captcha or font provider is blocked, the website breaks for the people who need it most.

Fronting through a CDN comes with a cost, though: the CDN terminates TLS, which means it can see the traffic between you and us in plaintext. Anyone who can read the CDN’s traffic – through stored logs, compelled disclosure, or an insider – could harvest the two most sensitive secrets FreeSocks handles: your account number and your VPN key. We built two layers of protection into v2 to mitigate this, and we think they’re pretty neat.

The first layer is HPKE encryption of sensitive data. Your browser encrypts sensitive request bodies (such as your account number during login) directly to our server, and the server encrypts sensitive responses (such as your VPN key) back to a fresh one-time key that your browser generates for each request. A CDN in the middle only ever sees ciphertext, even if TLS is broken. The encryption uses X-Wing, a hybrid of classical X25519 and post-quantum ML-KEM-768, so an adversary recording traffic today and hoping to decrypt it once a quantum computer exists gets nothing – it stays secure as long as either algorithm holds up. On top of that, the server rotates short-lived encryption keys every 10 minutes and destroys the retired ones, so even a future compromise of our server keys can’t decrypt past logins.

The second layer is proof-of-possession (PoP) sessions. A session cookie is normally a bearer credential – anyone who captures one can replay it. In v2, when you sign in, your browser generates a non-extractable signing key inside a Web Worker. The private key can never be read out, not even by our own JavaScript. Every authenticated request is then signed with that key, covering the request method, path, a hash of the exact request body, a timestamp and a single-use nonce. The server verifies the signature and burns the nonce, so a captured cookie is useless on its own and a captured request can’t be replayed. The same protection covers our admin dashboard, where sensitive actions like uploading server credentials are HPKE-encrypted as well.

We want to be honest about what this does and doesn’t protect against. It defeats a passive observer – CDN logging, compelled disclosure, insiders – including the future quantum version of that adversary. It cannot, by itself, defeat an active CDN that rewrites the JavaScript we serve, because no browser-delivered cryptography can. To narrow that gap, our builds are reproducible (CI builds the site twice and asserts the output is byte-for-byte identical), every script the site loads is integrity-pinned, and the site includes a “Verify this connection” panel that displays the key fingerprints your browser is using, so they can be compared against the values we publish out-of-band. Our future native app will narrow it further – its code ships with the app instead of being delivered through the CDN, while its API traffic stays protected by the same encryption. For those interested in the technical side, the full threat model is documented in docs/threat-model-cdn-blinding.md.

Memberships & donations

FreeSocks is free, and it always will be. However, running a global proxy network costs a considerable amount of money. v2 introduces an optional membership at $5/mo that removes the traffic limits on your key, for those who want to support the service and get something extra in return.

We built the payment system to store zero payer information. Payments happen entirely on processor-hosted pages – Bitcoin through our own self-hosted BTCPay Server, other cryptocurrencies, or card and PayPal – and the only thing that comes back to us is a signal that an order was paid. We never see or store names, emails or addresses. You can also purchase a membership as a gift code and give it to someone who can’t pay for one themselves.

Donations made through FreeSocks work a little differently, and we’re really excited about this part: donations fund a shared monthly bandwidth bonus that is split across every free user on the service. When someone donates, everyone’s free traffic allowance goes up for that month. The public impact numbers show gigabytes and user counts, never dollar amounts.

Translations

In our 2023 launch post, we said we planned to translate the website so that people who can’t read English can use the service. FreeSocks is now available in English, Farsi, Arabic, Russian and Simplified Chinese, with full right-to-left support. A native-speaker review of the translations is in progress. We also said we planned to provide mirrors in case the main URL is inaccessible – members can now mirror their subscription across multiple storage providers directly from their account.

Self-host your own FreeSocks

Everything described above is open source and built to be self-hosted. If you’re an operator who wants to run a proxy distribution service for your own community, the repository includes documentation for deploying the whole stack with Docker, from a fresh install to a production cutover. We’d love to see others deploy it.

If you find a security issue, please report it privately via SECURITY.md – this software protects people in high-risk environments.

We need your help!

Unredacted Inc is a 501(c)(3) non-profit organization, and we directly depend on generous donors like you to fund our operations. If you like what we do, and want to support our mission, please consider making a donation. With FreeSocks v2, every donation made through the service directly raises the free bandwidth of every free user each month.

If you live in, or are visiting, a country with a heavily censored Internet – create an account and share FreeSocks with your friends who might be subjected to Internet censorship. If you use the service and have any trouble, please contact us.

We’ve worked really hard on FreeSocks v2, and we hope that you can get good use out of the service!