This post was originally published on February 1, 2021.
VPN protocols define how a client and a server authenticate each other, establish a connection, and transmit data through the created tunnel. Plenty of VPN protocols are available, each made for its own unique environment and use case.
At ExpressVPN, we have developed our own protocol to best suit the needs of our customers, enabling them to stay connected all the time without having to accept trade-offs regarding privacy, speed, and convenience. Here, we outline some of the key design decisions we have made to deliver a more private, secure, and reliable VPN experience.
[Go behind the scenes of ExpressVPN. Sign up for the ExpressVPN Blog Newsletter.]
The Lightway protocol is a compact library of only around 1,000 lines of code that can be utilized by client applications on any platform or directly on the server. It does not implement its own cryptography but instead relies heavily on the well-established cryptography library wolfSSL, which has been extensively vetted and has a FIPS-ready library.
Lightway does not rely on external binaries (ready-compiled code) with configuration files, meaning the relationship between the VPN protocol, its implementation, and the client are more easily apparent. It carries no extra baggage in the form of unused or deprecated functionalities and in consequence is slim and easy to audit. It also allows developers to securely implement Lightway on a variety of platforms, both on the client and server.
The most immediately apparent benefit of Lightway is its short time-to-connect. The Lightway client can authenticate the server in a single round trip and establish the connection in three round trips. On UDP, the protocol uses D/TLS 1.2 (TLS for UDP), and in the event of interruption or inactivity, users can pick up right where they left off. D/TLS derives from TLS 1.2 and inherits all of its benefits, including replay protection. For TCP connections, Lightway uses TLS 1.3, and once TLS 1.3 supports UDP, Lightway will make use of it as soon as possible.
As connections aren’t terminated but instead idle, continuing from where a user left off is almost unnoticeable in many common situations, such as when waking a device from sleep or deactivating airplane mode after half a day. Even after changing mobile networks or your physical location, you will still be connected to the same ExpressVPN server.
After a certain period of inactivity, your connection is reset and your internal IP sent back to the queue, from where it will eventually be assigned to somebody else, ensuring that all connections have been terminated. (This “inactivity clock” resets with every packet sent and does not record log-in times or activity profiles.)
Keys are negotiated using Elliptic-Curve Diffie-Hellman (ECDH) every 15 minutes, or whenever your device changes networks, for instance as you move between Wi-Fi and mobile data. If ECDH fails, the software falls back to a classic Diffie-Hellman exchange.
The only two ciphers used in Lightway are AES-256-GCM and ChaCha20/Poly1305. Owing to the excellent hardware acceleration of AES available in most devices, Lightway will mostly default to this well-proven cipher. Only on lower-powered routers or entry-level mobile devices might ChaCha20 be used. Other protocols (such as SSL or older versions of TLS) and ciphers are not included in the client and server software, mitigating the risk of downgrade attacks.
Lightway by default does not obfuscate its traffic. To mitigate surveillance and censorship, the traffic can be modified to appear like other traffic by the client on top of the Lightway protocol. This is well suited for the way ExpressVPN users make use of their apps.
The core codebase of Lightway is now available for preview on GitHub, ensuring transparency to our users. We will be releasing even more Lightway code soon, allowing users to make use of the ExpressVPN network without requiring closed-source software or unknown binaries, similar to how the OpenVPN manual configuration allows it today.