No. This project is under active development. We’re happy to accept and fix issues as they are identified. Use Algo at your own risk. If you find a security issue of any severity, please contact us on Slack.
WireGuard reached “stable” 1.0.0 release in Spring 2020. It has undergone substantial security review.
The goal of this project is not to provide anonymity, but to ensure confidentiality of network traffic. Tor introduces new risks that are unsuitable for Algo’s intended users. Namely, with Algo, users are in control over the gateway routing their traffic. With Tor, users are at the mercy of actively malicious exit nodes.
Racoon does not support IKEv2. Racoon2 supports IKEv2 but is not actively maintained. When we looked, the documentation for strongSwan was better than the corresponding documentation for LibreSwan or OpenSwan. strongSwan also has the benefit of a from-scratch rewrite to support IKEv2. I consider such rewrites a positive step when supporting a major new protocol version.
I would, but I don’t know of any suitable ones. If you’re in the position to fund the development of such a project, contact us. We would be interested in leading such an effort. At the very least, I plan to make modifications to strongSwan and the environment it’s deployed in that prevent or significantly complicate exploitation of any latent issues.
OpenVPN does not have out-of-the-box client support on any major desktop or mobile operating system. This introduces user experience issues and requires the user to update and maintain the software themselves. OpenVPN depends on the security of TLS, both the protocol and its implementations, and we simply trust the server less due to past security incidents.
Alpine Linux is not supported out-of-the-box by any major cloud provider. While we considered BSD variants in the past, Algo now focuses exclusively on Ubuntu LTS for consistency, security, and maintainability.
Algo deliberately supports only one modern cipher suite (AES256-GCM with SHA2 and P-256) rather than offering a menu of cryptographic options. This design decision enhances security by:
The chosen cipher suite (AES256-GCM-SHA512 with ECP384) represents current cryptographic best practices and is supported by all modern operating systems (macOS 10.11+, iOS 10+, Windows 10+, and current Linux distributions). If your device doesn’t support this cipher suite, it’s likely outdated and shouldn’t be trusted for secure communications anyway.
Algo is designed for privacy and security, not censorship avoidance. This distinction is important for several reasons:
Different threat models - Censorship circumvention requires techniques like traffic obfuscation and protocol mimicry that add complexity and potential vulnerabilities. Algo focuses on protecting your data from eavesdroppers and ensuring confidential communications.
Legal considerations - Operating VPNs to bypass censorship is illegal in several countries. We don’t want to encourage users to break local laws or put themselves at legal risk.
Security focus - Adding censorship circumvention tools would expand our codebase significantly, making it harder to audit and maintain the high security standards Algo promises. Each additional component is a potential attack vector.
Separation of concerns - Tools like Tor, Shadowsocks, and V2Ray are specifically designed for censorship circumvention with teams dedicated to that cat-and-mouse game. Algo maintains its effectiveness by staying focused on its core mission: providing a secure, private VPN that “just works.”
If you need to bypass censorship, consider purpose-built tools designed for that specific threat model. Algo will give you privacy from your ISP and security on untrusted networks, but it won’t hide the fact that you’re using a VPN or help you access blocked content in restrictive countries.
No. By design, the Algo development team has no access to any Algo server that our users have deployed. We cannot modify the configuration, update the software, or sniff the traffic that goes through your personal Algo VPN server. This prevents scenarios where we are legally compelled or hacked to push down backdoored updates that surveil our users.
As a result, once your Algo server has been deployed, it is yours to maintain. It will use unattended-upgrades by default to apply security and feature updates to Ubuntu, as well as to the core VPN software of strongSwan, dnscrypt-proxy and WireGuard. However, if you want to take advantage of new features available in the current release of Algo, then you have two options. You can use the SSH administrative interface to make the changes you want on your own or you can shut down the server and deploy a new one (recommended).
As an extension of this rationale, most configuration options (other than users) available in config.cfg can only be set at the time of initial deployment.
Algo is short for “Al Gore”, the Vice President of Networks everywhere for inventing the Internet.
You can temporarily disable DNS filtering for all IPsec clients at once with the following workaround: SSH to your Algo server (using the ‘shell access’ command printed upon a successful deployment), edit /etc/ipsec.conf, and change rightdns=<random_ip> to rightdns=8.8.8.8. Then run sudo systemctl restart strongswan. DNS filtering for WireGuard clients has to be disabled on each client device separately by modifying the settings in the app, or by directly modifying the DNS setting on the clientname.conf file. If all else fails, we recommend deploying a new Algo server without the adblocking feature enabled.
Yes, Algo includes privacy enhancements that minimize logging by default. StrongSwan connection logging is disabled, DNSCrypt syslog is turned off, and logs are automatically rotated after 7 days. However, some system-level logging remains for security and troubleshooting purposes. For detailed privacy configuration and limitations, see the Privacy and Logging section in the README.
No.
Per security researcher Thomas Ptacek:
In 2001, Angelos Keromytis — then a grad student at Penn, now a Columbia professor — added support for hardware-accelerated IPSEC NICs. When you have an IPSEC NIC, the channel between the NIC and the IPSEC stack keeps state to tell the stack not to bother doing the things the NIC already did, among them validating the IPSEC ESP authenticator. Angelos’ code had a bug; it appears to have done the software check only when the hardware had already done it, and skipped it otherwise.
The bug happened during a change that simultaneously refactored and added a feature to OpenBSD’s ESP code; a comparison that should have been == was instead !=; the “if” statement with the bug was originally and correctly !=, but should have been flipped based on how the code was refactored.
HD Moore may as we speak be going through the pain of reconstituting a nearly decade-old version of OpenBSD to verify the bug, but stipulate that it was there, and here’s what you get: IPSEC ESP packet authentication was disabled if you didn’t have hardware IPSEC. There is probably an elaborate man-in-the-middle scenario in which this could get you traffic inspection, but it’s nowhere nearly as straightforward as leaking key bits.
To entertain the conspiracy theory, you’re still suggesting that the FBI not only introduced this bug, but also developed the technology required to MITM ESP sessions, bouncing them through some secret FBI-developed middlebox.
One year later, Jason Wright from NETSEC (the company at the heart of the [I think silly] allegations about OpenBSD IPSEC backdoors) fixed the bug.
It’s interesting that the bug was fixed without an advisory (oh to be a fly on the wall on ICB that day; Theo had a, um, a, “way” with his dev team). On the other hand, we don’t know what releases of OpenBSD actually had the bug right now.
It seems vanishingly unlikely that there could have been anything deliberate about this series of changes. You are unlikely to find anyone who will impugn Angelos. Meanwhile, the diffs tell exactly the opposite of the story that Greg Perry told.
You should only need 4160/TCP, 500/UDP, 4500/UDP, and 51820/UDP opened on any firewall that sits between your clients and your Algo server. See AlgoVPN and Firewalls for more information.
Your Algo server will track IPsec client logins by default in /var/log/syslog. This will give you client names, date/time of connection and reconnection, and what IP addresses they’re connecting from. This can be disabled entirely by setting strongswan_log_level to -1 in config.cfg. WireGuard doesn’t save any logs, but entering sudo wg on the server will give you the last endpoint and contact time of each client. Disabling this is paradoxically difficult. There isn’t any out-of-the-box way to monitor actual user activity (e.g. websites browsed, etc.)
By default, your Algo server doesn’t allow connections between connected clients. This can be changed at the time of deployment by enabling the BetweenClients_DROP flag in config.cfg. See the “Road Warrior” instructions for more details.