ocaml · hannesm · Oct 22, 2024
@@ -12,7 +12,7 @@ source:
 <h2>Introduction</h2>
 <p>Tl;DR: mirage-crypto-ec, with x509 0.12.0, and tls 0.13.0, provide fast and secure elliptic curve support in OCaml and MirageOS - using the verified <a href="https://github.com/mit-plv/fiat-crypto/">fiat-crypto</a> stack (Coq to OCaml to executable which generates C code that is interfaced by OCaml). In x509, a long standing issue (countryName encoding), and archive (PKCS 12) format is now supported, in addition to EC keys. In tls, ECDH key exchanges are supported, and ECDSA and EdDSA certificates.</p>
 <h2>Elliptic curve cryptography</h2>
-<p><a href="https://mirage.io/blog/tls-1-3-mirageos">Since May 2020</a>, our <a href="https://usenix15.nqsb.io">OCaml-TLS</a> stack supports TLS 1.3 (since tls version 0.12.0 on opam).</p>
+<p><a href="https://mirage.io/blog/tls-1-3-mirageos">Since May 2020</a>, our <a href="https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak">OCaml-TLS</a> stack supports TLS 1.3 (since tls version 0.12.0 on opam).</p>
 <p>TLS 1.3 requires elliptic curve cryptography - which was not available in <a href="https://github.com/mirage/mirage-crypto">mirage-crypto</a> (the maintained fork of <a href="https://github.com/mirleft/ocaml-nocrypto">nocrypto</a>).</p>
 <p>There are two major uses of elliptic curves: <a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">key exchange (ECDH)</a> for establishing a shared secret over an insecure channel, and <a href="https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm">digital signature (ECDSA)</a> for authentication, integrity, and non-repudiation. (Please note that the construction of digital signatures on Edwards curves (Curve25519, Ed448) is called EdDSA instead of ECDSA.)</p>
 <p>Elliptic curve cryptoraphy is <a href="https://eprint.iacr.org/2020/615">vulnerable</a> <a href="https://raccoon-attack.com/">to</a> <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5407">various</a> <a href="https://github.com/mimoo/timing_attack_ecdsa_tls">timing</a> <a href="https://minerva.crocs.fi.muni.cz/">attacks</a> - have a read of the <a href="https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/">overview article on ECDSA</a>. When implementing elliptic curve cryptography, it is best to avoid these known attacks. Gladly, there are some projects which address these issues by construction.</p>

@@ -10,7 +10,7 @@ source:
 ---
 
 <h2>Goal</h2>
-<p>Have your domain served by OCaml-DNS authoritative name servers. Data is stored in a git remote, and let's encrypt certificates can be requested to DNS. This software is deployed since more than two years for several domains such as <code>nqsb.io</code> and <code>robur.coop</code>. This present the authoritative server side, and certificate library of the OCaml-DNS implementation formerly known as <a href="https://hannes.robur.coop/Posts/DNS">&micro;DNS</a>.</p>
+<p>Have your domain served by OCaml-DNS authoritative name servers. Data is stored in a git remote, and let's encrypt certificates can be requested to DNS. This software is deployed since more than two years for several domains such as <code>robur.coop</code>. This present the authoritative server side, and certificate library of the OCaml-DNS implementation formerly known as <a href="https://hannes.robur.coop/Posts/DNS">&micro;DNS</a>.</p>
 <h2>Prerequisites</h2>
 <p>You need to own a domain, and be able to delegate the name service to your own servers.
 You also need two spare public IPv4 addresses (in different /24 networks) for your name servers.

@@ -10,7 +10,7 @@ preview_image:
 <p>As announced <a href="https://hannes.robur.coop/Posts/DNS">previously</a>, I started to work at robur early 2018. We're a collective of five people, distributed around Europe and the US, with the goal to deploy MirageOS unikernels. We do this by developing bespoke MirageOS unikernels which provide useful services, and deploy them for ourselves. We also develop new libraries and enhance existing ones and other components of MirageOS. Example unikernels include <a href="https://robur.io">our website</a> which uses <a href="https://github.com/Engil/Canopy">Canopy</a>, a <a href="https://robur.io/Our%20Work/Projects#CalDAV-Server">CalDAV server that stores entries in a git remote</a>, and <a href="https://github.com/roburio/unikernels">DNS servers</a> (the latter two are further described below).</p>
 <p>Robur is part of the non-profit company <a href="https://techcultivation.org">Center for the Cultivation of Technology</a>, who are managing the legal and administrative sides for us. We're ourselves responsible to acquire funding to pay ourselves reasonable salaries. We received funding for CalDAV from <a href="https://prototypefund.de">prototypefund</a> and further funding from <a href="https://tarides.com">Tarides</a>, for TLS 1.3 from <a href="http://ocamllabs.io/">OCaml Labs</a>; security-audited an OCaml codebase, and received <a href="https://robur.io/Donate">donations</a>, also in the form of Bitcoins. We're looking for further funded collaborations and also contracting, mail us at <code>[email protected]</code>. Please <a href="https://robur.io/Donate">donate</a> (tax-deductible in EU), so we can accomplish our goal of putting robust and sustainable MirageOS unikernels into production, replacing insecure legacy system that emit tons of CO<span style="vertical-align: baseline; position: relative;bottom: -0.4em;">2</span>.</p>
 <h2>Deploying MirageOS unikernels</h2>
-<p>While several examples are running since years (the <a href="https://mirage.io">MirageOS website</a>, <a href="http://ownme.ipredator.se">Bitcoin Pi&ntilde;ata</a>, <a href="https://tls.nqsb.io">TLS demo server</a>, etc.), and some shell-scripts for cloud providers are floating around, it is not (yet) streamlined.</p>
+<p>While several examples are running since years (the <a href="https://mirage.io">MirageOS website</a>, <a href="http://ownme.ipredator.se">Bitcoin Pi&ntilde;ata</a>, TLS demo server (not available anymore), etc.), and some shell-scripts for cloud providers are floating around, it is not (yet) streamlined.</p>
 <p>Service deployment is complex: you have to consider its configuration, exfiltration of logs and metrics, provisioning with valid key material (TLS certificate, hmac shared secret) and authenticators (CA certificate, ssh key fingerprint). Instead of requiring millions lines of code during orchestration (such as Kubernetes), creating the images (docker), or provisioning (ansible), why not minimise the required configuration and dependencies?</p>
 <p><a href="https://hannes.robur.coop/Posts/VMM">Earlier in this blog I introduced Albatross</a>, which serves in an enhanced version as our deployment platform on a physical machine (running 15 unikernels at the moment), I won't discuss more detail thereof in this article.</p>
 <h2>CalDAV</h2>

@@ -22,7 +22,7 @@ Pi&ntilde;ata</a>.</p>
 <p>From the start of the Pi&ntilde;ata project, we published the <a href="https://github.com/mirleft/btc-pinata">source code</a>, the virtual machine image, and the versions of the used libraries in a git repository.  Everybody could develop their exploits locally before launching them against our Pi&ntilde;ata.  The Pi&ntilde;ata provides TLS endpoints, which require private keys and certificates.  These are generated by the Pi&ntilde;ata at startup, and the secret for the Bitcoin wallet is provided as a command line argument.</p>
 <p>Initially the Pi&ntilde;ata was deployed on a Linux/Xen machine, later it was migrated to a FreeBSD host using BHyve and VirtIO with <a href="https://github.com/solo5/solo5">solo5</a>, and in December 2017 it was migrated to native BHyve (<a href="https://hannes.robur.coop/Posts/Solo5">using <code>ukvm-bin</code> and solo5</a>).  We also changed the Pi&ntilde;ata code to accomodate for updates, such as the <a href="https://mirage.io/blog/announcing-mirage-30-release">MirageOS 3.0 release</a>, and the discontinuation of floating point numbers for timestamps (asn1-combinators 0.2.0, x509 0.6.0, tls 0.9.0).</p>
 <h2>Motivation</h2>
-<p>We built the Pi&ntilde;ata for many purposes: to attract security professionals to evaluate our <a href="https://mirage.io/blog/introducing-ocaml-tls">from-scratch developed TLS stack</a>, to gather empirical data for our <a href="https://usenix15.nqsb.io">Usenix Security 15 paper</a>, and as an improvement to current bug bounty programs.</p>
+<p>We built the Pi&ntilde;ata for many purposes: to attract security professionals to evaluate our <a href="https://mirage.io/blog/introducing-ocaml-tls">from-scratch developed TLS stack</a>, to gather empirical data for our <a href="https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak">Usenix Security 15 paper</a>, and as an improvement to current bug bounty programs.</p>
 <p>Most bug bounty programs require communication via forms and long wait times for
 human experts to evaluate the potential bug.  This evaluation is subjective,
 intransparent, and often requires signing of non-disclosure agreements (NDA),

@@ -12,7 +12,7 @@ source:
 <h2>Cryptographic material</h2>
 <p>Once a private and public key pair is generated (doesn't matter whether it is plain RSA, DSA, ECC on any curve), this is fine from a scientific point of view, and can already be used for authenticating and encrypting. From a practical point of view, the public parts need to be exchanged and verified (usually a fingerprint or hash thereof). This leads to the struggle how to encode this cryptographic material, and how to embed an identity (or multiple), capabilities, and other information into it. <a href="https://en.wikipedia.org/wiki/X.509">X.509</a> is a standard to solve this encoding and embedding, and provides more functionality, such as establishing chains of trust and revocation of invalidated or compromised material. X.509 uses certificates, which contain the public key, and additional information (in a extensible key-value store), and are signed by an issuer, either the private key corresponding to the public key - a so-called self-signed certificate - or by a different private key, an authority one step up the chain. A rather long, but very good introduction to certificates by Mike Malone is <a href="https://smallstep.com/blog/everything-pki.html">available here</a>.</p>
 <h2>OCaml ecosystem evolving</h2>
-<p>More than 5 years ago David Kaloper and I <a href="https://mirage.io/blog/introducing-x509">released the initial ocaml-x509</a> package as part of our <a href="https://nqsb.io">TLS stack</a>, which contained code for decoding and encoding certificates, and path validation of a certificate chain (as described in <a href="https://tools.ietf.org/html/rfc6125">RFC 5280</a>). The validation logic and the decoder/encoder, based on the ASN.1 grammar specified in the RFC, implemented using David's <a href="https://github.com/mirleft/ocaml-asn1-combinators">asn1-combinators</a> library changed much over time.</p>
+<p>More than 5 years ago David Kaloper and I <a href="https://mirage.io/blog/introducing-x509">released the initial ocaml-x509</a> package as part of our TLS stack, which contained code for decoding and encoding certificates, and path validation of a certificate chain (as described in <a href="https://tools.ietf.org/html/rfc6125">RFC 5280</a>). The validation logic and the decoder/encoder, based on the ASN.1 grammar specified in the RFC, implemented using David's <a href="https://github.com/mirleft/ocaml-asn1-combinators">asn1-combinators</a> library changed much over time.</p>
 <p>The OCaml ecosystem evolved over the years, which lead to some changes:</p>
 <ul>
 <li>Camlp4 deprecation - we used camlp4 for stream parsers of PEM-encoded certificates, and sexplib.syntax to derive s-expression decoders and encoders;

@@ -14,7 +14,7 @@ authors:
 <p>Here's a summary of the things in MirageOS 3 that we're most excited about:</p>
 <h3>Solo5</h3>
 <p>MirageOS 3.0 is the first release that integrates the solo5 targets, <code>virtio</code> and <code>ukvm</code>, fully with the <code>mirage</code> front-end tool.  Now you can <code>mirage configure -t ukvm</code>, build a unikernel, and run directly with the generated <code>ukvm-bin</code>!  We've updated the &quot;hello world&quot; tutorial to reflect our excitement about <code>ukvm</code> -- the <code>ukvm</code> target is considerably easier to interface with and configure than <code>xen</code> was, and for a lot of users this will be a clearer path toward operational deployment of unikernels.</p>
-<p>For a lot more information on the Solo5 targets, see <a href="https://mirage.io/blog/introducing-solo5">the earlier blog post announcing solo5</a>, <a href="https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/williams">Unikernel Monitors: Extending Minimalism Outside of the Box</a>, and <a href="https://github.com/solo5/solo5/tree/master/README.md">the very readable solo5 repository README</a>.  You can also read how to <a href="https://hannes.nqsb.io/Posts/Solo5">run solo5 unikernels on FreeBSD via bhyve</a>.</p>
+<p>For a lot more information on the Solo5 targets, see <a href="https://mirage.io/blog/introducing-solo5">the earlier blog post announcing solo5</a>, <a href="https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/williams">Unikernel Monitors: Extending Minimalism Outside of the Box</a>, and <a href="https://github.com/solo5/solo5/tree/master/README.md">the very readable solo5 repository README</a>.  You can also read how to <a href="https://hannes.robur.coop/Posts/Solo5">run solo5 unikernels on FreeBSD via bhyve</a>.</p>
 <h3>Playing More Nicely with OPAM</h3>
 <p>MirageOS 3 has a much richer interface for dealing with the package manager and external library dependencies.  A user can now specify a version or range of versions for a package dependency, and the <code>mirage</code> front-end tool will construct a custom <code>opam</code> file including both those package dependencies and the ones automatically generated from <code>mirage configure</code>.  <code>mirage</code> will also consider version constraints for its own packages -- from now on, <code>opam</code> should notice that releases of <code>mirage</code> are incompatible with your unikernel.</p>
 <p>For more information on dealing with packages and dependencies, the documentation for <a href="http://docs.mirage.io/functoria/Functoria/index.html#pkg">the Functoria.package function</a> will likely be of use.  <a href="https://github.com/mirage/mirage-skeleton/blob/mirage-dev/device-usage/prng/config.ml">The PRNG device-usage example in mirage-skeleton</a> demonstrates some useful invocations of <code>package</code>.</p>
@@ -25,7 +25,7 @@ authors:
 <p>The MirageOS 3 module types define a core set of likely errors for each module type (see <a href="http://docs.mirage.io/mirage-flow/Mirage_flow/module-type-S/index.html">the mirage-flow module type</a> for an example), which can be extended by any given implementation.  Module types now specify that each implementation must include a pretty-printer that can handle all emitted error types.  Functions that return a <code>success</code> type when they run as expected return a <code>(success, error) Result.t</code>, which the caller can print with <code>pp_error</code> if the value is an <code>Error</code>.</p>
 <p>For more background on the result type, see the <a href="http://erratique.ch/software/rresult">Rresult library</a> which defines further useful operations on <code>Result.t</code> and is used widely in MirageOS libraries.  <a href="https://mirage.io/docs/mirage-3.0-errors">A more in-depth explanation of errors</a> in Mirage 3 is also available.</p>
 <h3>Logs Where You Want Them</h3>
-<p>MirageOS version 2.9.0 included automatic support for logging via the <code>Logs</code> and <code>Mirage_logs</code> library, but by default logs were always printed to the console and changing the log reporter was cumbersome.  In MirageOS 3, you can send logs to a consumer of syslog messages with <code>syslog_udp</code>, <code>syslog_tcp</code>, or with the full authentication and encryption provided by <code>ocaml-tls</code> using <code>syslog_tls</code>.  For more information, see <a href="https://hannes.nqsb.io/Posts/Syslog">the excellent writeup at hannes.nqsb.io</a>.</p>
+<p>MirageOS version 2.9.0 included automatic support for logging via the <code>Logs</code> and <code>Mirage_logs</code> library, but by default logs were always printed to the console and changing the log reporter was cumbersome.  In MirageOS 3, you can send logs to a consumer of syslog messages with <code>syslog_udp</code>, <code>syslog_tcp</code>, or with the full authentication and encryption provided by <code>ocaml-tls</code> using <code>syslog_tls</code>.  For more information, see <a href="https://hannes.robur.coop/Posts/Syslog">the excellent writeup at hannes.robur.coop</a>.</p>
 <h3>Disaggregated Module Type Definitions</h3>
 <p>Breaking all of the MirageOS 3.0 APIs showed us that keeping them all in the same place made updates really difficult.  There's now an additional set of packages which contain the definitions for each set of module types (e.g. <a href="https://github.com/mirage/mirage-fs">mirage-fs</a> for the <code>FS</code> module type, <a href="https://github.com/mirage/mirage-block">mirage-block</a> for the <code>BLOCK</code> module type, etc).  A few module types had some additional useful code that was nicely functorized over the module type in question, so we've bundled that code in the module type packages as well.  Documentation for all of the module type packages is available at <a href="http://docs.mirage.io">the Mirage documentation hub</a>.</p>
 <p>We hope that this change combined with the <code>opam</code> workflow changes above will result in <em>much</em> less painful API changes in the future, as it will be possible for unikernel authors to target specific versions more readily.</p>

@@ -209,7 +209,7 @@ end
 <p>All the application programmer needs to do is define functionality in relation to <code>flow</code> for sending and receiving data, establish this function as a callback with <code>listen_tcpv4</code>, and start a listening thread with <code>listen</code>.</p>
 <h2>More Complex Uses</h2>
 <p>An OCaml HTTP server, <a href="http://www.github.com/mirage/ocaml-cohttp">Cohttp</a>, is currently powering this very blog.  A simple static webserver using Cohttp <a href="https://github.com/mirage/mirage-skeleton/tree/master/static_website">is included in <code>mirage-skeleton</code></a>.</p>
-<p><a href="https://tls.nqsb.io/">The OCaml-TLS demonstration server</a> announced here <a href="http://mirage.io/blog/introducing-ocaml-tls">just a few days ago</a> is also running atop Cohttp - <a href="https://github.com/mirleft/tls-demo-server">source is available on Github</a>.</p>
+<p>The OCaml-TLS demonstration server (not available anymore) announced here <a href="http://mirage.io/blog/introducing-ocaml-tls">just a few days ago</a> is also running atop Cohttp - <a href="https://github.com/mirleft/tls-demo-server">source is available on Github</a>.</p>
 <h2>The future</h2>
 <p>Mirage's TCP/IP stack is under active development!  <a href="https://github.com/mirage/mirage-tcpip/search?q=TODO&amp;ref=cmdform">Some low-level details</a> are still stubbed out, and we're working on implementing some of the trickier corners of TCP, as well as <a href="http://somerandomidiot.com/blog/2014/05/22/throwing-some-fuzzy-dice/">doing automated testing</a> on the stack.  We welcome testing tools, bug reports, bug fixes, and new protocol implementations!</p>