Add PKCS#11 / p11-kit verifier for Linux

[zecakeh]

As mentioned in several places, the current problems with Linux are that the certificates are loaded only once and there are no trust decisions available.

Several distributions use p11-kit as a way to list certificates on the system and to list other PKCS#11 modules, and expose them via its API or a PKCS#11 proxy module. By interacting with it, we get an up-to-date list of certificates, and each certificate has a trust decision.

There is support for this in other TLS libraries:

• GnuTLS links p11-kit directly
• There is a PKCS#11 provider for OpenSSL, that uses p11-kit's proxy module by default.
• p11-kit can replace NSS's PKCS#11 module with its own.

[djc]

What are you trying to achieve exactly? What is the problem motivating your suggestion? Concretely, which (popular) distributions rely on p11-kit by default?

[zecakeh]

My use case is that we have a Linux desktop application that uses reqwest to make HTTP requests. With the current choice of TLS connectors, we cannot access user-provided certs in some environments. Particularly when the application is bundled with Flatpak, the only way to access user-provided certs on the system is to use p11-kit (although it is poorly documented). So for example users have a difficult time using proxies.

The distributions that I know use p11-kit by default (there might be others):

• Fedora, Red Hat, CentOS
• Arch Linux and derivatives

[djc]

@complexspaces have you run into issues with this kind of isolation at your employer?

Personally I'm not excited about doing FFI with a bunch of GLib-encumbered C code, but I agree that this might be a half way reasonable thing to do for these environments.

It doesn't inspire confidence that the link to PKCS #11 from the p11-kit homepage is broken (ends up at the rsa.com homepage) -- apparently it now lives at OASIS.

I'd be more interested in ways to have Rust versions of the code dealing with JSON/filesystem interfaces, but I guess that might mean we'd miss out on the C modules people are already using and installing? Do we know what kind of default installed modules one might encounter on Fedora, Red Hat or Arch Linux systems?

[ctz]

Since PKCS#11 can't do trust decisions¹ this would be more along the lines of rustls-native-certs (which hooks up assorted sources of root certs suitable for server authentication) than rustls-platform-verifier (which hooks up the platform's verifier API).

I think if we want to do something with PKCS#11, my strong preference would be to divest that interaction into a subprocess to keep them in their own resource and memory space. Arbitrary PKCS#11 providers are obviously of varying quality, and resource management in a dynamic library is notoriously fraught.

However, p11-kit provides some such programs that we could use as subprocesses, eg this:

$ trust extract --format pem-bundle --filter=ca-anchors --purpose=server-auth certs.pem
$ export SSL_CERT_FILE=certs.pem

Means rustls-native-certs will pick up those certs.

Footnotes

1. in other words, it cannot tell you if a certificate chain is valid for a particular purpose/name, only which certificates exist and what their properties are, and also let you verify signatures with them ↩

[complexspaces]

@complexspaces have you run into issues with this kind of isolation at your employer?

No, not to my knowledge. Granted the 1Password Snap/Flatpak distros aren't the most popular options so the sample size might be too small to be a good reference here. In general though we have only rarely gotten comments about needing to restart the Linux desktop app to pick up new certificates as well (and who are just appending them into the "main" /etc/certificate paths anyway).

I share the remarks expressed above about not wanting to deal with historically encumbered C code. Speaking specifically on the case of Flatpak, it looks like their runtime handles spawning a pk11-kit "proxy" server based on the linked commit (thanks for sharing that!). It would be nice if there was pure Rust code that could interact with this socket, if present, to support the sandboxed use case. That would avoid needing to depend on it at all or consider C libraries. However the documentation seems insistent that you should use their .so module alone for that, which is a downer :(

I don't mind the idea of subprocessing away a command-line tool: it seems doable with little work and doesn't risk frequent API breakage like reading from a socket would. The one downside I see is that despite all the complexity it adds we don't get closer to #60.

On a more positive angle it does solve the new problem this issue describes where certain sandboxed environments can't load enough certificates and brings them to at least the same feature/functionality parity as non-sandboxed ones.