Hacker News Reader

Comment by kfreds | Hacker News Reader

I’m the author of the article. Currently on my phone, but feel free to ask questions and I’ll answer as I’m able.

Not really a question about the article, but just a thought/recommendation.

Every now and then I check the Mullvad blog to see if any new servers have been added, or features I should know about, etc etc. In essence, things that pertain to me as an end user. Stories like this, or new servers, WireGuard being added, etc.

I always thought it would be cool to see some sort of article or blog post with a 2019/2020 road map, however. Just so I can see things that are upcoming or know what’s being worked towards. With VPN services, sometimes it feels kind of stagnant, as the only appreciable updates are new servers or new features. Plus, since I don’t use the Mullvad app itself, updates to it don’t really pertain to me all that much.

Idk, I’m rambling, just food for thought. A roadmap blog post would be cool imo.

Well worth considering. Thanks! The best I can offer at the moment are our yearly review posts, but those are obviously written after the fact: https://mullvad.net/en/blog/2018/12/19/final-glance-year-app...

I meant to ask this by mail but I might as well ask here:

Many other VPNs have opted for not yet adopting Wireguard since they claim it's currently difficult or impossible to offer the same privacy guarantees, and also due to the unaudited/new nature of the code base.

Mullvad has offered Wireguard for a while though, and without any warnings about this topic. Has Mullvad found a way to provide similar guarantess?

Or is there another reason why Mullvad does not see this as a problem while other providers do?

Hi! Thanks for the question. It's an important one. Both the security of WireGuard as a protocol as well as its Linux kernel implementation are most likely superior to all alternatives. Code audits and age of the project function as signals for decision makers, but there are stronger signals, if you look deeper. The simplicity of the protocol state machine, the fact that it can be implemented without dynamic memory allocation, the cryptographic primitives used, and the lines of code required, are arguably equally or more useful. WireGuard is 4000 LOC, IPSec is 400,000 LOC and OpenVPN is of similar complexity. I don't expect Jason Donenfeld who has a background in kernel exploit development to write code that contains 100x more vulnerabilities than IPSec and OpenVPN. We have noted the prevalence of those arguments. Let's wait a while and see who was right.

As for the privacy issues with a "standard" WireGuard deployment we are well aware of them and are working with others to develop a standard which will hopefully be adopted by privacy-focused operators. Unfortunately we only highlighted them to others in January this year. Note that no criticism of WireGuard's privacy seems to be older than this email: https://lists.zx2c4.com/pipermail/wireguard/2019-January/003...

We have deployed solutions for some of WireGuard's privacy issues while others are in the pipeline. It should however be noted that some of the attack vectors are somewhat esoteric and quite unlikely, so we don't consider them critical. The devil is in the details, as you can read in my email above. On the whole we think WireGuard is where the industry should be heading, fast, for many reasons, and that's why we are spearheading it: https://mullvad.net/en/blog/2017/9/27/wireguard-future/

At the moment IVPN is slightly ahead of us in terms of privacy features in WireGuard, but they are the provider we probably have most in common with, and we frequently discuss projects like this one, so they are definitely the one we most expect competition and collaboration from: https://www.ivpn.net/knowledgebase/253/Using-WireGuard-for-P...

While wireguard is probably safer and easier to setup, it has its own idiosyncrasies. Jason is stubborn enough to push through on creating a vpn, but also stubborn enough to see things his own way. I'm still wary of using it, not sure what will become of it.

It has idiosyncrasies like:

* Jason refuses to implement or see point of binding to an ip/address. I do not know of a serious network service that cannot bind. I guess roaming to any interface is always the right thing to do and sharing a port number for separate services on separate ips should be done via NAT.

* If you assign an ip/route to a peer, that is already assigned to another peer, previous assignment is simply removed. Somehow, this is a feature and not a blunder >95% of the time. On a security product, it's better to keep going and load a kind of obviously wrong config, discarding conflicting assignments, than to raise an error. Or even a warning (a warning is/was planned).

* on Windows Jason invented tying network id to hash of entire key+address configuration. Cool idea, but I guess you're supposed to fiddle with firewall settings each time you change any peer key/ip, because it's now a new network.

* wireguard is marketed as a modern secure VPN. It has proofs and what not, but I haven't seen a specification of what are it's security guarantees. It (obviously) leaks packet size and timing, also ecn bits, maybe server time? Does it leak public keys, dscp markings? I guess you're supposed to read the whitepaper, maybe source code and keep an eye for any changes.

> WireGuard is 4000 LOC, IPSec is 400,000 LOC and OpenVPN is of similar complexity.

Bollocks.

  $ cat netinet/ip_ah.c netinet/ip_ecn.c \
  netinet/ip_esp.c netinet/ip_ipsp.c netinet/ip_spd.c \ 
  netinet/ipsec_input.c netinet/ipsec_output.c | wc -l
  6445

You're comparing apples and oranges. Most critics implicitly count IKE and other PKI-related bits as part of IPSec. But Wireguard doesn't offer anything comparable. So if you want to compare apples & apples, you can only compare the actual transport layer. Wireguard is still more elegant, but of course Wireguard has the benefit of hindsight and IPSec has 20+ years of operational fixes.

What's happening is that because Wireguard doesn't include PKI people end up gluing together poor man's PKI with shell scripts and shoe strings. PKI is the hard part of key management, and because Wireguard doesn't attempt to solve it, it doesn't incur any of those costs. And the people who do try to solve it and get it horrible wrong, well I guess that's just not Wireguard's fault, right? How convenient.

Hey kfreds, great job first and foremost! You’re definitely working on some great stuff. In the world of VPN, it’s great to see another being innovative too.

We (Private Internet Access) are working on something similar called zero access. In response to your call to collaborate with other VPN providers, I would love to get on the phone with you to trade notes.

My contact info is on my profile here! Hopefully looking forward to it!

Hi Andrew! Thank you. I definitely took notice when PIA followed our lead and decided to donate to WireGuard as well. I suspect that was your initiative?

As far as innovation goes we published our vision for the VPN industry a few months ago. It's transparent and independently auditable VPN servers, through the use of System Transparency: https://mullvad.net/en/blog/2019/6/3/system-transparency-fut...

If you are interested in it you are more than welcome to join the implementation effort when we have put some basic things in place, or do your own thing right away. Above all it's important that we start moving in that direction as an industry. We don't really care who gets there first. It is also a more interesting game than the currently dominating one of affiliate marketing using hyperbolical and unverifiable security claims.

In a few weeks I will do a talk at the Open Source Firmware Conference together with our technology partner 9eSec ( https://9esec.io/ ), which will coincide with publishing a website as well as more planning of the implementation effort. As far as collaboration goes I have discussed System Transparency at length with IVPN many times, whose values and vision I find very well aligned with Mullvad's. We have an ongoing conversation with them about this and other things.

Thanks for the invite to chat, I agree it doesn't hurt to have a one-on-one talk. Even if Mullvad and PIA doesn't turn out to be a good fit for collaboration we should definitely share ideas on our vision for the VPN services market. Our perspective is pretty much all in the blog post about System Transparency. Looking forward to reading more about your idea "zero access". I'll reach out soon!

Amazing! Definitely, we think WireGuard is something that needs to happen, and we're happy to support it.

We are absolutely interested in joining in the implementation effort and likely have a lot of research/code to bring forth. I agree, that security theater is a joke xD

Looking forward to hearing from you, Andrew

I like to cheer on any company working towards transparent systems and privacy-first technology, but Mullvad has a special place in my heart for always being on the front line. Thanks for the article.

Thank you for the recognition! If you haven't read our blog post about System Transparency as a vision for more transparent and trustworthy computing I think you would enjoy it: https://mullvad.net/en/blog/2019/6/3/system-transparency-fut...

Architectural question: why are people fighting to drag x86 unwillingly into the open space rather than taking something open (ARM, MIPS, anything else) and bringing it up the security curve?

Crypto and VPN seem like ideal points to basically put a fork in x86 since they are not dependent upon raw CPU performance. It would seem that fracturing the x86 world by picking off individual use cases until x86 has very little left would be the best option (ie. exactly what x86 did to mainframes).

> This is the first time a modern off-the-shelf server platform gains coreboot support, and it is an integral part of realizing our vision of transparent and independently auditable VPN servers.

Important work. Could you share more about your envisioned OSS toolchain for independent auditing of servers? What were the factors which lead to choosing this board, e.g. could other VPN providers contribute resources for extending this coreboot port to a newer chipset?

Sure! coreboot + LinuxBoot (with u-root) in the integrity-protected SPI flash memory, which then netboots (download and kexec) a Linux system. All artifacts need to be reproducible. For the CT Log probably trillian.

As for choosing this board, I alluded to it in a post down below. Note that I'm not a firmware expert though. Support for x86 was obviously already there, as well as for the microarch if I recall correctly, so "all" our technology partner 9eSec ( https://9esec.io ) had to do was support the specific board. Had we chosen another microarch or something with multiple CPUs we could have spent months on it. Just another example of how important it is to work with experts.

You should definitely consider putting out a song like the Open Firmware song :-)

http://people.linaro.org/~rob.herring/openfirmware/1275/home... (look for 'song' there)

How much work do you think it would be to support open firmware in other Supermicro motherboards?

This port took roughly two-three weeks of full time work by an experienced firmware developer.

I'm not a firmware expert so take the following with a grain of salt. In general the more your target platform has in common with currently supported mainboards the easier it will be. First of all there obviously needs to be support for the instruction set architecture, then the CPU microarchitecture, and finally for the components on the specific mainboard you are targeting.

Given what has now been done by 9elements and others for SuperMicro boards based on Kabylake I expect more boards to be ported in the coming year.

As kfreds correctly states, there are important questions other than who the OEM for a mainboard is. With the exception of notebooks (where OEM specific components like the embedded controller require a fair bit of work that can be transferred from one device to the next), I'd even say that the OEM is among the least interesting bits about a mainboard on the technology side.

However, if the OEM supports the coreboot port (e.g. by providing schematics and generally answering questions that come up) that's very helpful.

So, question to kfreds: how was the cooperation with Supermicro? Are they aware of your effort, were they helpful?

(disclosure: doing coreboot development for 12 years now, some of that professionally, now for Google's Chrome OS devices)

Hi Patrick! I unfortunately don’t recall the details. If you’re interested reach out to Philipp at 9eSec.

Reply on news.ycombinator.com