[dangus]

There is no disk in the servers, so there is no chance for user information to persist anywhere.

I also wouldn’t be surprised if it’s a performance benefit, since RAM is far faster than any permanent storage.

The cons are probably just that this is a pretty unusual architecture that they probably had to put some work into setting up and making it reliable.

[Daviey]

It's essentially a PXE-boot diskless environment, what makes you think it is unusual and possibility of being unreliable?

[Brian_K_White]

What important things do you store only in ram? Why not? Isn't it reliable?

I think they just mean ephemeral.

[panick21_]

What is unusual is the firmware that they have.

[dangus]

I should say, unsuitable for certain use cases.

[johnklos]

I have servers which have literally been running non-stop for multiple years. Unless / until the kernel itself needs to be upgraded for security issues, and so long as backup power is good, they can run indefinitely.

[justapassenger]

Not a best setup to run database, yes. But stateless farm of servers that essentially forward the traffic for you? Not that much downsides.

[thathndude]

Technically, researchers have proven that you can shutdown a machine, hit the RAM with a cold spray (like liquid nitrogen) and keep the bits "alive" long enough to dump them for analysis.

But, obviously, that's pretty insane. Agree with everything that this is a big leap in the step of better protection for users.

[NhanH]

Even if that attacks has close to 100% success rate, I'd imagine it being nigh physically impossible to execute a targeted attack, as you don't know which machine to hit for a specific user. And that seems to be the main threat model we would be concerned about for this.

[foobiekr]

Of course they know which machine to hit. How do you do customer service without such a basic function?

[hiatus]

Mullvad gives you the option to connect to multiple servers. They offer wireguard configs for every endpoint. How does law enforcement know which server the client plans to connect to? There is no metering either, just a flat monthly rate so nothing to track there either.

[foobiekr]

I find these discussions so tiring. Let me turn it around. In their position, how would you manage this? Might you hook authentication events? Why are you pretending this is hard?

[hiatus]

You can connect to mullvad via tor though. If I only ever went to the mullvad site via tor to make an account, paid in monero and only ever accessed the VPN via tor, what is there to hook into?

[caeril]

There's a fairly easy physical mitigation for this.

Once DIMMs are seated, secure the ends with superglue, then brush conformal coating over the bus traces.

The second step is likely not even necessary if the motherboard is a 4 layer pcb with traces in the middle.

[sumtechguy]

The likelihood of them showing and doing that is low. However, the likelihood of them showing up with a set of USB drives and just running rsync/cp/dd is higher.

[heyoni]

Normally you unplug the drives and take them to a lab. Never let the host operating system continue running with those disks!

[jstarfish]

Maybe in the 90s. Unplugging the drive is how you kick FDE in now. The drive only has value while mounted and running on the host OS.

Even cellphones...you want them running decrypted, but inside a Faraday cage of some kind to block remote wipes.

[heyoni]

I don’t know how FDE works so thanks for the correction. I’ve read stories about feds pulling out drives and asking for keys later.

But to run dd wouldn’t you need root access? And couldn’t you use that to dump the FDE keys from memory?

[densh]

You can still mount a remote networked file system to a dikless node. Lack of disks does not guarantee inability to persist data.

[Brian_K_White]

If only the system were open source so you wouldn't have to wonder about that...

But we do still have to trust that they are actually running the code they posted.

Unless that code somehow contains some way to verify itself?

I wonder if there is some way to do that? Have the code include a hash of itself and some way to query the running service that guarantees that the running service must be running the code you are looking at?

At first glance it seems any response could always be faked, but maybe there is some cryptography trick where you submit something, like an encrypted copy of the public code maybe, and it crunches and returns something, and that somehow proves that the running code you can't see must be the same as the code you can see.

Depending on how the protocol for the challenge works, that could still be faked. The challenge has to somehow not be seperable from ordinary traffic so that you can't have one piece of code handle the challenge and another piece of code handle other traffic.

[meithecatte]

There are two known ways to achieve this:

- Multi-party computation. Too much overhead for something like this.

- Remote attestation, as seen in e.g. Intel SGX. Usually provided by the CPU vendor. Not a cryptographic guarantee, more of a "it'd be very hard to defeat this if you're not Intel". Probably not that warrant-resistant.

[c22]

Homomorphic encryption: https://en.wikipedia.org/wiki/Homomorphic_encryption

[lanstin]

I think the normal solution to this is all the prove you are the software you say you are calls is proxied to that software and all the normal services calls you want to log and duplicate or otherwise violate the contract are sent to the modified code.

[johnklos]

You can talk about hypothetically doing anything. You're not really making a point.

Hypothetically, you can rewrite the firmware for the IPMI with a backdoor and extract data.

Hypothetically, you could kidnap the family of a developer and force them to add a surreptitious side channel for exfiltrating data.

Hypothetically, you could run the universe in a simulator and use the simulator's controls to read data from RAM in the simulated Mullvad servers on the simulated Earth.