From 0d5db0de7d10d51fb65515091377f8e3fe4b54ae Mon Sep 17 00:00:00 2001 From: Hannes Mehnert Date: Wed, 17 Jul 2019 12:43:03 +0200 Subject: [PATCH] . --- Posts/Summer2019 | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Posts/Summer2019 b/Posts/Summer2019 index 322bfc5..2be1d3e 100644 --- a/Posts/Summer2019 +++ b/Posts/Summer2019 @@ -9,7 +9,7 @@ abstract: As announced [previously](/Posts/DNS), 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 [our website](https://robur.io) which uses [Canopy](https://github.com/Engil/Canopy), a [CalDAV server that stores entries in a git remote](https://robur.io/Projects/CalDAV), and [DNS servers](https://github.com/roburio/unikernels) (the latter two are further described below). -Robur is part of the non-profit company [Center for the Cultivation of Technology](https://techcultivation.org), 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 [prototypefund](https://prototypefund.de) and further funding from [Tarides](https://tarids.com), for TLS 1.3 from [OCaml Labs](http://ocamllabs.io/); worked for [Least Authority](https://leastauthority.com/) on a security audit of an OCaml codebase, and received [donations](https://robur.io/Donate), also in the form of Bitcoins. We're looking for further funded collaborations and also contracting, mail us at `team@robur.io`. Please [donate](https://robur.io/Donate) (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 CO2. +Robur is part of the non-profit company [Center for the Cultivation of Technology](https://techcultivation.org), 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 [prototypefund](https://prototypefund.de) and further funding from [Tarides](https://tarides.com), for TLS 1.3 from [OCaml Labs](http://ocamllabs.io/); security-audited an OCaml codebase, and received [donations](https://robur.io/Donate), also in the form of Bitcoins. We're looking for further funded collaborations and also contracting, mail us at `team@robur.io`. Please [donate](https://robur.io/Donate) (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 CO2. ## Deploying MirageOS unikernels @@ -41,7 +41,7 @@ There has been more work on our DNS implementation, now [here](https://github.co Most prominently is `primary-git`, a unikernel which acts as a primary authoritative DNS server (UDP and TCP). On startup, it fetches a remote git repository that contains zone files and shared hmac secrets. The zones are served, and secondary servers are notified with the respective serial numbers of the zones, authenticated using TSIG with the shared secrets. The primary server provides dynamic in-protocol updates of DNS resource records (`nsupdate`), and after successful authentication pushes the change to the remote git. To change the zone, you can just edit the zonefile and push to the git remote - with the proper pre- and post-commit-hooks an authenticated notify is send to the primary server which then pulls the git remote. -Another noteworthy unikernel is `letsencrypt`, which acts as a secondary server, and whenever a TLSA record with private type and a DER-encoded certificate signing request is observed, it requests a signature from letsencrypt by solving the DNS challenge. The certificate is pushed to the DNS server as TLSA record as well. The DNS implementation provides `ocertify` and `dns-mirage-certify` which use the above mechanism to retrieve valid let's encrypt certificates. The caller (unikernel or Unix command-line utility) either takes a private key directly or generates one from a (provided) seed and generates a certificate signing request. It then looks in DNS for a certificate which is still valid and matches the public key and the hostname. If such a certificate is not present, the certificate signing request is pushed to DNS (via the nsupdate protocol), authenticated using TSIG with a given secret. This way our public facing unikernels (website, this blog, TLS demo server, ..) block until they got a certificate via DNS on startup - we avoid embedding of the certificate into the unikernel image. +Another noteworthy unikernel is `letsencrypt`, which acts as a secondary server, and whenever a TLSA record with custom type (0xFF) and a DER-encoded certificate signing request is observed, it requests a signature from letsencrypt by solving the DNS challenge. The certificate is pushed to the DNS server as TLSA record as well. The DNS implementation provides `ocertify` and `dns-mirage-certify` which use the above mechanism to retrieve valid let's encrypt certificates. The caller (unikernel or Unix command-line utility) either takes a private key directly or generates one from a (provided) seed and generates a certificate signing request. It then looks in DNS for a certificate which is still valid and matches the public key and the hostname. If such a certificate is not present, the certificate signing request is pushed to DNS (via the nsupdate protocol), authenticated using TSIG with a given secret. This way our public facing unikernels (website, this blog, TLS demo server, ..) block until they got a certificate via DNS on startup - we avoid embedding of the certificate into the unikernel image. ## Monitoring @@ -58,4 +58,8 @@ The [domain-name](https://github.com/hannesm/domain-name) library was developed The [GADT map](https://github.com/hannesm/gmap) is a normal OCaml Map structure, but takes key-dependent value types by using a GADT. This library also was part of DNS, but is more broadly useful, we already use it in our icalendar (the data format for calendar entries in CalDAV) library, our [OpenVPN](https://git.robur.io/?p=openvpn.git;a=summary) configuration parser uses it as well, and also [x509](https://github.com/mirleft/ocaml-x509/pull/115) - which got reworked quite a bit recently (release pending), and there's preliminary PKCS12 support (which deserves its own article). [TLS 1.3](https://github.com/hannesm/ocaml-tls) is available on a branch, but is not yet merged. More work is underway, hopefully with sufficient time to write more articles about it. +## Conclusion + +More projects are happening as we speak, it takes time to upstream all the changes, such as monitoring, new core libraries, getting our DNS implementation released, pushing Conex into production, more features such as DNSSec, ... + I'm interested in feedback, either via [twitter](https://twitter.com/h4nnes) [hannesm@mastodon.social](https://mastodon.social/@hannesm) or an issue on the [data repository](https://github.com/hannesm/hannes.nqsb.io/issues).