Bringing FIDO2 device support to sandboxes

Hardening user logins with 2FA is becoming must-feature of Web services; most of the services I use daily (such as GitLab instances) are already enabling it. Although it’s a bit cumbersome to enter secondary factor manually, using hardware tokens (such as FIDO2 authenticators) simplifies the process to a single tap, also making the entire authentication more secure based on public key cryptography.

On the client side, major browsers provide built-in support for hardware tokens (at least CTAP1), though sandboxed applications cannot benefit from this without allowing direct access to the host hardware. To improve the situation, we had several discussions in forums last year and somehow reached a rough consensus: we need a proxy for those authenticator devices.

Norbert Pócs in our team tackled this problem and has managed to create a D-Bus based proxy service that can bridge the device access to sandboxed applications. At DevConf.cz 2021, we presented our effort covering a proof-of-concept Firefox/Flatpak integration (special thanks to the people behind zbus, which made this pretty straightforward).

If you are interested in this topic, take a look at the recording of our presentation. Slides are also available. It’s still up in the air how to properly integrate this feature into browsers, but maybe the next step would be to finalize the protocol to allow different implementations.

What’s new in GnuTLS 3.7.0

On behalf of the GnuTLS team, I am pleased to present GnuTLS 3.7.0, the first cut of the 3.7 series. This is the result of several months of planning and work by 25 contributors and includes feature enhancements and behavior changes, such as removal of deprecated functions and tightening of system requirements. In this entry, I will try to detail some notable features in the release.

API for on-demand CA certificates retrieval

During the TLS authentication phase, the server typically presents a chain of X.509 certificates, from the end-entity certificate to the trusted CA certificate. The AIA extension allows the server to omit certain portion of the certificate chain, by pointing to the location where the client can download the missing certificates. Although GnuTLS provides a means to override the certificate verification logic completely through callbacks, this task is error-prone and thus desired to be supported natively. Sahana Prasad introduced the new set of API that allow applications to safely complement the certificate chain. The API is already being used in glib-networking.

API to support QUIC

QUIC is a new, UDP based transport protocol used as the basis of HTTP/3. Although the protocol internally relies on TLS for security, the networking protocol requires direct access to the TLS handshake state machine, which is normally hidden behind the TLS library interface.

After examining the design decisions in other libraries, we took the approach to provide a small set of API that exposes the necessary part of the state machine: capturing and injecting Handshake/Alert messages, and notifying key installation.

The API can be used as a crypto backend of the ngtcp2 library, and in turn by curl’s experimental HTTP/3 support. Here is a quick screenshot how it works:


$ ./src/curl -V
curl 7.74.0-DEV (x86_64-pc-linux-gnu) libcurl/7.74.0-DEV GnuTLS/3.7.0 zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) ngtcp2/0.1.0-DEV nghttp3/0.1.0-DEV
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli Debug HTTP3 HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL TLS-SRP TrackMemory UnixSockets

$ ./src/curl --verbose -s --alt-svc altsvc.cache https://quic.aiortc.org/
* STATE: INIT => CONNECT handle 0x7c8a68; line 1796 (connection #-5000)
* Alt-svc connecting from [h1]quic.aiortc.org:443 to [h3-29]quic.aiortc.org:443
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x7c8a68; line 1842 (connection #0)
[...]
* QUIC handshake is completed
* ngtcp2 established connection!
* Connected to quic.aiortc.org () port 443 (#0)
* Marked for [keep alive]: HTTP/3 default
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x7c8a68; line 1987 (connection #0)
* STATE: SENDPROTOCONNECT => DO handle 0x7c8a68; line 2011 (connection #0)
* Using HTTP/3 Stream ID: 0 (easy handle 0x7c8a68)
> GET / HTTP/3
> Host: quic.aiortc.org
> user-agent: curl/7.74.0-DEV
> accept: */*
> alt-used: quic.aiortc.org:443
>
[...]

Hard dependency on Nettle 3.6

GnuTLS relies on the Nettle library for cryptographic algorithm implementations. While we closely work with the Nettle upstream, we have kept the copy of the library in our tree for compatibility reasons. By requiring Nettle 3.6, we were able to remove those compatibility code from the distribution, which makes the maintenance easier.

GOST MAGMA/KUZNYECHIK CTR-ACPKM and CMAC

Thanks to Dmitry Baryshkov, Nettle 3.6 has seen adoption of the GOST hash and digital signature (GOSTDSA) algorithms. Aiming at the inclusion of the future Nettle releases, the GOST block cipher algorithms, Magma and Kuznyechik, have also been made available through the abstract crypto API.

Resurrection of padlock instruction set and support for Zhaoxin CPU

GnuTLS has supported the VIA padlock instruction set for many years now. However, the support has become difficult to test as the VIA CPUs are hard to obtain. Jonas Zhou fixed the current padlock detection code, and added support for the compatible instruction set available in the Zhaoxin CPU family.

3.8.0 and 3.7.1 milestones are now open!

Now that 3.7.0 was released, a couple of milestones have been created for the new development.

I would expect even more new features coming in the those future releases, such as the Linux kernel TLS (KTLS) support, DTLS 1.3, algorithm acceleration based on AF_ALG, and TPM 2.0 support, to name a few. Stay tuned for updates!

libsecret is accepting Outreachy interns as well

Like other projects in GNOME, libsecret also has an open project for Outreachy internship: Create a portable library for reading/writing libsecret keyring format.

libsecret is a library that allows applications to store/retrieve user secrets (typically passwords). While it usually works as a client against a separate D-Bus service, it can also use a local file as database. The project is about refactoring the file database so it can easily gain more advanced features like hardware-based security, etc. That might sound intimidating as it touches cryptography, but don’t worry and reach out to us if you are interested 🙂

Update: we didn’t get applicants in this round, but the project is still open until someone will step up to implement it. Here is the details from the proposal:

libsecret is a library that allows applications to store and retrieve user secrets, widely used by GNOME and other desktop applications. While it works as a client of the D-Bus service, it has recently gained support for storing secrets in a local file for constrained applications. The current implementation, however, has a few shortcomings:

  1. it is tied to the specific crypto library (libgcrypt)
  2. it cannot be easily used by other projects, such as GNOME Keyring
  3. no versioning / migration support from other keyring formats

The objective of this project is to revamp the implementation in a modular design, allowing multiple crypto libraries (OpenSSL, GnuTLS, etc) to be used as backend, making the reader/writer code standalone, and adding proper support for data migration.

The resulting library shall be embedded as a git submodule in libsecret and linked as a static library, in a way akin to the GVDB library.

Secrets management for Flatpak applications

At this year’s GUADEC, I talked about how Flatpak applications could manage user secrets such as passwords. It has now been summarized as an article on opensource.com:

TL;DR, the points are:

  • If your app is using libsecret and you are willing to avoid unnecessary exposure of D-Bus Secret Service API to Flatpak sandboxes, we recommend to stick with (or port to) the simple API of libsecret
  • libsecret and co. are still maintained and your help is greatly appreciated! 🙂

Talk on TLS 1.3 APIs

I have been recently working on TLS (Transport Layer Security) libraries, in particular GnuTLS and NSS. For the last few years there had been a lot of activities in upstream implementing the latest standard, which officially came out as TLS 1.3. While the protocol design drastically changed from TLS 1.2, applications usually don’t need to be modified to just enable TLS 1.3; that is a good thing. On the other hand, a new API set is added to support the new concepts in TLS 1.3, such as 0-RTT mode.

In January, I had a chance to talk at DevConf.cz (and later FOSDEM) to go through those new APIs (slides, recording), which I hope application developers might find useful. Note that the APIs are still changing as we continue adding remaining features to the libraries.