 Hey everyone. So I'm Pete Membrune from ExpressVPN and I'm really, really excited to get to talk to you guys about Lightway. We've had a lot of discussions over the last few days. A lot of people through the booth have been really, really, really nice. But wanted to give a chance to explain why we did this and the reasons behind it. And so obvious question, why do we make Lightway, right? There were some very well-known protocols out there. Okay, we have OpenVPN and of course we have the new and shiny WireGuard. So why did we go and create a new VPN protocol? Why didn't we just join and work with other open source projects? What was the reasoning for this? Well, OpenVPN has a lot of pros to it, right? It's been around for very, very long time. It's been audited. It's well-known. People would recognize the name, they'd understand it. And for the longest time, it was our preferred protocol. Nothing wrong with that. The challenge though is OpenVPN was really created in a different era. It was designed for the days when your PC would be a box on a desk. You'd have a cable going to it. And that was pretty much as complicated as your networking environment got. And relatively speaking, speeds are much slower then. The demands on a VPN were significantly less. It expects to run as a binary. That might seem like an odd thing to point out. But if you wanted to get this into, say, an iOS app or you wanted to get it into an Android app, there was some surgery involved. And it wasn't really designed with that in mind, understandably. And there's relatively limited ways to interact with it. If you want to control it as a binary, if you want to start, stop, and get status information from it, that's more difficult to do. It does have some support for this, but you don't get full access. A lot of the time, you would need to, for example, look at logs and stuff like that. But of course, WireGuard. Why not WireGuard? Well, again, lots of pros for WireGuard. It's a super simple implementation. It's super fast. It's very easy to set up. I think to say that it has a lot of momentum behind it would be selling it short. It has a lot of momentum. There are some cons to it, though. And I should preface this by saying, when I talk about cons here, I mean them from the perspective of ExpressVPN and what we're building and what we need out of a VPN. So with WireGuard, all your keys must be pre-shared among all your endpoints. That's fine if you have a small number of people that you're trying to hook this up to. When you have many thousands of servers and you have millions of clients connecting to it, pre-sharing keys is undesirable. Now, of course, you can build infrastructure to do this, but now you have to build and maintain the infrastructure and do all the work involved in looking after that. And, well, that takes you away from actually focusing on the VPN part, which is the part where you're going to be actually hopefully adding value. The keys are also bound to IP addresses. That's how you authorize keys to connect through and use the API of WireGuard. And we're very privacy focused. We don't want to have this particular key is tied to this particular IP address. Of course, the simplest way that you could pre-share all your keys would mean the same IP, the same key shared everywhere. That's undesirable for us because, again, it links those things too closely together. Could you make a system that does it differently so it's different per connection? Sure, absolutely. But now you need to build and maintain that as well. The WireGuard project has no interest in TCP support. They list this on the limitations page and they have a very good reason for it. Generally speaking, VPNs like TCP over TCP sucks. It's not a great day out. Nobody likes it. It makes perfect sense they don't support it. But for us, we have a very, very large amount of users that are in using networks that don't have UDP. Think public government Wi-Fi. Think, you know, internet on a plane, coffee shops, you know, businesses running deep packet inspection, that sort of thing. In these environments, if you don't have UDP, and it doesn't matter how great UDP is, you cannot use it. If you want to support those users, you must then provide a fallback, which, possibly ironically, is usually open VPN. They also have no interest in DPI avoidance. Their feeling is that, well, that should be done at a different layer from the VPN. They want to focus on the core VPN parts. Again, that makes perfect sense. But for us, we have a lot of users in those sorts of environments where they're dealing with corporate firewalls. They're dealing with various different networking restrictions. And so for us, we really need to have things like obfuscation that's directly and easy to integrate into our protocol. Something that, sorry, Wargo wasn't interested in. So these are all things that, even if we put work and time and effort into them, we tried to upstream them, we wouldn't really have a receptive audience because we're just not building this the way that, you know, they're looking for. So how do we make lightway? Lightway was built with a mobile first sign. So one of, we've probably heard this a lot with things like web design. But when we were putting this together, designing for mobile or embedded systems first was really key for us. We have a lot of people who are using low-powered Android devices or otherwise like embedded routers and things like that. Mobile devices have a very different set of problems. They generally have limited power. They generally have limited CPU. And they have very interesting network configurations. One minute you're on Wi-Fi, then you're on to 5G. Now you're back to 4G, back to 5G again. If you can handle these things nicely on mobile, when you then go to run this on, say, desktop, it's just going to work nicely for you. Trying to go the other way can be very complicated. So a guy called, these are Ams, I'm not sure if you guys have ever heard of him. He was a big inspiration for Jonathan and I at Apple. I don't like reading off-slides, but bear with me. I'm going to do it here. So everything interacts and is dependent on other things. We must think more thoroughly about what we are doing, how we are doing it, and why we are doing it. And that really was the main driving force for our work on doing mobile first, how we balance all these different things together so that we get something that's very valuable and useful for people at the other end. So that's really where we're going with the mobile design aspect, trying to keep all of these things in mind. We'll touch on some more of these as we kind of go through, but that's the general gist and direction that we were taking. So what really is lightweight? We've got this far. We haven't really talked about it much, but this is actually a picture taken from near my hometown, Plymouth. It's on Dartmoor. It's to represent the blue sky green fields, the approach that we were able to take. This is probably one of the only three days you might have got a blue sky anywhere near my hometown. Anyone who's been on Dartmoor knows it's usually grey and miserable, so it took quite a while to find this. Basically, we had this rare opportunity, and it was, well, if we had a big enough magic one, what would we do? We have a lot of experience building and running these things. If none of the existing things are a good fit for us, what would we create instead? What if we could just pick something? What would it be? So one of the questions I get is, well, why not WireGuard? Why don't you like WireGuard? I love WireGuard. It's great. I use it myself. And to say that Lightway was inspired by WireGuard is a very true statement. I think everyone will agree that when WireGuard first came out, it blew people's minds. No one really knew that VPNs could look like this, and it changed how people started viewing VPNs as a technology. That's all we really wanted, that sort of stuff. There's lots about WireGuard that we really, really wanted. However, it's also grounded very much by OpenVPN. We have over a decade of running a platform with OpenVPN. We like how the binary runs. We like how the connections work, how authentication works, how network assignments work. There's a lot of stuff that we'd learned running this that we were really happy with and really wanted to keep. One of the key things, Lightway is secured by Wolf SSL. I won't go into too much detail on the reasons why we picked it, but we did go through a whole host of different libraries before picking Wolf. But the key reason I mentioned it here is we did not roll our own crypto. So Wolf provides all the cryptography and the connection security for Lightway. None of that is implemented by us. And Wolf themselves have actually verified and confirmed that the implementation that we've used and how we've used a library is correct. And engineered by ExpressVPN, this I'm putting in there because we designed it to do very much what we wanted it to do. It's very opinionated, right? Like a lot of software, this was designed to solve our pain points. And chances are it will solve a lot of other people's pain points as well. But this deliberately fixes problems that we cared about. And we designed it with that in mind. So Lightway really is a mobile first open source VPN protocol. It's open source under the GPL v2. It emphasizes simplicity, security, privacy, and performance. That's really what we were trying to do with it. So what does it offer? Well, it's fast. Realize that's a very iffy thing to give without numbers. Everything is relative. But even in our basic builds that we're clocking, well over line speed for gigabit connections, it's power efficient. Lightway doesn't really do much of anything. If you're not passing traffic through it, Lightway is basically inert and on purpose. So things like sending heartbeats by default, Lightway doesn't do that because that would wake up your phone, that would draw battery, draw CPU, again, turns on the radio, more power, more CPU. We try to do as little as we possibly can there. And we're also using Wolf's hardware acceleration. So again, we're using less instructions and getting better power efficiency that way. It has first class support for TCP. Again, for lots of people, this is an irrelevant feature for us. It was absolutely critical. And so Lightway supports TCP just as well as it does UDP. It was designed to support easy extension. This is so that you can easily add things around the tunnel and also things through the tunnel. And this is because doing that with open VPN is quite difficult. You're not supposed to do that. But it's something that I need to do in my role. So I wanted to make sure that it was simple to extend. As a very simple code base, the first version we released publicly under the GPL was just under 2,000 lines of code. So it's quite a simple code base. People say, oh, the one code base is so simple, you could audit it yourself in a few days. While Lightway is so simple, you could probably audit it on a live YouTube stream. It's really that simple. Most of it is getting and setting in terms of the code itself. A big focus on privacy and the ideals there, so the ability to mask IP addresses from the client itself. This means that if you did have someone looking over someone's shoulder or looking at log files and things like that, you wouldn't really have to be concerned about trying to obfuscate it because the IP address doesn't actually have any real identification value. Everyone else on that system would have the same one. So where's Lightway today? It's been around three years carrying real world traffic. It protects around 4 million people around the world. So far this year, it's handled over 11 billion individual connections. We've transferred, on average, just over an exabyte of traffic so far. Also, it's independently audited by QA53. So once when we open sourced it and went live, and again quite recently, so again, we're keeping up the public quality of the protocol. This is just a very quick comparison to OpenVPN. Again, this is because this is what we were running and these values are relative, but if you've ever tried doing speed tests or performance testing, you know as well as I do that just spewing out numbers is not particularly helpful, but compared to users who had been using OpenVPN, people were experiencing twice as fast connection times. Reliability was improved by 40%, so connections were longer lived, and we're basically seeing double speeds on average across all users. So for Lightway tomorrow, while what currently is written in ANCC, we are making a big push to move this to Rust. Somebody's happy, and this is for all the reasons that you can probably imagine. Three years ago when I put this down, we were looking to support again those really embedded niche devices, and the Rust compiler wasn't there yet. It just wasn't going to do the job. That's no longer the case, and I think most of you probably know that Rust has moved on massively in three years. We are very excited about taking advantage of things like the memory safety, the borrower checker, performance, the much simpler code, and modern toolchain and things like hash maps being available out of the box is quite a nice thing too. We're also moving quickly to implement the post quantum protection. This is something that's been talked about a lot quite recently. It was a big topic of the real world crypto conference a couple of weeks ago, and to do with right now, we're seeing this save now decrypt later that even large companies are now doing, with the idea being that in about 10, 15 years, quantum computing will be at the stage where they can basically unzip the encrypted data that they're storing today. I can go into more deals later in the Q&A if anyone's interested, but the short version is the post quantum protection that we're looking to roll out will help protect against that particular threat. Also, we're improving open source reference clients. We have one right now. It's not great. It did the job, but it's not something that people would generally be able to run as their own server, their own client. We're revamping and improving that so that you can use it ultimately as a drop-in replacement for open VPN. We're hoping to get it packaged into distributions and things like that. Lastly, your community outreach and engagement. Part of the reason why I'm here today, and why we've been here the last few days, just to try to engage more with the community, figure out new things that we can do with this and new ideas and how we can make it more useful to more people. If you're interested in some of the stuff that we're coming up next, do have a Google Form that you can fill in. It's just an email address that we can contact you and just let you know, hey, here's where we're going. We're still trying to figure out the best way of doing that. Rather than trying to figure that out in a rush and get it horribly horribly wrong, we have something simple to get us started. Again, the usuals are social channels. If you are interested, please feel free to check us out anywhere there. Thanks for listening. All right. Thank you very much. I'm hopeful if you want to start getting set up. Yeah, we're going to do questions, but you can start getting set up in the meantime. Questions, Ryan? The TCP over TCP problem. You mentioned uniform IP addresses visible from the client. Are you doing termination in the client so you can avoid the lobbying format? To avoid the what? Sorry? The performance collapse of TCP over TCP when you have a drop packet. Based on the stuff that we've been doing, we very rarely see TCP meltdown scenarios these days. It's most common when you're on either a very poor network or you're on the edge of Wi-Fi and you get a significant number of drops. Normally, this cleans itself up quite nicely and compared to trying to have a workaround as opposed to just leaving it be and not using TCP at all, so far we very rarely see this in the field. Some of the stuff that we are doing to improve this is just having timeouts based in lightweight itself so that it knows when it's trying to send traffic if it isn't getting a response or you're not able to read from that socket after a period of time. It can affect you like a dead man switch and just reset that connection. Usually, due to what triggers those events, it's usually when it's in your pocket and not being interacted with. Usually, when those things would happen anyway, you wouldn't be aware of it. It wouldn't be happening just as you were typing something, for example. There's definitely things we can do to improve it, but so far it's not posed much for a problem. I wanted to ask, do we need to use ExpressVPN itself to utilize lightweight? Do we need to use ExpressVPN itself to utilize lightweight? For example, OpenVPN and WireGuard offer their own servers so we can set up in our servers. How can we use lightweight? Lightweight, as in the core protocol, it's on GitHub. It's fully open source. You can use it for anything. That is the core library. That's been designed specifically to remove any mention like TCP, UDP and stuff like that. You can hook it up in any way you can imagine to whatever you want. The most fun one we've talked about so far is doing lightweight over Google Sheets. You don't actually have to use TCP or UDP. You can stick it over a spreadsheet if you want. Your performance would not be great and you wouldn't be streaming anything, but you could build that connectivity. To answer your question more directly, we do have a very basic reference client as I alluded to earlier. That's being improved now. Over the next few months to the end of the year, we're looking to release better reference clients that are improved that you could use as your own server. You do not need to be an ExpressVPN customer to use lightweight. You can go and take the library now and build stuff with it, but soon there will be better suited clients. You can actually use it as an open VPN replacement. Is there any tentative date or any specific line that you're working with in the open source domain which has a promising deadline or data on which we can expect something that we can use on our own servers? Can you say that first bit again? Is there any open source client which is closely working with you so that I can expect the data on which we can try deploying this on our own servers to test it out? We do have a lot of people at Express who are very engaged with the open source community. I think we have a couple who are debbie maintainers. We have a couple who do a lot of work at open WRT. As part of the new validation and testing for the new work we're doing with Rust, that's what's going to cause these new clients to be created and released, but then we release as part of the Rust rework effectively. At that point we are looking to work with any open source distribution that wants to help and work with us, and we'll be openly trying to help, for example, ensure that we're able to package it in the right way. We're looking to work with distributions to try and get it out there. At least initially, you'd just be able to download it either from the crate or into your site, but we are actively looking to work with people to get it integrated into distribution so others can use it. Thanks for your presentation, Pete. Could you speak more to the post-quantum protection part that you're talking about? Do you have a framework and idea in mind that you're working on that you're exploring? Could you maybe speak a little bit more to that? Sure. One of the really nice benefits of using Wolf SSL as our library is Wolf SSL has already integrated post-quantum support as part of the LibOQS project. For us, actually enabling post-quantum security is effectively tweaking the configuration of Wolf and then rebuilding. We don't actually have to do anything particularly special for that. We don't have to implement new protocols or new layers. We're just going to take what's already there that someone else has already designed, tested, and certified, and we're going to use that. If anything crypto related, that's how we approach it. We try to do it hands-off. Do you want to know more about the actual issue or your core of the issue and just want to know the framework? We're just going to use it. If you go to our GitHub page, we create a system level wrapper for Wolf SSL already, so Wolf SSL-SYS. It's a Rust create for Wolf SSL. We've already integrated the post-quantum feature into that. Anyone can pull that create, set that feature, and they'll have access to Wolf SSL in Rust with the post-quantum stuff enabled. We're currently working on adding the high-level wrapper around it so that you can more easily use it with things like Tokyo, but the core stuff is already there, and it's already open for people to look at and see you're working. Cool. Two questions. One is, how do you handle expiry of SSL-SYS for this? The second one is about, what was the inspiration or why I got that you just stated from? Thanks. So Lightway itself doesn't really do anything specific with the SSL certs. It just uses whichever SSL certs that you provide it, so you can get those from any provider or your own CA if you want. So again, you can indeed use less encrypt. Again, another benefit of using Wolf SSL, like standing off the shelf certs, just work out of the box. So there's no restriction on how you create those or how you use them. As long as you have in the client the CA so that it can recognize the server, there's nothing you need to do that's special for that. In terms of inspiration, I think Warguard was super inspiring for a whole host of reasons. Until then, VPNs are always clunky. You always expect them to impact how you use your connection. It's going to get slower, latency is going to go up. This was just something that we kind of just assumed and expected would happen with all VPNs. I think what Warguard shows is that they can be lightweight and still be secure, and they can be really, really fast. In many cases, we've seen with Lightway that this actually improves internet connection performance. Obviously, this is testing through R-Service, and R-Service have awesome connectivity. Rather than going for your ISP provides, particularly for international long-haul stuff, by hopping into us, you can access that bandwidth. What traditionally be a case of, please use our VPN, it's not that bad. Now it's actually like we can improve quality of experience. The other way Lightway can do this for you is with it's like it can roam between Wi-Fi and Cell. If you are doing, say, a speed test and you're on Wi-Fi and you just turn Wi-Fi off and you drop back to Cell, your speed test will continue. It'll drop or change, of course, but your connection itself won't drop and your traffic won't be exposed. We found this actually be really helpful even going in elevators and things like that. When you get that WhatsApp call and you get in the elevator and like, I've just lost it for a second. When you come out, of course, you're usually waiting a few more seconds for it to realize that the network is back, the 3Ds come back, or 4Ds come back and trying things to catch up. With Lightway, because it's keeping networks that kind of alive and it very quickly recovers, usually the poor connectivity features in the stuff that runs on top of it, they never need to kick in. So you tend to get faster responses for things like, if you're running Grab or you're running Uber or something like that, you do tend to see more faster recovery, basically. I have a general XP-Pin question, I think, specific about Lightway. XP-Pin recently pulled out of India. There are no Indian servers from what I can recall the last news I read. How are you dealing with situations where more and more governments are having more regulations to control the VPN usage of the citizens? I have a specific use case where I need an Indian server and XP-Pin doesn't have it anymore from what I know. So how are you dealing around that? For the situation because I couldn't use any other VPNs, I set up my own VPN server on an Indian instance and then I am using that. Cool. I'm not a lawyer, obviously. So the India case was quite interesting. As soon as the Indian government said that we are going to put these restrictions in place, we immediately pulled all of our servers from the region. Once it's important for us to have servers there to represent people who want to use it there, privacy is our thing and we will not compromise on that. So as soon as there was any hint there might be some issues, we just pulled out of it straight away and we were the first to do so. However, what we do have for India, I'm not sure if you're aware, but we do have what we call virtual clusters. Again, we're quite open about these. These are clusters that you can connect to that will give you the geolocation of India. So for a lot of connectivity issues that you might have where you need to be in India with an Indian IP address, the virtual clusters can be quite beneficial for you. So if you haven't tried that, give that a go. Again, we are maybe a company, but we're a law-abiding company, so we make sure that we don't get into any of these sort of sticky situations. If we start seeing more cases of this, we will do the same thing. We will pull our servers out. We don't compromise on our privacy or how we build our service. Thank you. So I have a question about the actual cryptographic protocol you guys are using. So I just skimmed your reports from QA53. It seems to be that you're just using TLS because you mentioned that you use wealth TLS, so just actually use the TLS protocol. Pack all the network into a TLS tunnel and use that instead of wire guard. Yeah, so for the TCP side of things, we just use plain-vehicle TLS 1.3. The reason for that is it works really well and we haven't found any reason to change it. For UDP, we are still using DLS 1.2. We have certain extensions that were added to that from the TLS spec to give us a better key renegotiation, but we're already working with Warped Up greater to DLS 1.3. That will also then give us the post-quantum support as well on both the TCP and the UDP side. Yeah, okay, this was well known about so the PQC will be just using the TLS efforts that use that. Yeah, exactly, yeah. So with DLS, once we remove the DLS 1.3, we just get all the benefits of the TLS stuff and then we'll just use the standard of the shelf stuff again. Okay, thank you. Thanks. All right, any more questions? Any more questions? All right, thank you very much. Cool. Thanks everyone. Thanks.