diff --git a/articles/2024-08-21-OpenVPN-and-MirageVPN.html b/articles/2024-08-21-OpenVPN-and-MirageVPN.html index ca598d8..0f4ddc8 100644 --- a/articles/2024-08-21-OpenVPN-and-MirageVPN.html +++ b/articles/2024-08-21-OpenVPN-and-MirageVPN.html @@ -25,7 +25,7 @@

MirageVPN and OpenVPN

At Robur we have been busy at work implementing our OpenVPN™-compatible MirageVPN software. -Recently we have implemented the server side. +Recently we have implemented the server side. In order to implement this side of the protocol I studied parts of the OpenVPN™ source code and performed experiments to understand what the implementation does at the protocol level. Studying the OpenVPN™ implementation has lead me to discover two security issues: CVE-2024-28882 and CVE-2024-5594. In this article I will talk about the relevant parts of the protocol, and describe the security issues in detail.

diff --git a/articles/miragevpn-ncp.html b/articles/miragevpn-ncp.html index 5534d38..6c5f4c4 100644 --- a/articles/miragevpn-ncp.html +++ b/articles/miragevpn-ncp.html @@ -25,7 +25,7 @@

MirageVPN updated (AEAD, NCP)

Updating MirageVPN

-

As announced earlier this month, we've been working hard over the last months on MirageVPN (initially developed in 2019, targeting OpenVPN™ 2.4.7, now 2.6.6). We managed to receive funding from NGI Assure call (via NLnet). We've made over 250 commits with more than 10k lines added, and 18k lines removed. We closed nearly all old issues, and opened 100 fresh ones, of which we already closed more than half of them. :D

+

As announced earlier this month, we've been working hard over the last months on MirageVPN (initially developed in 2019, targeting OpenVPN™ 2.4.7, now 2.6.6). We managed to receive funding from NGI Assure call (via NLnet). We've made over 250 commits with more than 10k lines added, and 18k lines removed. We closed nearly all old issues, and opened 100 fresh ones, of which we already closed more than half of them. :D

Actual bugs fixed (that were leading to non-working MirageVPN applications)

In more detail, we had a specific configuration running over all the years, namely UDP mode with static keys (no TLS handshake, etc.). There were several issues (bitrot) that we encountered and solved along the path, amongst others:

To avoid any future breakage while revising the code (cleaning it up, extending it), we are now building several unikernels as part of our CI system. We also have setup OpenVPN™ servers with various configurations that we periodically test with our new code (we'll also work on further automation thereof).

New features: AEAD ciphers, supporting more configuration primitives

-

We added various configuration primitives, amongst them configuratble tls ciphersuites, minimal and maximal tls version to use, tls-crypt-v2, verify-x509-name, cipher, remote-random, ...

+

We added various configuration primitives, amongst them configuratble tls ciphersuites, minimal and maximal tls version to use, tls-crypt-v2, verify-x509-name, cipher, remote-random, ...

From a cryptographic point of view, we are now supporting more authentication hashes via the configuration directive auth, namely the SHA2 family - previously, only SHA1 was supported, AEAD ciphers (AES-128-GCM, AES-256-GCM, CHACHA20-POLY1305) - previously only AES-256-CBC was supported.

NCP - Negotiation of cryptographic parameters

OpenVPN™ has a way to negotiate cryptographic parameters, instead of hardcoding them in the configuration. The client can propose its supported ciphers, and other features (MTU, directly request a push message for IP configuration, use TLS exporter secret instead of the hand-crafted (TLS 1.0 based PRF), ...) once the TLS handshake has been completed.

diff --git a/articles/miragevpn-performance.html b/articles/miragevpn-performance.html index ba48b00..a43a7f5 100644 --- a/articles/miragevpn-performance.html +++ b/articles/miragevpn-performance.html @@ -24,7 +24,7 @@

Speeding up MirageVPN and use it in the wild

-

As we were busy continuing to work on MirageVPN, we got in touch with eduVPN, who are interested about deploying MirageVPN. We got example configuration from their side, and fixed some issues, and also implemented tls-crypt - which was straightforward since we earlier spend time to implement tls-crypt-v2.

+

As we were busy continuing to work on MirageVPN, we got in touch with eduVPN, who are interested about deploying MirageVPN. We got example configuration from their side, and fixed some issues, and also implemented tls-crypt - which was straightforward since we earlier spend time to implement tls-crypt-v2.

In January, they gave MirageVPN another try, and measured the performance -- which was very poor -- MirageVPN (run as a Unix binary) provided a bandwith of 9.3Mb/s, while OpenVPN provided a bandwidth of 360Mb/s (using a VPN tunnel over TCP).

We aim at spending less resources for computing, thus the result was not satisfying for us. We re-read a lot of code, refactored a lot, and are now at ~250Mb/s.

Tooling for performance engineering of OCaml

@@ -40,7 +40,7 @@ To better guide the performance engineering, we also developed discussing it in the OCaml community, and are eager to find a solution to avoid unneeded computations.

Conclusion

-

To conclude: we already achieved a factor of 25 in performance by adapting the code in various ways. We have ideas to improve the performance even more in the future - we also work on using OCaml string and bytes, instead of off-the-OCaml-heap-allocated bigarrays (see our previous article, which provided some speedups).

+

To conclude: we already achieved a factor of 25 in performance by adapting the code in various ways. We have ideas to improve the performance even more in the future - we also work on using OCaml string and bytes, instead of off-the-OCaml-heap-allocated bigarrays (see our previous article, which provided some speedups).

Don't hesitate to reach out to us on GitHub, or by mail if you're stuck.

We want to thank NLnet for their funding (via NGI assure), and eduVPN for their interest.

    diff --git a/articles/miragevpn-server.html b/articles/miragevpn-server.html index 8e9bd6b..0459014 100644 --- a/articles/miragevpn-server.html +++ b/articles/miragevpn-server.html @@ -25,7 +25,7 @@

    MirageVPN server

    It is a great pleasure to finally announce that we have finished a server implementation for MirageVPN (OpenVPN™-compatible). This allows to setup a very robust VPN network on both the client and the server side.

    -

    As announced last year, MirageVPN is a reimplemtation of OpenVPN™ in OCaml, with MirageOS unikernels.

    +

    As announced last year, MirageVPN is a reimplemtation of OpenVPN™ in OCaml, with MirageOS unikernels.

    Why a MirageVPN server?

    Providing Internet services with programming languages that have not much safety requires a lot of discipline by the developers to avoid issues which may lead to exploitable services that are attacked (and thus will circumvent any security goals). Especially services that are critical for security and privacy, it is crucial to avoid common memory safety pitfalls.

    Some years back, when we worked on the client implementation, we also drafted a server implementation. The reasoning was that a lot of the code was already there, and just a few things needed to be developed to allow clients to connect there.

    diff --git a/articles/miragevpn-testing.html b/articles/miragevpn-testing.html index db722d3..eeec7fe 100644 --- a/articles/miragevpn-testing.html +++ b/articles/miragevpn-testing.html @@ -45,7 +45,7 @@ Specifically, we encountered a packet whose message authentication code (MAC) wa It helped us discover the MAC computation was correct but the packet encoding was truncated - both implementations agreed that the MAC was bad. The test was very tedious to write and would not easily scale to cover a large portion of the code. If of interest, take a look into our modifications to OpenVPN and modifications to MirageVPN.

    -

    The end-to-end testing is in addition to our unit tests and fuzz testing; and to our benchmarking binary.

    +

    The end-to-end testing is in addition to our unit tests and fuzz testing; and to our benchmarking binary.

    Our results are that with 4 configurations we achieve above 75% code coverage in MirageVPN. While investigating the code coverage results, we found various pieces of code that were never executed, and we were able to remove them. Code that does not exist is bug-free :D