[HN Gopher] Moving our Encrypted DNS servers to run in RAM
___________________________________________________________________
Moving our Encrypted DNS servers to run in RAM
Author : kisamoto
Score : 279 points
Date : 2023-11-10 10:51 UTC (12 hours ago)
(HTM) web link (mullvad.net)
(TXT) w3m dump (mullvad.net)
| kisamoto wrote:
| Mullvad encrypted DNS is also available to all - whether paying
| for VPN services or not.
|
| In addition they also support optional content blocking[1] via
| blocklists, just set the desired TLS/HTTPS DNS server.
|
| [1] https://github.com/mullvad/dns-blocklists
| Etheryte wrote:
| FYI the standalone encrypted DNS profiles for macOS
| (.mobileconfig files) do not work if you're using Little Snitch
| or Lulu to block unwanted network traffic. This is a limitation
| of macOS that Apple hasn't bothered to fix.
| WirelessGigabit wrote:
| Doesn't work how? Little Snitch / Lulu don't use the profile?
| As in DNS traffic is not encrypted?
|
| Little Snitch / Lulu die?
|
| Do you have like a ticket for more explanation?
| Etheryte wrote:
| You can have one or the other active at a time, but not
| both simultaneously. If you have the DNS profile turned on
| and then proceed to turn on Little Snitch/Lulu, the DNS
| profile will get turned off by macOS and whatever other DNS
| configuration you have will take precedence. It's mentioned
| in passing by Mullvad in the docs [0]:
|
| > If you have more than one profile added then macOS seems
| to use only the last one that you installed. If you remove
| a profile then it appears that it will not use any of the
| other profiles.
|
| This isn't unique to Little Snitch/Lulu and Mullvad though,
| you would run into the same problem with any application
| that creates a network filter by using a profile, see [1]
| for example. Since the full blown Mullvad VPN app does not
| use system profiles, it does work in tandem with Little
| Snitch/Lulu.
|
| [0] https://mullvad.net/en/help/dns-over-https-and-dns-
| over-tls#...
|
| [1] https://git.codeproxy.net/paulmillr/encrypted-
| dns/issues/13
| SV_BubbleTime wrote:
| Can you help me out with the threat model for encrypted DNS?
|
| As I see it, the model is that I need to contact a site, and
| use DNS to get the IP - but either my ISP or my VPN provider
| can see I'm visiting that IP whether I looked it up just now,
| or knew it already.
|
| So unless the model is I'm using a VPN, but am leaking via
| someone else's logging DNS, I don't really get it.
| Etheryte wrote:
| Personally my main motivation is I don't want anyone to snoop
| what sites I visit and then sell that data, my ISP included,
| but there are other issues too. To quote Cloudflare [0]:
|
| > Queries could be directed to a resolver that performs DNS
| hijacking. For example, in the UK, Virgin Media and BT return
| a fake response for domains that do not exist, redirecting
| users to a search page. This redirection is possible because
| the computer/phone blindly trusts the DNS resolver that was
| advertised using DHCP by the ISP-provided gateway router.
|
| [0] https://blog.cloudflare.com/dns-encryption-explained/
| _Algernon_ wrote:
| Cant your ISP reverse lookup the IPs you connect to based
| on your IP headers anyways?
| jrockway wrote:
| They can, but pretty much everything will reverse lookup
| to Cloudflare or AWS.
| fullspectrumdev wrote:
| Rather amusingly, the massive centralisation of the
| internet, which is bad for privacy in every other way,
| actually protects you here.
| eddd-ddde wrote:
| Yep, cloudflare dns proxy essentially hides your origin
| ip addresses.
| prosody wrote:
| I think it might become a little more useful in some contexts
| at least once ECH gets wider adoption. In that case afaik
| only the DNS server and the remote host you're connecting to
| would know what FQDN you're connecting to--anyone else would
| only see the IP of the remote host. If the host serves
| requests for lots of different FQDNs, that's less information
| going around.
| johnmaguire wrote:
| DNS leaks have historically been a thorn in the side of the
| Tor project, if I understand correctly.
|
| Sure, you might have a SOCKS proxy configured for the HTTP
| request, but depending on how the program makes the DNS
| query, it might bypass that proxy:
| https://support.torproject.org/misc/check-socks-dns-leaks/
|
| Encrypted DNS isn't a perfect solution, because the request
| still won't go through the proxy, but at least it won't leak
| the info to your ISP (assuming you have something else
| configured as your DNS provider.)
|
| Obviously, this isn't limited to just Tor.
| elif wrote:
| I would like to see real statistics but my gut feeling from
| running read/write intensive data applications on SSD and ECC RAM
| is that both of them fail often enough that this move is somewhat
| lateral in terms of resiliency.
|
| But in terms of clawing raw performance decimals, I applaud the
| effort. This would be a fun redis project.
| stephen_g wrote:
| That's not the point - they promise to keep no logs, and the
| best way to demonstrate that they don't is to not even have any
| fixed storage in the servers at all (they presumably netboot
| from a read-only image). So they have done this with their VPN
| servers, now they are rolling out the strategy to DNS servers
| as well.
| elif wrote:
| That's fine but as long as it is connected to a network you
| cannot prove a system to be log-free.
|
| The majority of systems I've worked on used a message queue
| of some kind for logging rather than a file on disk.
|
| I suppose it could be useful to expedite downtime in the case
| that they are subpoenaed, but I doubt claiming to be diskless
| would prevent any subpoena.
| bragr wrote:
| With this kind of security, you're more guarding against
| your servers being seized or intelligence agency installing
| an implant.
|
| > I doubt claiming to be diskless would prevent any
| subpoena
|
| It does in Sweden. They've repeatedly squashed subpoenas
|
| > long as it is connected to a network you cannot prove a
| system to be log-free.
|
| Nothing is perfect. If you read their audits, it's clear
| admins could get at your traffic if they wanted
| ThePowerOfFuet wrote:
| This is why they have their architecture audited (and
| release the audit reports).
|
| https://mullvad.net/en/blog/2022/6/22/vpn-server-audit-
| found...
| ziddoap wrote:
| > _but I doubt claiming to be diskless would prevent any
| subpoena._
|
| It has already.
|
| See https://news.ycombinator.com/item?id=38220769
| Thaxll wrote:
| How do they troubleshoot issues without logs exactly?
| bragr wrote:
| Live monitoring and test instances. They have ssh access to
| prod
| dboreham wrote:
| By shipping the logs to another box.
| waynesonfire wrote:
| Logging doesn't require disks, the logs can be sent over the
| network.
| throwaway914 wrote:
| As a naive outsider: Does RAM in 2023 encrypt all its contents?
|
| Can we reliably "forget" the contents of what's in RAM by
| powering-off and letting some encryption key somewhere fade from
| a smaller, more volatile piece of memory? I'm curious what has
| been done to mitigate cold-boot attacks in RAM. What has changed
| in hardware? Are the keys to encrypt contents of RAM kept in the
| TPM or something?
| josephcsible wrote:
| Isn't that what Intel TME does?
| throwaway914 wrote:
| That does look like it:
|
| https://www.intel.com/content/www/us/en/developer/articles/n.
| ..
|
| Looks like AMD has an equivalent:
|
| https://www.tomshardware.com/news/intel-mktme-amd-memory-
| enc...
|
| I wish there were a sort of checklist that prints out in
| dmesg saying "Your RAM is encrypted: (check) Your machine has
| these mitigations against cold-boot attacks: ...some list
| here... (check, check, check)"
|
| In some contexts, I love how far we've come with secure boot,
| attestation, speculative execution mitigations, etc. but it's
| very difficult for the average Linux user to understand what
| they should expect for hardware security, and then work
| toward enabling all of it.
|
| I love what Gnome did in the last year in Settings -> Device
| Security:
|
| https://www.phoronix.com/news/Ubuntu-No-GNOME-Device-
| Securit...
|
| There's a detailed list here of what it's looking for:
|
| https://forums.debian.net/viewtopic.php?t=152705
|
| Not a fan of all the bound-to-Intel technologies. I wish the
| concept of what's being secured were identified, then made
| available in dmesg or through some /sys or /proc interface.
| adrian_b wrote:
| AMD Epyc servers have offered encrypted memory for many
| years.
|
| Intel is only now catching up.
| matja wrote:
| I have an AMD CPU and I get in my kernel logs during boot:
| [ 0.338594] Memory Encryption Features active: AMD SME
| throwaway914 wrote:
| I mean like a checklist of security capabilities that are
| enabled/disabled, all grouped together in dmesg. That is
| cool though, it does help
| jchw wrote:
| In this case I think the point of running from RAM is that
| there isn't non-volatile storage. Of course, someone who has
| physically compromised the server could do potentially bad
| things, but this makes it harder to e.g. persistently
| compromise a server, since it doesn't have storage to store
| malware on persistently, or e.g. accidentally or intentionally
| log data, since there is no local storage to log it on.
|
| Encrypting what's in RAM would possibly add some additional
| protection but realistically if things are done right what's
| left in RAM will probably be only marginally more interesting
| than what you can see over the wire; at most I'd expect you
| could see a tiny amount of active request data. That's just a
| guess, though.
| ignoramous wrote:
| > _since it doesn 't have storage to store malware on
| persistently, or e.g. accidentally or intentionally log data,
| since there is no local storage to log it on._
|
| Does this prevent _rootkits_?
|
| > _but realistically if things are done right what 's left in
| RAM will probably be only marginally more interesting_
|
| See: https://en.wikipedia.org/wiki/Cold_boot_attack
| jchw wrote:
| > Does this prevet _rootkits_?
|
| That's the idea. If the OS is immutable, where do you put
| them?
|
| Bootkits require further mitigation to prevent, but Mullvad
| has also put effort into that, too, with their secure
| coreboot bootchain.
|
| Of course as an end-user you still can't really fully
| validate a machine over the network has not been tampered
| with, so you're obviously ultimately still trusting Mullvad
| as you'd expect.
|
| > See: https://en.wikipedia.org/wiki/Cold_boot_attack
|
| Yes, that's what I'm referring to. I don't expect that
| there would be a significant amount of requests in RAM,
| probably just remnants of mainly what was active (and some
| de-allocated but not cleared remnants?) when the machine
| was reset.
| LinuxBender wrote:
| _That 's the idea. If the OS is immutable, where do you
| put them?_
|
| They would be in the PXE image. There was one time I
| flubbed on this actually. I had to change export options
| on our PXE servers to fix something and I forgot to
| change it back _adding my poor excuse of multitasking and
| being lazy_. This was in a Dev environment _we also used
| PXE in production believe it or not_. A developer sitting
| across from me said he changed something in the image by
| mistake and I said, _" That's not possi... oh crap."_ It
| was cool of them to call it out right away. Attackers
| probably won't be so kind.
| jchw wrote:
| For what it's worth though, that's possible to mitigate.
| I don't believe Mullvad uses PXE and they do have a
| "secure boot" validation chain, starting from Coreboot on
| the hardware.
|
| https://mullvad.net/en/blog/2022/1/12/diskless-
| infrastructur...
| ignoramous wrote:
| It is an improvement, for sure.
|
| _secure boot_ , as painful it is to get right, doesn't
| help when the vendor runs its own things with elevated
| privileges, like they are known to do:
| https://news.ycombinator.com/item?id=34085635
|
| Doubly so, when the said things are not only closed
| source but vulnerable themselves:
| https://archive.is/6ClWm
|
| Does _coreboot_ help in mitigating vuln in privilged
| vendor blobs?
| jchw wrote:
| Well, with Coreboot, you at least know the very first
| instructions executed by the x86 cores are under your
| control. That's all it can really do. Whatever else lurks
| beneath is really impossible for anyone to scrutinize
| without insane capital or insider knowledge.
|
| Mitigating the risk of Intel ME is obviously something
| that is complicated. The "state of the art" so-to-speak
| is really just rendering it non-functional. This isn't
| strictly related to Coreboot; that said, Coreboot has a
| page about ME:
|
| https://www.coreboot.org/Intel_Management_Engine
|
| And in general, when you're running Coreboot, you're
| running significantly less privileged blackbox blobs
| (possibly _none_ in some rare cases), and in general, the
| surface area of Coreboot is going to be _dramatically_
| tinier than any typical UEFI system firmware. So it 's
| absolutely worth it in that regard.
|
| There's never going to be a "perfect" option here with
| how complex things have gotten, but I think that you can
| _at least_ say that Mullvad has taken almost any
| reasonable step, and perhaps a few steps that are beyond
| what many would consider reasonable, towards developing
| effective mitigation of the risks of rootkits, bootkits
| and malicious /unwanted vendor code running on their
| "diskless" architecture.
|
| Of course, you _still_ have to trust Mullvad. Trust is
| definitely a meaty human-y experience, and the cold
| rational part of our brain craves some kind of
| technically-bulletproof way to _prove_ that it 's truly
| safe, secure, and private, but that's just not possible.
| Best you can do is layer enough assurances on top of
| each-other in a way that at least some layers are
| completely independent of others for maintaining your
| operational security. Far easier said than done, and
| obviously how rigorously one approaches this will vary on
| paranoia.
|
| At some point you have to pick your middle-ground I
| suppose.
| generalizations wrote:
| > we also used PXE in production believe it or not
|
| Wait why would this be a bad thing?
| LinuxBender wrote:
| It depends on your use case, SLA's and configuration
| management role/structure discipline. There are different
| schools of thought on _diskless_ boot which is not truly
| diskless as the images have to be shared from somewhere
| meaning that disk availability goes from 1:1 to many to
| one increasing the blast radius of outages when the NAS
| fails or network re-convergence occurs. They all fail
| regardless of how many millions one spends and in my
| experience the more millions the more glorious the
| failure that _should never happen_. For some companies
| this is fine if they have the discipline to balance their
| servers across many NAS servers in a strict hierarchy
| that facilitates a smaller predictable POD structure
| blast radius. But that 's a bigger topic than I could
| possibly cover in a HN comment. It also depends on how
| the OS is being used and how writable spaces _tmpfs vs
| disk_ are being used. This will all vary wildly across
| different business models.
| cookiengineer wrote:
| > As a naive outsider: Does RAM in 2023 encrypt all its
| contents?
|
| No. At least not reliably, due to how the keys are stored in
| RAM as well (e.g. when in standby mode, or when a laptop lid is
| just closed).
|
| There's even an EFI reboot flag that could fix this and force-
| clears the RAM on next boot, but it's usually deactivated.
|
| [1] https://en.wikipedia.org/wiki/Cold_boot_attack (works still
| on Windows, thanks to BitLocker)
|
| [2]
| https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...
| rwmj wrote:
| This isn't correct - the key is stored inside the CPU.
| tredre3 wrote:
| AMD offers RAM encryption on their threadripper server CPUs and
| also in their Ryzen PRO on workstation/laptops (you have to
| enable it in the bios).
|
| https://www.amd.com/system/files/documents/amd-memory-guard-...
|
| https://www.amd.com/content/dam/amd/en/documents/epyc-busine...
| latchkey wrote:
| Years ago, I went to AMD and saw this demonstrated live by
| engineers there. They spun up a VM with it turned off and you
| could basically grep a string out of ram. Turning it on, grep
| returned nothing. It was pretty cool. Developed by a bunch of
| true grey beards over the course of many years.
| Cody-99 wrote:
| On consumer Ryzen chips you can enable it too if your
| motherboard supports it. Like error correction code (ECC)
| support on consumer chips it isn't "officially" supported but
| it works. I know MSI and ASUS (IIRC) have the option in bios
| for transparent memory encryption.
| LinuxBender wrote:
| Are these physical servers or VM's? I ask because some VM types
| can be frozen/shapshot/cloned or live replicated _including
| memory contents_ as is done in some VPS providers for lawful
| requests. From the bare metal host anything can be accessed in a
| VM or container. Do they have a diagram of their physical setup?
|
| [Edit] - Are there any Mullvad architects here that can help us
| avoid going down theoretical hypothetical rabbit holes and turtle
| stacks?
| dijit wrote:
| Mullvad has been pushing system transparency a lot (which is a
| security system specifically designed for bare-metal), so it's
| fairly safe to say that it's based on bare-metal.
|
| https://www.system-transparency.org
| LinuxBender wrote:
| _Maybe it should be safe to say?_ but do they actually have a
| diagram of their physical and logical setup that shows they
| use bare metal _only_ and not VM 's or containers? Is that
| documented in audited security controls?
| dijit wrote:
| Such a weird discussion because we're talking about a
| company that is going from the very fundamentals of
| operating system design and the boot process of bare metal
| machines in order to get more security.
|
| It's very antithetical to that goal to add more layers of
| abstraction that could be buggy or reduce security. We're
| talking about motivated and intelligent people purposefully
| trading off convenience for security.
|
| Containers, btw, cannot be snapshotted. So that's a weird
| thing to put into your question.
|
| They've also discussed booting UEFI directly to VPN nodes:
| https://mullvad.net/en/blog/2022/1/12/diskless-
| infrastructur...
|
| It's completely weird to argue that they might introduce a
| layer of insecurity here. Directly goes against everything
| else they're working on.
| kaszanka wrote:
| > Containers, btw, cannot be snapshotted
|
| Why not?
| anonacct37 wrote:
| criu has been used for live migration for a while.
|
| Getting a consistent snapshot that you can restore
| reliably is a hard problem but probably not as big deal
| for forensic analysis.
| LinuxBender wrote:
| _Such a weird discussion because we 're talking about a
| company that is going from the very fundamentals of
| operating system design and the boot process of bare
| metal machines in order to get more security._
|
| I am extra skeptical of a company that pushes this. They
| and I know they can't side step lawful requests which
| raises the spidey senses even further so I believe it is
| a valid question.
|
| _Containers, btw, cannot be snapshotted._
|
| I did not say they could be. Their memory contents
| however can be accessed, even if the host memory is
| encrypted.
|
| _They 've also discussed booting UEFI directly to VPN
| nodes:_
|
| That in no way precludes having VM's. I have run VM's on
| PXE Diskless nodes. The boot method is orthogonal to
| this.
|
| _It 's completely weird to argue that they might
| introduce a layer of insecurity here._
|
| Weird maybe? But completely logical and valid question
| nonetheless. They are leaving 53 characters out of their
| documentation _unless I missed it_. My questions could be
| solved by saying "We do not any form of virtual machines
| or containers". That is only 53 characters and should fit
| on their document site.
| ziddoap wrote:
| > _They and I know they can 't side step lawful requests
| which raises the spidey senses even further so I believe
| it is a valid question._
|
| They have been able to turn down lawful requests
| previously, which is (at the very least) a positive
| indicator that may lower your spidey senses a bit.
|
| > _On April 18 at least six police officers from the
| National Operations Department (NOA) of the Swedish
| Police visited the Mullvad VPN office in Gothenburg with
| a search warrant._
|
| > _After demonstrating that this is indeed how our
| service works and them consulting the prosecutor they
| left without taking anything and without any customer
| information._
|
| https://mullvad.net/en/blog/2023/4/20/mullvad-vpn-was-
| subjec...
| LinuxBender wrote:
| I remember that and that case was cool. I will leave my
| questions in place though because I recall Apple doing
| the same thing when a terrorist phone was locked and they
| claimed to not be able to access _with a big public show
| /fight_ it but turns out they could and so could the FBI.
| My theory is that they did not want the public to lose
| confidence in their phones.
| hathawsh wrote:
| Yeah, that Apple case was really interesting. I always
| guessed that Apple could simply push a software update
| (possibly to everyone) that happens to open a backdoor
| for a specific phone. I wonder if that's what they did.
| asynchronous wrote:
| What happened in that case is the FBI went to a different
| vendor, and they broke into the iPhone either with a zero
| day they had developed or more likely, they just cloned
| the phone hardware thousands of times until they could
| guess the password.
| buildbot wrote:
| Yep, Apple had nothing to do with it. They do hand over
| iCloud data (which now can be E2E)
| buildbot wrote:
| Maybe - depends on how secure enclave is built. It may
| have hardware defined limitations on # of tries for the
| passkey and no way to circumvent that in firmware even.
| theshrike79 wrote:
| Apple would've had to create a specific OS update with a
| security hole the FBI could've exploited and distributed
| that.
|
| Courts couldn't force them to do that -> FBI went another
| way. This was in the iPhone 7 era IIRC.
|
| Currently their stuff is locked down even tighter and
| Apple has even less ability to hack anyone's phone.
| Barring a full-on backdoored software update targeted to
| a specific person - which they refused to do once
| already.
| 10000truths wrote:
| > I am extra skeptical of a company that pushes this.
| They and I know they can't side step lawful requests
| which raises the spidey senses even further so I believe
| it is a valid question.
|
| "Here is a subpoena compelling you to disclose the data
| you have on XYZ."
|
| "Sure. Here is the data we have on XYZ." _hands over
| blank page_
|
| It's not sidestepping the request. They literally do not
| have the data, because they don't retain it. And unless
| there is a specific law mandating that they retain the
| data, law enforcement have no grounds for punitive
| action.
| wolfgang42 wrote:
| _> Containers, btw, cannot be snapshotted._
|
| lxc-snapshot(1), podman-container-checkpoint(1), and
| docker-checkpoint-create(1) all beg to differ.
| rzzzt wrote:
| Some (maybe all) of these are backed by CRIU:
| https://criu.org/Main_Page
| paulddraper wrote:
| Docker at least is
| k8sToGo wrote:
| Physical server can also be frozen (literally) and then data
| extracted from RAM.
| LinuxBender wrote:
| It can but to my knowledge law enforcement _in the US anyway_
| have only done this once _for a national security incident_
| in the real world _outside of a lab_. If you have any links
| to this becoming common practice _outside of a lab demo or
| security presentation on their own hardware_ I would be
| interested to save in my own documentation.
|
| They can also buy cases that have anti-tampering controls
| that force a poweroff if the case is opened but that is
| getting into more costly edge cases. The hardware exists but
| is not datacenter operations friendly. It is also possible to
| force a wipe of ram on a clean shutdown but one must assume
| this won't be. As one example the feds took Mega's servers
| from Equinix after yanking out the cables and out the door
| they went.
|
| [Edit] I should add for completeness sake there are kernel
| boot options to clear memory space before allocation and
| after de-allocation _with a performance hit_. Both are
| enabled by default on modern kernels now.
| init_on_alloc=1 init_on_free=1
| mschuster91 wrote:
| There exist special UPSes that you can attach to a power
| line of a server, unplug and unmount it, and keep the
| server powered all the time, without the server being able
| to detect that.
|
| If you are really serious about security, you need to have
| a watchdog on network link downtimes because, no matter
| what, you can't disrupt a fiber optic network link without
| the server noticing.
| tln wrote:
| Whoa! Any keyword suggestions to find those UPSes?
| Eldt wrote:
| I'm having trouble remembering what they're called, but I
| do remember reading about these. I saw a demonstration
| where they slightly pulled at the desktop power plug in
| order to hook a thin device around the plug connectors to
| provide power, and then they could transport the desktop
| around.
| kl4m wrote:
| It becomes way more straightforward if it's a server with
| redundant power supplies.
| tuetuopay wrote:
| Actually not because a server with multiple PSUs
| definitely knows when one loses power. It's made to raise
| alerts about a power rail failing. So this makes it
| harder because you need to keep power on both to not
| raise any alarm
| rwmj wrote:
| For laptops, law enforcement use "mouse jigglers" to
| prevent screen locks and laptops going to sleep, which I
| guess is similar. Random article:
| https://www.electronicproducts.com/what-is-a-mouse-
| jiggler-a...
| fmajid wrote:
| https://wiebetech.com/products/hotplug-field-kit/
| 0cf8612b2e1e wrote:
| Just like Seinfeld and saving the Frogger high score.
| greentea23 wrote:
| Are there any known examples of this actually being done by
| law enforcement or government and working?
| ziddoap wrote:
| There are plenty of examples of it working (e.g.
| researchers from F-Secure presented at SEC-T conference in
| 2018 with a cold-boot against Bitlocker), but I haven't
| seen a LEA or government come out and say "we got access to
| X via a cold-boot attack".
| 0cf8612b2e1e wrote:
| As RAM densities/speed increase, I wonder if this is
| still viable. DDR5 had to mandate some baseline ECC given
| the intrinsic error rate.
| adrian_b wrote:
| That is why modern servers have the option to encrypt the
| DRAM to prevent this attack.
|
| Moreover, there is also the option to have distinct randomly-
| generated keys for each virtual machine, to make useless the
| speculative attacks that succeed to peek at the memory of
| another VM.
|
| AMD has offered these options for years and the future Intel
| CPUs will also have them.
| xyst wrote:
| good ole can of air compressor flipped upside down and quick
| hands trick
| WirelessGigabit wrote:
| One can fix that by deploying software with the VM pause
| functionality removed and / or remove disks the bare-metal
| servers and only PXE-boot them. That way there is nothing to
| pause.
| xyst wrote:
| If you are asking this, you probably need to self host your VPN
| LinuxBender wrote:
| I do this but I do not use them for privacy. I use Tinc [1]
| to route around internet outages as it can do user-space
| dynamic mesh routing. Since they are all nodes I pay for they
| would not hide who I am. While I do control the logging of
| Tinc I do not control external logging of the server and VPS
| providers.
|
| For privacy I might theoretically use Tor but most sites
| block or grief people on that network. Tor exit nodes share
| some risks that of public WiFi.
|
| [1] - https://www.tinc-vpn.org/
| LinuxBender wrote:
| The more I think about this VM's are not required. There are
| tools that can extract data streams based on specific
| parameters on demand using eBPF. Perhaps tools like
| Sysdig/Falco, etc... It might also be useful to know if they
| custom compile kernels to disable eBPF and if they do any
| additional specific kernel hardening to strip out or disable on
| demand debugging capabilities.
| deknos wrote:
| they should at least opensource their implementation. they may
| have errors there. should we just trust everything?
| dewey wrote:
| Why the entitled attitude? They do a lot of open source
| contributions already so maybe just give them some time instead
| of immediately disregarding the whole improvement? Small steps
| into the right direction.
|
| https://mullvad.net/en/help/open-source
| zlg_codes wrote:
| Making a suggestion isn't entitlement. Maybe reconsider the
| foul void that accusation came from.
| dewey wrote:
| If someone suggests something to me they usually don't say
| "you should at least". This sounded more like an entitled
| comment you see every day on open source repositories and
| making it sometimes not fun to be an open source
| maintainer.
| k8sToGo wrote:
| Pretty sure they have been audited recently.
| dewey wrote:
| Indeed: https://mullvad.net/en/blog/tag/system-transparency
| willis936 wrote:
| If I were a Mullvad customer this is what I would want:
| regular audits and closed source until everyone was convinced
| the code was bulletproof.
| carlhjerpe wrote:
| Their infrastructure kind of is their USP. It'd be like giving
| their competition their work for free. And it's not about
| absolute trust, it's about trusting them more than your ISP and
| other VPN providers. You still have TLS over Mullvad
| yjftsjthsd-h wrote:
| I'd argue that Mullvad's USP/moat is their reputation, far
| more than the software they run.
| lopkeny12ko wrote:
| I don't understand this. Don't all Linux processes "run in RAM"?
| It sounds like what they have _actually_ accomplished here is
| eliminate all disk I /O requirements from their DNS service, i.e.
| it works against a read-only mounted root filesystem now. That's
| not really the same as "running in RAM".
| ziddoap wrote:
| > _In early 2022 we announced the beginning of our migration to
| using diskless infrastructure with our bootloader known as
| "stboot"._
|
| > _We recently announced the completion of our migration to
| remove all traces of disks in use on our VPN infrastructure._
|
| Is this more clear?
| oxygen_crisis wrote:
| Once they have everything running in RAM, they can have racks
| of servers that contain no persistent storage whatsoever, and
| are therefore subpoena-proof.
|
| > _On April 18 [2023] at least six police officers from the
| National Operations Department (NOA) of the Swedish Police
| visited the Mullvad VPN office in Gothenburg with a search
| warrant. They intended to seize computers with customer data._
|
| > _In line with our policies such customer data did not exist.
| We argued they had no reason to expect to find what they were
| looking for and any seizures would therefore be illegal under
| Swedish law. After demonstrating that this is indeed how our
| service works and them consulting the prosecutor they left
| without taking anything and without any customer information._
|
| https://mullvad.net/en/blog/2023/4/20/mullvad-vpn-was-subjec...
| 8organicbits wrote:
| > contain no persistent storage whatsoever, and are therefore
| subpoena-proof.
|
| Nonsense. The linked post shows that they didn't have the
| sought information. If the information was present in RAM,
| they'd just read it from RAM.
| itslennysfault wrote:
| I assume they only hold what the server is doing in any
| given moment in ram and it is overwritten as new requests
| come in. By the time the police showed up with the subpoena
| the data they wanted was long gone.
| theshrike79 wrote:
| [delayed]
| Etheryte wrote:
| This is not what's happening here. The systems don't have a
| disk, period. The bootloader downloads an OS image from a
| provisioning server into RAM that's verified and then run. Past
| the bootloader, the system doesn't have access to the
| provisioning server. Every program the server needs or may need
| to run at one point is already in memory. Outside of RAM there
| is nowhere to read more data from, not even a read-only disk,
| nor anywhere to write it to.
| ignoramous wrote:
| If one is already running only "verified" (attested) code
| (with a read-only partition), diskless doesn't buy you much?
| Android, for example, does this: The _system_ partition where
| the OS is remains immutable unless there 's a signed update
| (or the bootloader is "unlocked").
| ziddoap wrote:
| They briefly explain some of the reasoning here:
| https://mullvad.net/en/blog/2022/1/12/diskless-
| infrastructur...
|
| > _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._
| yjftsjthsd-h wrote:
| Yeah, I don't have their opsec concerns but I'm very
| tempted to try implementing something similar just to
| enforce having a stateless system (easier to manage IMO)
| with a nice bonus of no longer caring about host disk
| failures.
| lopkeny12ko wrote:
| This seems like a very roundabout and unnecessary solution to
| a problem that is already solved with tmpfs.
| drexlspivey wrote:
| In such a setup where does the key to verify the image come
| from?
| j-bos wrote:
| Does anyone know how Mullvad vpn security compares with Proton
| vpn?
| drexlspivey wrote:
| "In April 2019, upon the order of the Swiss judiciary in a case
| of clear criminal conduct, we enabled IP logging against a
| specific user account which is engaged in illegal activities
| which contravene Swiss law. Pursuant to Swiss law, the user in
| question will also be notified and afforded the opportunity to
| defend against this in court before the data can be used in
| criminal proceedings"
| ziddoap wrote:
| A quote with no context or attribution always makes it fun to
| figure out what someone intends to say with their comment.
|
| This quote is in reference to ProtonMail in 2019, a fairly
| widely reported on case at the time.
|
| This would be a point in favor of Mullvad, as Mullvad has
| demonstrably squashed a subpoena in the past, thanks to their
| data-minimization policies (no PII for signup, no PII options
| for payment, diskless infrastructure, etc.).
|
| Note that this is more related to _privacy_ , and not as much
| _security_. If the parent comment was specifically talking
| about security, I would recommend reviewing the software and
| infrastructure audits made available by either company. I 'm
| not aware of any major fault with either, from a security
| perspective.
| woofcat wrote:
| Who is this in reference to? What is the source? Googling for
| the quote you gave doesn't have great results.
| ziddoap wrote:
| See my comment above, but it is in reference to ProtonMail.
|
| You can find many articles about it (search "Protonmail
| subpoena 2019"), but an example article is here:
| https://www.privacyaffairs.com/protonmail-surrenders-user-
| lo...
|
| ProtonMail's own blog post about it is here:
| https://proton.me/blog/climate-activist-arrest
| drexlspivey wrote:
| It's from Protonmail's website https://web.archive.org/web/
| 20190425155330/https://protonmai...
| theshrike79 wrote:
| [delayed]
| naet wrote:
| I was extremely happy with everything mullvad was doing until
| they announced they were discontinuing port forwarding, which is
| important to a niche part of my setup. I understand the
| reasoning, but if it came back ever I would again happily be a
| customer.
| rbut wrote:
| I use Cloudflare's DoH DNS (https://1.1.1.1) and tunnel that over
| Mullvad's VPN.
|
| That way Mullvad can only see the IPs I visit, Cloudflare only
| see DNS requests coming from the VPN IP, and my ISP sees nothing.
|
| Mullvad's DoH DNS seems nice, but it provides potentially less
| privacy than the above, so I won't be using it.
| ThePowerOfFuet wrote:
| >That way Mullvad can only see the IPs I visit,
|
| I hate to break it to you, but if they wanted to look at the
| SNI on all your TLS connections, they could; ECH is not really
| a thing yet.
| rbut wrote:
| Yes you're correct if Mullvad is performing packet inspection
| then there isn't much I can do about that.
|
| My point stands though about not putting all eggs in the one
| basket and using a different DNS provider than that of the
| VPN provider.
| herpderperator wrote:
| > Today we can announce more steps forward - our Encrypted DNS
| service has also been converted to run from RAM!
|
| Where exactly do services run from if not RAM? The post is very
| plain with no explanation of what "running from RAM" means. When
| you execute any binary it gets loaded into RAM as per standard
| operating system procedures...?
| 10000truths wrote:
| They mean diskless. There's no persistent storage attached to
| the machines that run the DNS servers, because the entire
| operating system is loaded into RAM directly from PXE boot. So,
| if the hardware ever gets seized by law enforcement or rogue
| actors, there is no risk of exfiltration of private user data.
___________________________________________________________________
(page generated 2023-11-10 23:00 UTC)