ExpressVPN open-sources Lightway: a modern VPN protocol | Hacker News Reader

ExpressVPN open-sources Lightway: a modern VPN protocol

github.com

37 pointsvladaionescu13 comments

I don't love the code style in terms of indentation, line length, alignment and bracket placing but IMO at least it doesn't look childish / reckless.

I think there could be bug in he_internal_send_auth_userpass when it copies the strings because when calculating the string lengths it uses the size of he_conn->username and he_conn->password which are "HE_CONFIG_TEXT_FIELD_LENGTH +1" whereas the sizes of the destination fields in he_msg_auth_t are "HE_CONFIG_TEXT_FIELD_LENGTH" so .

Take it with a grain of salt, I just took a very quick look mostly to see if I liked the coding style and it's far too early for my brain to be functional but it seemed that way to me. Other than that I didn't hate the code which is cool!

Thanks for opening it!

Disclaimer: I'm an employee of ExpressVPN and work on this codebase.

The specific reason for the size disparity is that we require he_conn->{username,password} to be null-terminated, whereas we do NOT require he_msg_auth->{username,password} to be null-terminated. I remember raising the same point and being convinced that we had a good reason for doing so, but I also haven't had enough coffee to remember what the good reason was!

Regardless of whether this is a "bug" or not I do think that the disparity points to something that unnecessarily causes confusion, will have a think about making it more consistent.

Regarding style -- I also ~hate if(x==0) without the space after the if but we committed to consistency instead of arguing over it via clang-format. To quote Rob Pike, "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."

Sorry about the late reply, I didn't realize there was a reply to my message. I reviewed it once again and can attest that what you say is correct, so that's cool.

Thanks for taking the time to reply!

Seems to miss a very important part: comparison to other VPN protocols.

In particular, I wonder why they made all new protocol instead of adding a nice wrapper over Wireguard.

A core reason for creating Lightway was the need for a VPN protocol that was designed for all the things that a privacy focused, high performance VPN platform needs. Unlike Wireguard, Lightway does not need a wrapper, it provides these features out of the box for everyone.

Wireguard is a great VPN protocol, but it was designed for a very different use case.

Edit: My apologies, I should have first introduced myself as the creator of Lightway at ExpressVPN :)

To be honest, I’m pretty familiar with the top VPN providers and I’ve never heard of ExpressVPN. When I Google it, I immediately receive so many explicit ads for your service and a bunch of obviously promoted blog posts comparing garbage VPNs to your service. Creating a VPN protocol from scratch is ambitious and going to take some pretty heavy hitters to join and contribute to this protocol to gain trust in a pretty guarded community.. maybe that isn’t your intended customer though.

You say WireGuard was designed “for a different use case”.. that’s an extremely cryptic (buh dum tiss) thing to say. Do you seriously envision Mullvad or other VPN service providers adopting your protocol? At face value, I will conjecture and come from pessimistic point-of-view: this more of a niche feature of your product, appealing to a type of techy mindset where shiny new tools are somehow better.. which is playing with fire when it comes to encryption for privacy..

For anyone reading this, don’t listen to anyone here. Just go to https://privacytools.io and use those providers.

I would love to see Lightcore and ExpressVPN listed on that site someday.. good luck

Native Wireguard ties keys to specific internal IP addresses or ranges. This is not an issue for many use cases such as between friends for gaming or by a business to connect remote users to their corporate network. There's no inherent security issue here.

However, this is undesirable for a VPN provider that has a focus on preserving privacy. In this case you want users to get a new IP address each time they connect so that there is nothing in common across connections. This matters to us and so Lightway has this as a core design feature. To get that in Wireguard, an additional layer needs to be added.

I certainly believe that Lightway could be an excellent alternative for any provider who doesn't want (or isn't able) to implement Wireguard. Lightway is Open Source and it has had a full security audit that has been publicly released. Other providers are most welcome to look at Lightway and decide for themselves whether they think it offers them anything of value.

ExpressVPN is a very well known VPN service IMO. I've certainly heard of it from several people, and seen it often in lists of VPN recommendations. Can't speak to the other points you raise, but ExpressVPN is certainly a known company in the field...

I would love to see some benchmarks comparing lightway to Wireguard, OpenVPN and other protocols added to the repo. Specially on Battery usage while idle and Performance over a unstable connection.

Also I don't really get this? This to be looks like just the core library that details the protocol and nothing else around it.

Like this is really just wolfSSL + wire format. You'd still have to write the code for getting the data to the server (Handle all retransmission and other stuff), write clients (possibly kernel modules for layer 3 performance) for all major OS, write a server to handle traffic forwarding. And if you're doing all that, one might as well make their own format. Are there plans to release the other parts separately?

We have released a reference implementation that uses Lightway Core to create both a client and a server. It can be found here:

https://github.com/expressvpn/lightway-laser

Lightway Core is designed specifically to be embeddable and to work well on any platform without making assumptions about how that platform works (i.e. OpenVPN assumes a tun-like device).

The comparison to WolfSSL is a good one because it was inspired by their library's design. As WolfSSL is to SSL, Lightway Core is to VPN tunnels. Just like WolfSSL, how you use Lightway Core is really up to you.

For example, if you wanted to create a VPN that connects over Google Sheets or uses DNS messages, you’d be able to do that easily with Lightway Core.

I wasn't able to find any comparison to WireGuard, but I did notice that a CLA must be signed before contributing to Lightway.

No CLA needs to be signed to contribute to WireGuard.

I'm more than happy to answer any questions you might have about Lightway vs Wireguard.

The reason we have a CLA is that we want to be upfront and transparent about what happens when someone contributes code to the project. It is important to note that the author maintains ownership of their contribution at all times and that we will immediately release the contribution under the GPL 2.0 license. This helps to protect the project by ensuring that any code in the repository can be released under the GPL 2.0 license both now and in the future. This is why the Apache Foundation requires a CLA for all contributions - the intent is to protect everyone's interests.

As part of any code contribution, we will list the author's name and what was contributed so that the author will get full recognition for their work.

[Off topic] What are available options are best practices for CTO/VP Engg leaders to build efficient and secure developer access ? We use OpenVPN but it's not most easiest one to build fine grained controls

Reply on news.ycombinator.com