I am seeking feedback. I made a PR about adding info about Mullvad’s new obfuscation technique.
See a preview here
I also introduce new criterias, that all current providers meet.
I am a bit confused by this, possibly due to my lack of knowledge on the subject but, is there a specific definition of what “secret logging” is? Would PG be able to define what countries/jurisdictions do not allow it?
It just seems a bit ambiguous to be a requirement.
This would be for example US gag orders forcing a company to give info about a customer and stay silent about this. Another example would be China’s law stipulating that any company must help intelligence agencies, so including spying etc and they can’t tell about it.
That isn’t really necessary. We can check when a new VPN recommendation is proposed. All current VPNs meet the criteria.
Generally, EU democracies don’t have this kinda of secret courts.
Curious: What informs this criteria?
Both FDE and RAM-only machines don’t mean much when the servers themselves are virtual or in a colo (not in a DC owned by the provider, say). None of the two techniques would help much against adversaries with physical access to bare metal.
Privileged remote access in to these servers (ex via SSH) are also another possible compromising vector where RAM-only / FDE don’t help move the needle in any meaningful way, either.
Thank you, this is an interesting proposal !
What is the goal of an optional criteria ? Then it is not a criteria anymore ?
If you don’t have this, anyone could easily “sneak in” the datacenter, like during a maintenance phase, and easily copy the logs (mostly debigging but can still be valuable).
It is still a nice thing to have, but VPNs recommended by PG aren’t shared servers (I am assuming this is what you mean by Colo).
But you can read what VPN providers say about it
Proton VPN
Mullvad VPN
IVPN
The VPN providers still have some control and can say that they only want RAM servers. For FDE, I am not sure how this would work. But RAM-only servers are the safest as all data is gone after it is powered off.
It’s not mutually exclusive, and it is not a silver bullet, but it is a needed security, hence why all our listed providers comply with this requirement.
[quote=“mangomango, post:5, topic:21864”]
What is the goal of an optional criteria ? Then it is not a criteria anymore ?
I meant a “Best-case” criteria. Those are what we would like to see, but none all of them meet the criteria.
I can see the point. I think the adversary VPNs advertise this feature towards is seizure of servers, and not protection against data centre itself (although couldn’t the adversary just keep the server running while seizing it, even if it’s just RAM only?).
It’s mostly a placebo in my opinion too, but it does show that the provider at least is focused on server security maybe? So the feature is a proxy for provider’s approach towards servers ig.
Afaik, Proton has secure core where they actually own the bare metal server and do multi-hop there, so that might be a better way to approach this? Since now even seized datacentre servers can only yield data about proton’s servers.
VPNs are anyways just more trusted ISPs in regions where ISPs can be forced to log easily.
Eh, honestly most of them do (Germany does, France does, Britain does, Ireland does, etc.). They either have statutory laws/ executive ordinances for direct surveillance, or treaties for foreign intelligence exchange. That’s partially why jurisdictions like Switzerland are in demand: The existing laws explicitly forbid this stuff instead of depending on judicial/parliamentary/executive discretion or interpretation.
I think they meant colocated servers. But do you have a source for providers not using shared servers at all? I remember proton sharing space with Nord VPN, and mullvad shared it with similarly dubious providers at some point. I could be wrong though, and it could be that they were just colocated, not shared.
Thanks.
This is a misconception. RAM-only servers are susceptible to cold boot attacks.
As long as these servers (RAM-only / FDE) are accessible remotely, the threat of “sneaking in” is not mitigated. In fact, it is cheaper to (social) engineer your way past SSH logins than it is to sneak in physically in each of the server locations.
Those webpages don’t talk about whether these providers build their own DCs? Or, use bare metal?
I’d not say it is “needed”, since (in our model) it doesn’t sufficiently mitigate “sneaking in” part concretely. For that, what’s needed is zero access servers. Once these boot up, except for the what the server wants to serve nothing goes in or out, and in case of virtual / guest machines, it must be guaranteed to not be beholden to the host machine in any shape or form. As Signal (with Secure recovery) & Apple (Private Compute Cloud) have demonstrated.
I’m missing something here. You’re arguing that FDE/Ram only are not enough to make a VPN server secure, but that seems to be beyond the point. So the real question is: are they useless? Is there no gain in avoiding non-ram-only servers, or in other words, making it a requirement for recommendations?
That Mullvad episode where the police seized their servers comes to mind as a case study. I’m not familiar enough to call it an argument, but people who know the details might contribute more.
In this context, yes. imo, these are at best necessary but not sufficient. That is, the threat here (as the OP put it) is adversaries “sneaking in”, then both RAM-only & FDE, on their own, are not sufficient at all, if not accompanied with, say, zero remote access (which Mullvad does not have), or absent that, owning the DCs.
imo, Apple (for AI) and Signal (for PIN recovery) have designed a more serious architecture for “private compute” that amply addresses the threats of actors “sneaking in”. In fact, Android 14+ has a variant too (pKVM), for sensitive processing like DRM & Pay.