Here are some additional details for those interested. We intend to make use of TPM for remote attestation of the current boot chain, reproducible builds to provide a strong link from source code to build artifacts, and a transparency log for a historical record of previously used boot chains, artifacts, WireGuard server keys, and related signatures.
As dtx1 mentioned elsewhere in this thread, diskless VPN infrastructure is currently in use by many other VPN providers. That is not a novel feature of course. What is novel is user-auditability of running VPN infrastructure. We were the first VPN provider to state our intention to make our infrastructure user-auditable AND provide a realistic roadmap with the specific technologies needed to do so. See the link above.
I believe the technologies we use in System Transparency will ultimately reshape the VPN provider industry into a highly competitive space focused on maximizing the transparency of VPN infrastructure. Or not, but at least OUR users will be able to audit us. :)
Either way we’re looking forward to the future. The opportunity for improvement is immense.
Niiice. I really love the concept of reversing the usual DRM use of remote attestation--forcing customers to prove they're running only software allowed by the megacorps. Instead of DRM, it's proving the corporation/server is trustworthy to the customer.
Check out tpm2-totp. I stumbled across it while looking for a way to store totp secrets in my tpm, and was really impressed with the clever use of totp to verify a boot chain.
If you're from Mullvad, let me tell you that I love your service.
I had one technical support question, and I got an immediate response from an actual person who knew this problem, gave me a simple workaround (toggle between wireless connection and not), and told me that a permanent fix was in the works. Likely that fix rolled out because I haven't seen the issue in months.
The idea of an account that doesn't need a password because there's no critical information saved is such a nice one, too.
Keep up the good work - I recommend you to everyone.
This all sounds very exciting. Where will you draw the line between public and private – at the moment your consumer-facing app is on github, but less "server side" stuff (in common with many other VPN providers). I understand that probably you want to keep the database of "active numbers" private, but if I understand you correctly, you want to move to a model where anyone can download your in-memory image, run it in a VM, and audit it independently. I would welcome this. I'm particularly interested in how you maintain access to your bare-metal machines (e.g. do you have ssh / a serial console enabled)
> Where will you draw the line between public and private – at the moment your consumer-facing app is on github, but less "server side" stuff (in common with many other VPN providers).
All source code for all software on our VPN servers must eventually be public, and all build artifacts must be reproducible by 3rd parties.
> I understand that probably you want to keep the database of "active numbers" private, but if I understand you correctly, you want to move to a model where anyone can download your in-memory image, run it in a VM, and audit it independently.
Exactly, but we will also have to measure each artifact in the boot chain into the platform TPM, and allow anyone to issue a challenge to the TPM to get a signed quote of the boot chain measurements.
> I would welcome this. I'm particularly interested in how you maintain access to your bare-metal machines (e.g. do you have ssh / a serial console enabled)
We’ll have to constrain our own ability to access the VPN servers. We cannot be allowed arbitrary root access as that would make the TPM measurements meaningless from an audit perspective. Well, you’d be able to conclude we have root access, so not totally meaningless.
> Isn't network monitoring and logging the bigger issue for a VPN service?
Great point. I have a hard time comparing the importance of the integrity of our VPN servers with monitoring and logging of network traffic happening upstream of them without a long discussion of the many nuances. Let’s leave it at; they are both very important issues.
> How can you provide transparency of the network?
That’s very hard. Individual AS’s upstream of the VPN server you’re connected to might change their routing at any moment, and suddenly your traffic makes its way through an unexpected AS or jurisdiction, which may change the monitoring situation completely.
Enabling our users to use multiple hops is one mitigation, another is vetting our data center providers. In collaboration with some of our Internet providers in Europe we have deployed protections on layers below IP. Come to think of it, I don’t think we’ve blogged about that. Thanks!
Here are some additional details for those interested. We intend to make use of TPM for remote attestation of the current boot chain, reproducible builds to provide a strong link from source code to build artifacts, and a transparency log for a historical record of previously used boot chains, artifacts, WireGuard server keys, and related signatures.
As dtx1 mentioned elsewhere in this thread, diskless VPN infrastructure is currently in use by many other VPN providers. That is not a novel feature of course. What is novel is user-auditability of running VPN infrastructure. We were the first VPN provider to state our intention to make our infrastructure user-auditable AND provide a realistic roadmap with the specific technologies needed to do so. See the link above.
I believe the technologies we use in System Transparency will ultimately reshape the VPN provider industry into a highly competitive space focused on maximizing the transparency of VPN infrastructure. Or not, but at least OUR users will be able to audit us. :)
Either way we’re looking forward to the future. The opportunity for improvement is immense.