Python's `str.__repr__()`
-Sometimes software is written using whatever built-ins you find in your programming language of choice. +
Sometimes software is written using whatever built-ins you find in your programming language of choice. This is usually great! However, it can happen that you depend on the precise semantics of those built-ins. This can be a problem if those semantics become important to your software and you need to port it to another programming language. diff --git a/articles/2024-08-21-OpenVPN-and-MirageVPN.html b/articles/2024-08-21-OpenVPN-and-MirageVPN.html index 0683731..b80adca 100644 --- a/articles/2024-08-21-OpenVPN-and-MirageVPN.html +++ b/articles/2024-08-21-OpenVPN-and-MirageVPN.html @@ -5,13 +5,13 @@
MirageVPN and OpenVPN
-At Robur we have been busy at work implementing our OpenVPN™-compatible MirageVPN software. -Recently we have implemented the server side. +
At Robur we have been busy at work implementing our OpenVPN™-compatible MirageVPN software. +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/2024-10-29-ptt.html b/articles/2024-10-29-ptt.html new file mode 100644 index 0000000..0c525a6 --- /dev/null +++ b/articles/2024-10-29-ptt.html @@ -0,0 +1,206 @@ + + + + + + +blog.robur.coop
++ The Robur cooperative blog. ++
Postes, télégraphes et téléphones, next steps
+As you know from our article on Robur's +finances, we've just received +funding for our email project. This project +started when I was doing my internship in Cambridge and it's great to see that +it's been able to evolve over time and remain functional. This article will +introduce you to the latest changes to our PTT +project and how far we've got towards providing +an OCaml mailing list service.
+A Git repository or a simple block device as a database?
+One issue that came up quickly in our latest experiments with our SMTP stack was +the database of users with an email address. Since we had decided to ‘break +down’ the various stages of an email submission to offer simple unikernels, we +ended up having to deploy 4 unikernels to have a service that worked.
+-
+
- a unikernel for authentication +
- a unikernel DKIM-signing the incoming email +
- one unikernel as primary DNS server +
- one unikernel sending the signed email to its real destination +
And we're only talking here about the submission of an email, the reception +concerns another ‘pipe’.
+The problem with such an architecture is that some unikernels need to have the +same data: the users. In this case, the first unikernel needs to know the user's +password in order to verify authentication. The final unikernel needs to know +the real destinations of the users.
+Let's take the example of two users: foo@robur.coop and bar@robur.coop. The +first points to hannes@foo.org and the second to reynir@example.com.
+If Hannes wants to send a message to bar@robur.coop under the identity of +foo@robur.coop, he will need to authenticate himself to our first unikernel. +This first unikernel must therefore:
+-
+
- check that the user
fooexists
+ - the hashed password used by Hannes is the same as the one in the database +
Next, the email will be signed by our second unikernel. It will then forward the +email to the last unikernel, which will do the actual translation of the +recipients and DNS resolution. In other words:
+-
+
- it will see that one (the only) recipient is bar@robur.coop +
- check that bar@robur.coop exists and obtain its real address +
- it will obtain reynir@example.com and perform DNS resolution on
+
example.comto find out the email server for this domain
+ - finally send the email signed by foo@robur.coop to reynir@example.com! +
So the first and last unikernels need to have the same information about our +users. One for the passwords, the second for the real email addresses.
+But as you know, we're talking about unikernels that exist independently of each +other. What's more, they can't share files and the possibility of them sharing +block-devices remains an open question (and a complex one where parallel access +may be involved). In short, the only way to ‘synchronise’ these unikernels in +relation to common data is with a Git repository.
+Git has the advantage of being widely used for our unikernels +(primary-git, pasteur, unipi and +contruno). The advantage is that you can track changes, modify +files and notify the unikernel to update itself (using nsupdate, a simple ping +or an http request to the unikernel).
+The problem is that this requires certain skills. Even if it's ‘simple’ to set +up a Git server and then deploy our unikernels, we can restructure our +architecture and simplify the deployment of an SMTP stack!
+Elit and OneFFS
+We have therefore decided to merge the email exchange service and email +submission into a unikernel so that this is the only user information requester.
+So we decided to use OneFFS as the file system for our database, +which will be a plain JSON file. This is perhaps one of the advantages of +MirageOS, which is that you can decide exactly what you need to implement +specific objectives.
+In this case, those with experience of Postfix, LDAP or MariaDB could confirm +that configuring an email service should be ‘simpler’ than implementing a +multitude of pipes between different applications and authentication methods.
+The JSON file is therefore very simple and so is the creation of an OneFFS +image:
+$ cat >database.json<<EOF
+> [ { "name": "din"
+> , "password": "xxxxxx"
+> , "mailboxes": [ "romain.calascibetta@gmail.com" ] } ]
+> EOF
+$ opam install oneffs
+$ oneffs create -i database.json -o database.img
+All you have to do is register this image as a block with albatross and launch +our Elit unikernel with this block-device.
+$ albatross-client create-block --data=database.img database 1024
+$ albatross-client create --net=service:br0 --block=database:database \
+ elit elit.hvt \
+ --arg=...
+At this stage, and if we add our unikernel signing incoming emails, we have more +or less the same thing as what I've described in my previous articles on +deploying an email service.
+Multiplex receiving & sending emails
+The PTT project is a toolkit for implementing SMTP servers. It gives developers +the choice of implementing their logic as they see fit:
+-
+
- sign an email +
- resolve destinations according to a database +
- check SPF information +
- annotate the email as spam or not +
- etc. +
Previously, PTT was split into 2 parts:
+-
+
- management of incoming clients/emails +
- the logic to be applied to incoming emails and their delivery +
The second point was becoming increasingly complex, however, and errors in +sending emails are legion (DMARC non-alignment, the email is too big for the +destination, the destination doesn't exist, etc.). All the more so since, up to +now, PTT could only report these errors via the logs...
+Hannes immediately mentioned the possibility of separating the logic of the +unikernel from the delivery. This will allow us to deal with temporary failures +(greylisting) as well. So a fundamental change was made:
+-
+
- improve the sendmail and
sendmail-lwtpackages (as well as proposing +sendmail-miou!) when sending or submitting an email
+ - improve PTT so that there are now 3 distinct jobs: receiving, what to do with +incoming emails and sending emails +
This finally allows us to describe a clearer error management policy that is
+independent of what we want to do with incoming emails. At this stage, we can
+look for the Return-Path in emails that we haven't managed to send and notify
+the senders!
All this is still in the experimental stage and practical cases are needed to +observe how we should handle errors and how others do.
+Insights & Next goals
+We're already starting to have a bit of fun with email and we can start sending +and receiving emails right away.
+We're also already seeing hacking attempts on our unikernel:
+-
+
- people trying to authenticate themselves without
STARTTLS(or with it, +depending on how clever the bot is)
+ - people trying to send emails as non-existent users in our database +
- we're also seeing content that has nothing to do with SMTP +
Above all, this shows that, very early on, bots try to usurp the identity linked +to your server (in our case, osau.re) in order to send spam, authenticate +themselves or simply send ‘stuff’ and observe what happens. In this case, for +all the cases mentioned, Elit (and PTT) reacts well: in other words, it simply +cuts off the connection.
+We were also able to observe how services such as gmail work. In addition, for +the purposes of a mailing list, email forwarding distorts DMARC verification +(specifically, SPF verification). The case is very simple:
+foo@gmail.com tries to reply to robur@osau.re. robur@osau.re is a mailing list
+to several addresses (one of them is bar@gmail.com). The unikernel will receive
+the email and send it to bar@gmail.com. The problem is the alignment between
+the From field (which corresponds to foo@gmail.com) and our osau.re server.
+From gmail.com's point of view, there is a misalignment between these two
+pieces of information and it therefore refuses to receive the email.
This is where our next objectives come in:
+-
+
- finish our DMARC implementation +
- implement ARC so that our server notifies us that, on our side, the DMARC +check went well and that gmail.com should trust us on this. +
There is another way of solving the problem, perhaps a little more problematic,
+modify the incoming email and in particular the From field. Although this
+could be done quite simply with mrmime, it's better to concentrate on
+DMARC and ARC so that we can send our emails as they are and never alter them
+(especially as this will invalidate previous DKIM signatures!).
Conclusion
+It's always satisfying to see your projects working ‘more or less’ correctly. +This article will surely be the start of a series on the intricacies of email +and the difficulty of deploying such a service at home.
+We hope that this NLnet-funded work will enable us to replace our current email +system with unikernels. We're already past the stage where we can, more or less +(without DMARC checking), send emails to each other, which is a big step!
+So follow our work on our blog and if you like what we're producing (which +involves a whole bunch of protocols and formats - much more than just SMTP), you +can make a donation here!
+ +blog.robur.coop
++ The Robur cooperative blog. ++
Sponsor us via GitHub
+We're delighted to announce the possibility of helping our cooperative through +the GitHub Sponsors platform. The link is available here:
+https://github.com/sponsors/robur-coop
+We would also like to reiterate the possibility of making a donation[1] to our +cooperative via the IBAN of Änderwerk available here (if you need +a tax-deductible donation receipt, please use this form).
+Account holder: Änderwerk gGmbH
+Subject: robur
+IBAN: DE46 4306 0967 1289 8604 00
+BIC: GENODEM1GLS
+Bank: GLS Gemeinschaftsbank, Christstrasse 9, 44789 Bochum, Germany
+More generally, you can refer to our article which explains our +funding since the creation of Robur and we would like to point out that, +despite our funding, part of our work remains unfunded: in particular with +regard to the maintenance of certain software as well as certain services made +available to our users.
+We would therefore be delighted if users of our software and services could +finance our work according to their means. GitHub in particular offers an +easy-to-use platform for funding us (even if, in all transparency, it takes a +certain amount from each transaction).
+-
+
-
+
In fact, this method is preferable to us as this means it will go directly to us instead of through GitHub and Stripe who will take a small cut of the donation in fees.
+↩︎︎
Runtime arguments in MirageOS
-TL;DR: Passing runtime arguments around is tricky, and prone to change every other month.
+TL;DR: Passing runtime arguments around is tricky, and prone to change every other month.
Motivation
Sometimes, as an unikernel developer and also as operator, it's nice to have some runtime arguments passed to an unikernel. Now, if you're into OCaml, diff --git a/articles/dnsvizor01.html b/articles/dnsvizor01.html index a5cdafe..fbc488f 100644 --- a/articles/dnsvizor01.html +++ b/articles/dnsvizor01.html @@ -5,13 +5,13 @@
Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
-TL;DR: We got NGI0 Entrust (via NLnet) funding for developing +
TL;DR: We got NGI0 Entrust (via NLnet) funding for developing DNSvizor - a DNS resolver and DHCP server. Please help us by sharing with us your dnsmasq configuration, so we can diff --git a/articles/finances.html b/articles/finances.html index 6f75ade..6fd86aa 100644 --- a/articles/finances.html +++ b/articles/finances.html @@ -5,13 +5,13 @@
How has robur financially been doing since 2018?
-Since the beginning, robur has been working on MirageOS unikernels and getting +
Since the beginning, robur has been working on MirageOS unikernels and getting them deployed. Due to our experience in hierarchical companies, we wanted to create something different - a workplace without bosses and management. Instead, we are a collective where everybody has a say on what we do, and who gets how diff --git a/articles/gptar-update.html b/articles/gptar-update.html new file mode 100644 index 0000000..8bde6d8 --- /dev/null +++ b/articles/gptar-update.html @@ -0,0 +1,110 @@ + + +
+ + + +blog.robur.coop
++ The Robur cooperative blog. ++
GPTar (update)
+In a previous post I describe how I craft a hybrid GUID partition table (GPT) and tar archive by exploiting that there are disjoint areas of a 512 byte block that are important to tar headers and protective master boot records used in GPT respectively. +I recommend reading it first if you haven't already for context.
+After writing the above post I read an excellent and fun and totally normal article by Emily on how she created executable tar archives. +Therein I learned a clever hack: +GNU tar has a tar extension for volume headers. +These are essentially labels for your tape archives when you're forced to split an archive across multiple tapes. +They can (seemingly) hold any text as label including shell scripts. +What's more is GNU tar and bsdtar does not extract these as files! +This is excellent, because I don't actually want to extract or list the GPT header when using GNU tar or bsdtar. +This prompted me to use a different link indicator.
+This worked pretty great.
+Listing the archive using GNU tar I still get GPTAR, but with verbose listing it's displayed as a --Volume Header--:
$ tar -tvf disk.img
+Vr-------- 0/0 16896 1970-01-01 01:00 GPTAR--Volume Header--
+-rw-r--r-- 0/0 14 1970-01-01 01:00 test.txt
+And more importantly the GPTAR entry is ignored when extracting:
$ mkdir tmp
+$ cd tmp/
+$ tar -xf ../disk.img
+$ ls
+test.txt
+BSD tar / libarchive
+Unfortunately, this broke bsdtar!
+$ bsdtar -tf disk.img
+bsdtar: Damaged tar archive
+bsdtar: Error exit delayed from previous errors.
+This is annoying because we run FreeBSD on the host for opam.robur.coop, our instance of opam-mirror. +This Autumn we updated opam-mirror to use the hybrid GPT+tar GPTar tartition table[1] instead of hard coded or boot parameter specified disk offsets for the different partitions - which was extremely brittle! +So we were no longer able to inspect the contents of the tar partition from the host! +Unacceptable! +So I started to dig into libarchive where bsdtar comes from. +To my surprise, after building bsdtar from the git clone of the source code it ran perfectly fine!
+$ ./bsdtar -tf ../gptar/disk.img
+test.txt
+I eventually figure out this change fixed it for me. +I got in touch with Emily to let her know that bsdtar recently fixed this (ab)use of GNU volume headers. +Her reply was basically "as of when I wrote the article, I was pretty sure bsdtar ignored it." +And indeed it did. +Examining the diff further revealed that it ignored the GNU volume header - just not "correctly" when the GNU volume header was abused to carry file content as I did:
+ /*
+ * Interpret 'V' GNU tar volume header.
+ */
+ static int
+ header_volume(struct archive_read *a, struct tar *tar,
+ struct archive_entry *entry, const void *h, size_t *unconsumed)
+ {
+- (void)h;
++ const struct archive_entry_header_ustar *header;
++ int64_t size, to_consume;
++
++ (void)a; /* UNUSED */
++ (void)tar; /* UNUSED */
++ (void)entry; /* UNUSED */
+
+- /* Just skip this and read the next header. */
+- return (tar_read_header(a, tar, entry, unconsumed));
++ header = (const struct archive_entry_header_ustar *)h;
++ size = tar_atol(header->size, sizeof(header->size));
++ to_consume = ((size + 511) & ~511);
++ *unconsumed += to_consume;
++ return (ARCHIVE_OK);
+ }
+So thanks to the above change we can expect a release of libarchive supporting further flavors of abuse of GNU volume headers! +🥳
+-
+
-
+
Emily came up with the much better term "tartition table" than what I had come up with - "GPTar".
+↩︎︎
GPTar
-At Robur we developed a piece of software for mirroring or exposing an opam repository. +
At Robur we developed a piece of software for mirroring or exposing an opam repository. We have it deployed at opam.robur.coop, and you can use it as an alternative to opam.ocaml.org. It is usually more up-to-date with the git opam-repository than opam.ocaml.org although in the past it suffered from occasional availability issues. I can recommend reading Hannes' post about opam-mirror. diff --git a/articles/lwt_pause.html b/articles/lwt_pause.html index f9fe6b3..0306e51 100644 --- a/articles/lwt_pause.html +++ b/articles/lwt_pause.html @@ -5,13 +5,13 @@
Cooperation and Lwt.pause
-Here's a concrete example of the notion of availability and the scheduler used +
Here's a concrete example of the notion of availability and the scheduler used
(in this case Lwt). As you may know, at Robur we have developed a unikernel:
opam-mirror. It launches an HTTP service that can be used as an
OPAM overlay available from a Git repository (with opam repository add <name> <url>).
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
+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
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:
-
@@ -35,7 +35,7 @@
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 591b8f9..b6160f8 100644 --- a/articles/miragevpn-performance.html +++ b/articles/miragevpn-performance.html @@ -5,13 +5,13 @@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 2e1250a..4a96fd1 100644
--- a/articles/miragevpn-server.html
+++ b/articles/miragevpn-server.html
@@ -5,13 +5,13 @@
-
+
Sponsor us via GitHub + https://blog.robur.coop/articles/2024-12-04-github-sponsor.html ++ https://blog.robur.coop/articles/2024-12-04-github-sponsor.html +Wed, 04 Dec 2024 00:00:00 GMT +
+ -
+
Postes, télégraphes et téléphones, next steps + https://blog.robur.coop/articles/2024-10-29-ptt.html ++ https://blog.robur.coop/articles/2024-10-29-ptt.html +Tue, 29 Oct 2024 00:00:00 GMT +
+ -
+
GPTar (update) + https://blog.robur.coop/articles/gptar-update.html ++ https://blog.robur.coop/articles/gptar-update.html +Mon, 28 Oct 2024 00:00:00 GMT + -
Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel https://blog.robur.coop/articles/dnsvizor01.html @@ -47,6 +68,13 @@https://blog.robur.coop/articles/tar-release.html Thu, 15 Aug 2024 00:00:00 GMT
+ -
+
Testing MirageVPN against OpenVPN™ + https://blog.robur.coop/articles/miragevpn-testing.html ++ https://blog.robur.coop/articles/miragevpn-testing.html +Wed, 26 Jun 2024 00:00:00 GMT + -
qubes-miragevpn, a MirageVPN client for QubesOS https://blog.robur.coop/articles/qubes-miragevpn.html diff --git a/images/smtp.jpg b/images/smtp.jpg new file mode 100644 index 0000000..c974dcc Binary files /dev/null and b/images/smtp.jpg differ diff --git a/index.html b/index.html index fa0ae79..cfa5c46 100644 --- a/index.html +++ b/index.html @@ -5,13 +5,13 @@- Robur's blogIndex + Robur's blog - Index - - - - + + + +@@ -20,21 +20,60 @@ The Robur cooperative blog. -RSS The Robur blog.
+RSS The Robur blog.
Essays and ramblings
-
+ + ++ +
+
-
+ + ++ +
-
+ + ++
+
+ 2024-10-28 + GPTar (update)+
+libarchive vs hybrid GUID partition table and GNU tar volume header
++ ++ -
2024-10-25 - Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
+ Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
The NGI-funded DNSvizor provides core network services on your network; DNS resolution and DHCP.
- + -
@@ -44,10 +83,10 @@
2024-10-22 - Runtime arguments in MirageOS
+ Runtime arguments in MirageOS
The history of runtime arguments to a MirageOS unikernel
- + -
@@ -57,10 +96,10 @@
2024-10-21 - How has robur financially been doing since 2018?
+ How has robur financially been doing since 2018?
How we organise as a collective, and why we're doing that.
- + -
@@ -70,10 +109,10 @@
2024-08-21 - MirageVPN and OpenVPN
+ MirageVPN and OpenVPN
Discoveries made implementing MirageVPN, a OpenVPN-compatible VPN library
- + -
@@ -83,10 +122,23 @@
2024-08-15 - The new Tar release, a retrospective+
+ The new Tar release, a retrospective
A little retrospective to the new Tar release and changes
- + ++ -
+ + +++ 2024-06-26 + Testing MirageVPN against OpenVPN™
+Some notes about how we test MirageVPN against OpenVPN™
++ -
@@ -96,10 +148,10 @@
2024-06-24 - qubes-miragevpn, a MirageVPN client for QubesOS
+ qubes-miragevpn, a MirageVPN client for QubesOS
A new OpenVPN client for QubesOS
- + - @@ -109,10 +161,10 @@
-
@@ -122,10 +174,10 @@
2024-04-16 - Speeding up MirageVPN and use it in the wild
+ Speeding up MirageVPN and use it in the wild
Performance engineering of MirageVPN, speeding it up by a factor of 25.
- + - @@ -135,10 +187,10 @@
-
@@ -148,10 +200,10 @@
2024-02-13 - Speeding elliptic curve cryptography
+ Speeding elliptic curve cryptography
How we improved the performance of elliptic curves by only modifying the underlying byte array
- + -
@@ -161,10 +213,10 @@
2024-02-11 - Cooperation and Lwt.pause
+ Cooperation and Lwt.pause
A disgression about Lwt and Miou
- + -
@@ -174,10 +226,10 @@
2024-02-03 - Python's `str.__repr__()`
+ Python's `str.__repr__()`
Reimplementing Python string escaping in OCaml
- + -
@@ -187,10 +239,10 @@
2023-11-20 - MirageVPN updated (AEAD, NCP)
+ MirageVPN updated (AEAD, NCP)
How we resurrected MirageVPN from its bitrot state
- + -
@@ -200,10 +252,10 @@
2023-11-14 - MirageVPN & tls-crypt-v2
+ MirageVPN & tls-crypt-v2
How we implementated tls-crypt-v2 for miragevpn
- +
- Robur's blog + Robur's blog - Tags @@ -22,7 +22,7 @@Back to index - +Community
@@ -46,7 +46,7 @@MirageOS
- +MirageVPN @@ -56,7 +56,7 @@
OCaml
-- MirageVPN & tls-crypt-v2
- MirageVPN updated (AEAD, NCP)
- Python's `str.__repr__()`
- Cooperation and Lwt.pause
- Speeding elliptic curve cryptography
- GPTar
- Speeding up MirageVPN and use it in the wild
- MirageVPN server
- qubes-miragevpn, a MirageVPN client for QubesOS
- The new Tar release, a retrospective
- Runtime arguments in MirageOS
- Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
- MirageVPN & tls-crypt-v2
- MirageVPN updated (AEAD, NCP)
- Python's `str.__repr__()`
- Cooperation and Lwt.pause
- Speeding elliptic curve cryptography
- GPTar
- Speeding up MirageVPN and use it in the wild
- MirageVPN server
- qubes-miragevpn, a MirageVPN client for QubesOS
- Testing MirageVPN against OpenVPN™
- The new Tar release, a retrospective
- Runtime arguments in MirageOS
- Meet DNSvizor: run your own DHCP and DNS MirageOS unikernel
- GPTar (update)
OpenVPN @@ -72,6 +72,11 @@ QubesOS
+++ SMTP +
+Scheduler @@ -91,12 +96,17 @@
cooperative
- +cryptography
- + +++ emails +
+finances @@ -107,16 +117,26 @@ functors
+++ github +
+++ mailing-lists +
+performance @@ -126,17 +146,22 @@
persistent storage
- +security
- +++ testing +
+unicode @@ -151,7 +176,7 @@
vpn
- + -
+
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.
+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.
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 new file mode 100644 index 0000000..a63961a --- /dev/null +++ b/articles/miragevpn-testing.html @@ -0,0 +1,67 @@ + + + + + + +blog.robur.coop
++ The Robur cooperative blog. ++
Testing MirageVPN against OpenVPN™
+As our last milestone for the EU NGI Assure funded MirageVPN project (for now) we have been working on testing MirageVPN, our OpenVPN™-compatible VPN implementation against the upstream OpenVPN™. +During the development we have conducted many manual tests. +However, this scales poorly and it is easy to forget testing certain cases. +Therefore, we designed and implemented interoperability testing, driving the C implementation on the one side, and our OCaml implementation on the other side. The input for such a test is a configuration file that both implementations can use. +Thus we test establishment of the tunnel as well as the tunnel itself.
+While conducting the tests, our instrumented binaries expose code coverage information. We use that to guide ourselves which other configurations are worth testing. Our goal is to achieve a high code coverage rate while using a small amount of different configurations. These interoperability tests are running fast enough, so they are executed on each commit by CI.
+A nice property of this test setup is that it runs with an unmodified OpenVPN binary. +This means we can use an off-the-shelf OpenVPN binary from the package repository and does not entail further maintenance of an OpenVPN fork. +Testing against a future version of OpenVPN becomes trivial. +We do not just test a single part of our implementation but achieve an end-to-end test. +The same configuration files are used for both our implementation and the C implementation, and each configuration is used twice, once our implementation acts as the client, once as the server.
+We added a flag to our client and our recently finished server applications, --test, which make them to exit once a tunnel is established and an ICMP echo request from the client has been replied to by the server.
+Our client and server can be run without a tun device which otherwise would require elevated privileges.
+Unfortunately, OpenVPN requires privileges to at least configure a tun device.
+Our MirageVPN implementation does IP packet parsing in userspace.
+We test our protocol implementation, not the entire unikernel - but the unikernel code is a tiny layer on top of the purely functional protocol implementation.
We explored unit testing the packet decoding and decryption with our implementation and the C implementation. +Specifically, we encountered a packet whose message authentication code (MAC) was deemed invalid by the C implementation. +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.
+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 +With these tests in place future maintenance is less daunting as they will help us guard us from breaking the code.
+At the moment we do not exercise the error paths very well in the code.
+This is much less straightforward to test in this manner, and is important future work.
+We plan to develop a client and server that injects faults at various stages of the protocol to test these error paths.
+OpenVPN built with debugging enabled also comes with a --gremlin mode that injects faults, and would be interesting to investigate.
MirageVPN & tls-crypt-v2
-In 2019 Robur started working on a OpenVPN™-compatible implementation in OCaml. +
In 2019 Robur started working on a OpenVPN™-compatible implementation in OCaml.
The project was funded for 6 months in 2019 by prototypefund.
In late 2022 we applied again for funding this time to the NGI Assure open call, and our application was eventually accepted.
In this blog post I will explain why reimplementing the OpenVPN™ protocol in OCaml is a worthwhile effort, and describe the Miragevpn implementation and in particular the tls-crypt-v2 mechanism.
qubes-miragevpn, a MirageVPN client for QubesOS
-We are pleased to announce the arrival of a new unikernel: +
We are pleased to announce the arrival of a new unikernel: qubes-miragevpn. The latter is the result of work begun several months ago on miragevpn.
Indeed, with the ambition of completing our unikernel suite and the success of diff --git a/articles/speeding-ec-string.html b/articles/speeding-ec-string.html index ae8552b..aadfb42 100644 --- a/articles/speeding-ec-string.html +++ b/articles/speeding-ec-string.html @@ -5,13 +5,13 @@
Speeding elliptic curve cryptography
-TL;DR: replacing cstruct with string, we gain a factor of 2.5 in performance.
+TL;DR: replacing cstruct with string, we gain a factor of 2.5 in performance.
Mirage-crypto-ec
In April 2021 We published our implementation of elliptic curve cryptography (as mirage-crypto-ec opam package) - this is DSA and DH for NIST curves P224, P256, P384, and P521, and also Ed25519 (EdDSA) and X25519 (ECDH). We use fiat-crypto for the cryptographic primitives, which emits C code that by construction is correct (note: earlier we stated "free of timing side-channels", but this is a huge challenge, and as reported by Edwin Török likely impossible on current x86 hardware). More C code (such as point_add, point_double, and further 25519 computations including tables) have been taken from the BoringSSL code base. A lot of OCaml code originates from our TLS 1.3 work in 2018, where Etienne Millon, Nathan Rebours, and Clément Pascutto interfaced elliptic curves for OCaml (with the goal of being usable with MirageOS).
The goal of mirage-crypto-ec was: develop elliptic curve support for OCaml & MirageOS quickly - which didn't leave much time to focus on performance. As time goes by, our mileage varies, and we're keen to use fewer resources - and thus fewer CPU time and a smaller memory footprint is preferable.
diff --git a/articles/tar-release.html b/articles/tar-release.html index faf10bf..511fe66 100644 --- a/articles/tar-release.html +++ b/articles/tar-release.html @@ -5,13 +5,13 @@The new Tar release, a retrospective
-We are delighted to announce the new release of ocaml-tar. A small library for
+
We are delighted to announce the new release of ocaml-tar. A small library for
reading and writing tar archives in OCaml. Since this is a major release, we'll
take the time in this article to explain the work that's been done by the
cooperative on this project.
