Diskless infrastructure in beta (System Transparency: stboot)
Diskless infrastructure using stboot (in beta) is now available on a pair of WireGuard servers in Sweden.
Today we are introducing our first VPN servers booted with our new bootloader - stboot. This marks the start of our long-running public-facing journey to make our VPN infrastructure transparent and user-auditable.
Diskless infrastructure for VPN servers
Today we announce an early beta release of a part of our System Transparency technology running on one VPN server in Gothenburg and one in Stockholm, Sweden. Both of these servers are listed in a “System Transparency [BETA]” city in our server list, viewable within our app as well as on our website.
You can find these servers by selecting: Switch Location → Sweden → System Transparency [BETA]
Make sure you are using the WireGuard protocol (applies to desktop app only).
This means that we now have two servers running entirely on RAM, without any disks in use.
What does “without any disks in use” mean?
- If the computer is powered off, moved or confiscated, there is no data to retrieve.
- We get the operational benefits of having fewer breakable parts. Disks are among the components that break often. Therefore, switching away from them makes our infrastructure more reliable.
- The operational tasks of setting up and upgrading package versions on servers become faster and easier.
- Running the system in RAM does not prevent the possibility of logging. It does however minimise the risk of accidentally storing something that can later be retrieved.
Where do you pull data from if you have no disks to store it on?
For these servers we make use of provisioning servers in order to download an “OS Package”. These provisioning servers have disks but they contain only the signed images and some base configuration data that our System Transparency (or stbooted) servers will use.
Our VPN servers launch the System Transparency bootloader (stboot) which downloads the OS package from a provisioning server and verifies that it originates from relevant Mullvad VPN staff by checking its signatures. If the OS package is valid, the OS is booted. The server then waits for an authorised member of staff to provision and deploy it for customer use.
By and large, these servers will be configured in a similar manner to our other WireGuard servers, except we use no disks, and RAM is the only location where data is kept.
Debug output stboot starting up
Debug output OS package signatures verified
What happens when the server is restarted?
At this point, the server would boot up, unaware about its past history due to using no disk. The process would be the same as in the previous step (download, verify, wait for authorisation).
In other words, we have amnesia for servers.
If this is the first of many steps, what happens next?
We get your feedback, if any, on how well it works!
We will continue to develop our provisioning and deployment process of stbooted VPN servers, starting with the ones providing WireGuard tunnels. We will start adding more servers in different locations as we get more comfortable and the projects' moving parts become more mature.
End goal: Trustworthiness through transparency
We are continuously striving to strengthen the trustworthiness of all aspects of our service. This is why our VPN apps have been open source since we started over 12 years ago. Achieving transparency on the server side is a very different challenge, as merely open sourcing our server software is not enough. We want our users to be able to verify and audit what is currently running on the VPN server they are connected to. This is our end goal with System Transparency.
Note
During this beta, WireGuard keys will be wiped on each server restart. If you are using configuration files to connect to the servers you will need to download new ones each time this happens. This does not affect the Mullvad App.