How it works
What MultiOBX is made of
A short account of what the service runs on and why it is built this way. Only things that are in the code and can be checked.
01Foundation
The WireGuard protocol
The tunnel runs on WireGuard. It has a fixed set of ciphers (ChaCha20-Poly1305 for traffic, Curve25519 for key exchange), so there are no settings that could be weakened by accident. The protocol code is small and its handshake has been formally verified.
The handshake takes one round trip. That is why the connection comes up in a fraction of a second and survives a change of network: switch from Wi-Fi to mobile data and the tunnel carries on from where it was.
A service written in Rust
The service that holds the tunnel and the network rules is written in Rust. The language rules out memory errors, which account for most vulnerabilities in networking software.
The app window runs separately and without administrator rights. It talks to the service over a Windows named pipe rather than a port on localhost, which a page open in a browser could otherwise reach.
02The gate goes up before the tunnel
Firewall rules are set before the network adapter is created, not after.
The order on connect is: set the rules "close everything except the server address", create the adapter, wait for the handshake, configure DNS, allow traffic through the adapter. Between the first and the last step not a single packet leaves the machine. The order is pinned by a test: change it and the build fails.
A dropped link, an unreachable server or a tunnel restart do not open the network. Only the "Disconnect" button does. There is also a "lock" mode: with it the internet does not work without the tunnel at all, even after you disconnect by hand. Useful on a laptop that wakes up in a café or a hotel.
03DNS kept apart
Before opening a site, the computer looks up its address by name. These DNS queries leave the machine separately from the rest of the traffic, and they are the most common leak. A typical case: you enable "Local network" so the printer works, but the home router is on the local network too, and the queries go through it to the ISP.
Here DNS lives in its own layer of rules. Only the resolver inside the tunnel and the local address 127.0.0.1 are allowed. Even with the local network enabled, the router will not see a DNS query. There is a dedicated test for this.
The rule that allows the connection to our server is bound to the service executable. No other program can send a packet to the server address around the tunnel.
All rules live in the Windows Filtering Platform, the system traffic filter. Any program that can read WFP can see them, and they do not depend on whether the app window is open.
04When the network throttles traffic
Office, hotel and some mobile networks may limit or slow down UDP. For that case the app has several ways to establish a connection. It tries them one after another.
Plain UDP
The standard WireGuard mode. The fastest. Works at home and on almost every mobile network.
Over TCP, port 443
The same tunnel inside a TCP connection to port 443. That port is open almost everywhere, because ordinary websites use it.
Through two servers
Traffic enters one server and leaves from another. The first sees your address but not where you are going. The second sees the opposite. Available when there is more than one server.
There is also a route through a network of volunteer anonymous nodes. The connection passes three nodes, and none of them knows both the sender and the recipient. It is slower than the rest, but our server takes no part in that route. No separate program is needed, it is all inside the app.
Which method got through on your network is shown in the "Diagnostics" section. We cannot guarantee a connection on every network.
05Where the app gets the server list
The app has to get the list of servers from somewhere. If that source disappears, it cannot connect even when the servers themselves are fine. This is the weak spot of any such service.
So the list is signed (Ed25519), and the public key for checking the signature is built into the app at compile time. The server does not hold that key. A tampered list is rejected. The list can be fetched over several independent routes: from the main address, from backups, through encrypted DNS queries to public resolvers. One working route is enough.
App updates are signed the same way. The private signing key is kept by the owner, not on the servers: a compromised server cannot hand out someone else's program as an update.
06What is stored on the server
- The key
- 24 characters from a 31-symbol alphabet, without 0, O, 1, I and L so they are not confused when copied by hand. The last character is a checksum, so a typo is caught before anything is sent. The server keeps an HMAC-SHA256 of the key; the key itself is not written anywhere.
- Devices
- The WireGuard public key, the address inside the tunnel, a name from a word list. The computer's real name is never requested.
- Term
- The date until which time is paid. Nothing more.
- Logs
- The servers keep no connection logs: who, when, where. There is nothing to store and nothing to hand over.
- Changing the key
- Once every 30 days the key can be replaced from the account page. Devices, addresses and paid days stay. The old key stops working immediately.
07How to check
The app has a "Diagnostics" section. It shows whether the service has the rights to set rules, how many rules are in place right now and which ones, which DNS is in use, and when the last handshake happened. The same from the command line: multiobx doctor.
The rules can also be listed without our app, with Windows itself:
netsh wfp show filters file=filters.xml
A simple experiment: connect, unplug the cable or turn off Wi-Fi for a couple of seconds, then put it back. The internet returns only together with the tunnel, not before.