OpenVPN is probably still the better default for most threat models. Hear me out. ExpressVPN shipped Lightway with roughly two thousand lines of core protocol code, built on wolfSSL instead of OpenSSL, and published the source on GitHub in 2021. The codebase reduction is real and it is the strongest argument Lightway has. This desk concedes that upfront.
But a protocol is not a product. A protocol is a component inside a deployment, inside a provider's infrastructure, inside a jurisdiction, inside a threat model. The codebase reduction matters. Everything surrounding it matters more. What follows are nine questions this desk considers essential — each one absent from the standard Lightway coverage.
Is Lightway Actually Open Source in the Way That Matters?
Technically, yes. ExpressVPN published the Lightway core library on GitHub under GPLv2 in September 2021. The repository contains the protocol implementation and the wolfSSL integration layer. Anyone can clone it, read it, compile it. But "open source" carries different weight depending on which question you bring to the code.
The client applications — the software users actually install on their devices — remain proprietary. The server-side implementation is not published. What you can audit is the protocol negotiation and tunnel construction logic. What you cannot audit is the production deployment: how ExpressVPN configures its servers, what telemetry exists at the application layer above the protocol, how key material rotates across their infrastructure. For most threat models, the server side is where trust lives. A protocol can be flawless in its published form and still run inside a configuration that undermines every guarantee the repository implies. The open-source label is accurate. The assurance it suggests is not.
Why Did ExpressVPN Choose wolfSSL Over OpenSSL?
Attack surface reduction. That is the stated rationale and it is defensible on its face. OpenSSL carries decades of backwards-compatible cipher suite support, legacy protocol negotiation paths, and a codebase that exceeds 500,000 lines by conservative estimates. Heartbleed lives in institutional memory for a reason. wolfSSL targets embedded systems and constrained environments — it is engineered to be small, and its smaller footprint means fewer lines for a security auditor to cover in a fixed-duration engagement.
The logic holds in isolation. In context, wolfSSL's smaller deployment footprint also means a smaller research community examining its internals. OpenSSL's vulnerabilities are famous precisely because hundreds of researchers audit it continuously. High-profile bugs attract more eyeballs. More eyeballs find more bugs. More found bugs means more patches, which means a harder target over time. wolfSSL does not benefit from that cycle at the same scale. Every dependency is a trust decision with a specific shape. Choosing wolfSSL means betting that a TLS library with a fraction of OpenSSL's production exposure receives proportionally adequate scrutiny. That bet is open.
Does Fewer Lines of Code Actually Mean Fewer Vulnerabilities?
Not automatically. The correlation between codebase size and vulnerability density is supported in aggregate — academic work from Shin, Meneely, and others demonstrates a statistical relationship between code volume and defect probability. But aggregate correlation does not produce individual prediction. A two-thousand-line codebase with no fuzzing infrastructure will carry more exploitable paths than a hundred-thousand-line codebase under continuous automated analysis with OSS-Fuzz coverage.
The relevant metric is not the line count. It is the ratio of code to sustained review effort. Lightway's small core is genuinely easier to cover in a single audit engagement. This desk conceded that point at the top. Here is where the concession stops bearing weight: audit coverage is a snapshot, not a permanent property. A Cure53 engagement covers the codebase at a specific commit hash on a specific date. Every subsequent commit, every wolfSSL point release pulled into the build, every server-side configuration change — those arrive after the audit report is signed. Fewer lines buy a cheaper first audit. They do not purchase ongoing assurance. The distance between "audited once" and "continuously verified" is the distance most marketing copy refuses to measure.
What Happens When wolfSSL Ships a CVE?
This is the dependency question ExpressVPN's product pages do not address. wolfSSL has shipped security advisories affecting TLS session integrity at the library level. CVE-2022-25640, disclosed February 2022, involved a client-side certificate verification bypass in wolfSSL versions prior to 5.2.0 — a malicious server could present a crafted certificate chain that the client accepted without proper validation. CVE-2022-25638, published on the same date, described a related flaw in OCSP stapling verification that allowed similar bypass conditions.
These are not theoretical findings. They are scored, published, and patchable. But "patchable" carries an asterisk the size of the deployment pipeline between wolfSSL's repository and ExpressVPN's production servers. How quickly does ExpressVPN integrate wolfSSL security patches into Lightway builds? How quickly do those builds reach user devices? That latency is not published, not audited, and not subject to any external SLA. It exists entirely inside ExpressVPN's internal release process, and the end user has no independent mechanism to verify it. When your protocol's security properties depend on a third-party library, the dependency chain is the threat surface. The protocol code is secondary.
What Did the Cure53 Audit of Lightway Actually Scope?
Cure53 conducted a penetration test and source code review of the Lightway protocol library. The engagement was commissioned and funded by ExpressVPN. That disclosure is material — a vendor-commissioned audit is not equivalent to independent research, though it is substantially better than no audit at all.
The published findings covered the core protocol implementation and its wolfSSL integration. The scope did not extend to server-side deployment configurations. It did not include the proprietary client applications that users install. It did not examine the logging infrastructure or telemetry systems operating above the tunnel layer. Scope defines meaning. An audit that examines protocol logic but not the production environment running that logic can certify that the tunnel construction is sound. It cannot certify that the deployed system inherits that soundness. This is not a criticism of Cure53 — their engagement boundaries were contractually defined. It is a criticism of how the audit result is communicated downstream. "Independently audited" presented without scope disclosure is positioning, not assurance. The scope document is the audit. Everything else is narrative.
Can Deep Packet Inspection Fingerprint Lightway Traffic?
Yes. Every tunneling protocol produces observable artifacts at the packet level, and Lightway is no exception. The protocol operates over UDP using DTLS, and its handshake sequence generates characteristics a network observer can classify — initial packet sizes, inter-packet timing during session establishment, and the cipher suite list presented in the ClientHello. A DPI-capable adversary can build statistical models distinguishing Lightway sessions from ordinary DTLS application traffic with high confidence.
Context matters here. OpenVPN over TCP on port 443, configured with TLS-crypt obfuscation, can more closely resemble standard HTTPS traffic — imperfect mimicry, but a higher bar for automated classifiers. WireGuard's fixed-size handshake pattern is trivially identifiable. Lightway sits between them: less static than WireGuard, more distinguishable than a hardened OpenVPN configuration.
If your threat model includes a DPI-capable adversary — the baseline assumption in China, Iran, Russia, Turkmenistan, and an increasing number of corporate network environments — the protocol's fingerprint profile is not a footnote. It is the first thing the adversary checks.
Does OpenVPN's Complexity Serve a Purpose Most Reviews Ignore?
It does. OpenVPN's sprawling configuration surface is simultaneously its greatest liability and its most undervalued feature. The protocol supports TCP and UDP transport selection, TLS-crypt for pre-shared key obfuscation of the entire control channel, TLS-auth for HMAC-based authentication of handshake packets, granular cipher selection, and plugin hooks for external authentication frameworks. Complexity creates misconfiguration risk. That same complexity enables hardening that no minimal protocol can replicate.
TLS-crypt deserves specific attention. The mechanism encrypts the complete control channel — including the TLS ClientHello — with a symmetric pre-shared key before the TLS handshake begins. A passive network observer cannot see the handshake at all. The session looks like opaque data on a standard port. Lightway has no equivalent mechanism in its current architecture. For users whose adversary operates DPI infrastructure at a national scale, that single capability justifies OpenVPN's continued deployment despite its age, its codebase volume, and its slower connection establishment. Features that appear as unnecessary complexity in one threat model become load-bearing in another.
Does the Protocol Choice Matter If the Provider Logs Anyway?
No. This is the question that collapses most VPN protocol analysis into irrelevance, and it is the question least often asked. A protocol secures the tunnel between client and server. It does not govern what the provider does with metadata visible at the tunnel endpoints — connection timestamps, originating IP addresses, bandwidth consumption, session duration, server selection patterns. These data points are observable at the VPN server regardless of whether the tunnel uses Lightway, OpenVPN, WireGuard, or any other construction.
If a provider retains connection metadata, the protocol's cryptographic properties are orthogonal to the privacy claim. Kape Technologies completed its acquisition of ExpressVPN in late 2021. Kape's prior corporate identity — Crossrider, a company whose historical association with adware distribution is documented in public reporting — is part of the ownership record. ExpressVPN's no-logs policy is published. The TrustedServer RAM-only architecture is described in marketing materials. Whether these commitments survive a determined legal process under British Virgin Islands jurisdiction is a question no protocol audit, no Cure53 engagement, and no GitHub repository can answer. Analyzing the tunnel without analyzing the provider is theater.
When Does Switching Away from OpenVPN Actually Make Sense?
When your threat model does not include a DPI-capable adversary, and your primary requirement is connection reliability on mobile devices. That is the direct answer. Lightway's sub-second handshake and efficient session resumption after network transitions — moving between cellular and Wi-Fi, recovering from brief signal loss — represent genuine engineering improvements for users whose concern is preventing passive ISP observation of browsing destinations. Most consumer VPN users fall into that threat model. For that population, Lightway's reduced handshake latency and lower battery draw on mobile hardware are practical advantages that affect daily usability.
The moment the adversary escalates — DPI capability, legal compulsion authority, active network interference, or any combination — the protocol selection becomes secondary to deployment configuration, provider jurisdiction, key management practices, and logging architecture. OpenVPN with TLS-crypt on a self-hosted server remains the recommendation this desk makes for threat models above consumer-grade ISP redirection. The protocol is a component. The deployment is the system. The system is what the adversary attacks.
The Cure53 audit report for Lightway and the wolfSSL CVEs referenced above both carry 2022 dates. The distance between a dependency vulnerability disclosure and the downstream protocol audit that might catch its integration is measured in months, not days. That gap is the number that matters. It is not published anywhere in ExpressVPN's documentation.