namecoin / ncp11

PKCS11 module for Namecoin TLS certificate trust

ncp11: Namecoin TLS Certificate Trust PKCS#11 Module

Build Instructions

1. Install Go.
2. Clone this repo.
3. Configure Go Modules to use the latest experimental Namecoin branches of pkcs11mod and pkcs11 (these will be submitted upstream later).
4. CGO_ENABLED=1 go build -buildmode c-shared -o libncp11.so
   1. If building for Windows or macOS, change the output filename to ncp11.dll or libncp11.dylib.

Installation Instructions

1. Build ncp11 from source (see above) or download binaries from Namecoin.org.
2. Install Encaya and make sure that it's running. (You'll probably want to set it to launch automatically on boot.)
3. Install ncp11 like any other PKCS#11 module.

p11-kit (e.g. NSS, GnuTLS, Firefox, Chromium, and GNOME Web on Fedora)

Register via .module file

NSS (e.g. Firefox on all OS's and Chromium on GNU/Linux)

modutil -add

Firefox (probably also LibreWolf, IceCat, etc.)

Security Devices GUI

Firefox

SecurityDevices Enterprise Policy

License / Credits

Original code Copyright Namecoin Developers 2018-2022. ckibproxy, fedorarealckbiproxy, and testdata directories, and loose files in root directory, are licensed under LGPLv2.1+. moz directory is licensed under GPLv3+.

Based on:

• https://github.com/miekg/pkcs11
  • BSD 3-Clause License
• https://github.com/Pkcs11Interop/pkcs11-mock
  • Apache 2.0 License

ncp11's Issues

Logging includes visited domains (privacy leak)

The log files include text such as Issuer/Subject CommonName: ca-test.bit Domain CA. This is a privacy leak since users may not want their browsing history to be written to a log file. This logging should be either removed completely or moved behind an environment variable (which should be disabled by default).

Look into not bundling pkcs11 header files

Right now we're bundling pkcs11 header files that originate from OASIS and from miekg/pkcs11. It might be useful to avoid bundling them (to make it easier to audit that we haven't modified them).

Possible approaches include using miekg/pkcs11 as a Git submodule, or fetching the headers from the OASIS website via rbm.

"nctls.so" name is confusing

The .so extension refers to any dynamically linked library on Linux systems. pkcs11 modules, of course, are included under that umbrella. Unfortunately, @cjdelisle pointed out on #namecoin-dev that many users are likely to assume that the .so extension in the name "nctls.so" refers to an LD_PRELOAD library, not a pkcs11 module. This is especially true because there's already a conceptually similar project called Cert-Shim which is implemented using LD_PRELOAD.

So, we should probably change the name of the project. I'd tend to lean toward "ncp11". "p11" is a well-accepted abbreviation for pkcs11, and "ncp11" is short and easy to type/remember/say.

Thoughts?

certMatchesTemplate doesn't handle CKO_PRIVATE_KEY

My error logs indicate that occasionally, ncp11 is asked to match certs against a template that sets CKA_CLASS to CKO_PRIVATE_KEY. Right now, ncp11 expects CKA_CLASS to always be either CKO_CERTIFICATE or CKO_NSS_TRUST, so it generates a warning (Template contains unknown CKA_CLASS 3) in the error log. AFAICT the warning is harmless (ncp11 returns an empty list of objects, which is the correct behavior), but we should still fix it since it adds noise to the error logs.

CloseAllSessions is unimplemented

Based on my testing, it appears that the CloseAllSessions function is used by some NSS tools (I think the modutil command for adding a module to an NSS DB calls it). We should therefore implement it.

FindObjectsInit doesn't handle [CKA_TOKEN, CKA_CLASS] template types

My error logs indicate that occasionally, ncp11 is asked to match certs against a template whose types consist of [CKA_TOKEN, CKA_CLASS]. (I think Firefox is responsible for this query.) ncp11 doesn't currently have this template on its whitelist of known templates, so it generates a warning (Unknown FindObjectsInit template types: [1 0]) in the error log. AFAICT the warning is harmless (ncp11 returns an empty list of objects, which is the correct behavior), but we should still fix it since it adds noise to the error logs.

Add a make target for p11-kit installation

AFAICT it should be possible to add ncp11 to p11-kit for system-wide operation. We just need that added to the makefile. It's possible that running through p11-kit will cause compatibility issues due to different pkcs11 usage compared to Chromium/Firefox; if such issues show up they should be fixed.

Consider splitting off pkcs11mod into its own repo

The pkcs11mod package is sufficiently broad in intended audience that I don't think it makes sense to keep it as a subdirectory of the nctls.so repo. I'd much rather split it off into its own repo.

Thoughts?

Factor out "p11trustmod" package

We should refactor ncp11, by factoring out a p11trustmod package. This package will provide a p11mod.Slot, and will accept a p11trustmod.Backend, which provides the following interface:

• Accepts query for "IsBuiltinRootList"; returns boolean. If true, then the module will have a CKO_NSS_BUILTIN_ROOT_LIST object present, and certificates will have a CKA_NSS_MOZILLA_CA_POLICY attribute present. Otherwise, both are suppressed.
• Accepts query for "IsTrusted"; returns boolean. If true, then the module will return both CKO_CERTIFICATE and CKO_NSS_TRUST objects. Otherwise, it will only return CKO_CERTIFICATE objects.
• Accepts queries for certificates by value, subject, issuer+serial, or all certs.
• Returns a struct per cert that contains the following fields (which are then converted into a CKO_CERTIFICATE and CKO_NSS_TRUST object and passed to p11mod):
  • Label (string)
  • Certificate (x509.Certificate)
  • Builtin Policy (boolean)
  • Trust for Server Auth (CKT_NSS_ trust value)
  • Trust for Client Auth (CKT_NSS_ trust value)
  • Trust for Code Signing (CKT_NSS_ trust value)
  • Trust for Email Protection (CKT_NSS_ trust value)
• Info, TokenInfo (pass through to p11mod.Slot's functions)

ncp11 can then be refactored to provide this API.

Investigate whether we can make NSS ignore libnssckbi.so by returning non-empty CKO_NSS_BUILTIN_ROOT_LIST

I noticed in the error logs that NSS seems to occasionally ask ncp11 for a list of objects with CKA_CLASS of CKO_NSS_BUILTIN_ROOT_LIST. Some non-exhaustive checking of the NSS source code suggests that this query is done by NSS to check whether a pkcs11 module is the built-in root CA list, and if it is, NSS won't try to check any additional pkcs11 modules for the root CA list. It would be interesting if we could take advantage of this, and make NSS not try to load libnssckbi.so. Further research would be warranted here.

Support CA's, not just end-entity certs

mozilla::pkix (which is used by Firefox) requires that all trust anchors be CA's. That means that ncp11 will need to retrieve CA certs from the HTTP API. Among other things, that means that the API will need some changes to indicate which certs are end-entity and which are CA's. CA's will need the trust value CKT_NSS_TRUSTED_DELEGATOR instead of CKT_NSS_TRUSTED.

const initializer is not a constant

Building ncp11 f060446 for linux/amd64 (in rbm) yields the following error:

Starting build: Wed Aug  7 05:29:38 2019
/var/tmp/dist/gcc/bin ~
~
# github.com/namecoin/ncp11
../dist/gopath/src/github.com/namecoin/ncp11/filename_other.go:15:2: const initializer os.Getenv("HOME") + "/libnssckbi.so" is not a constant
../dist/gopath/src/github.com/namecoin/ncp11/filename_other.go:16:2: const initializer os.Getenv("HOME") + "/libnssckbi-namecoin-target.so" is not a constant

Presumably I screwed up the CKBI filename patch in f060446. Working on a fix now.

SEC_ERROR_LIBRARY_FAILURE in Firefox when installed via NSS DB

Steps to reproduce

1. Install ncp11 to Firefox via the Firefox GUI or via NSS DB's pkcs11.txt.
2. Restart Firefox.
3. Visit an HTTPS website.

Expected results

Website should load.

Observed results

SEC_ERROR_LIBRARY_FAILURE

Other notes

• This is with Firefox 60.6.3 (Debian Buster package).
• Happens with both the 35C3 workshop ncp11 binary and the current rbm-compiled ncp11 binary.
• Installing ncp11 via replacing libnssckbi.so (the Mozilla one, not the p11-kit one) does not trigger this behavior.
• I don't know if anything similar occurs when ncp11 is installed via p11-kit's module list.
• I don't know if anything similar occurs when ncp11 is installed via replacing the p11-kit variant of libnssckbi.so.
• I don't know if anything similar occurs when ncp11 is installed via a WebExtension.
• I don't know if anything similar occurs when using Chromium (in GNU/Linux) instead of Firefox.
• I don't know if this is an ncp11 bug in pkcs11 compliance, a Mozilla bug in pkcs11 compliance, or a quirk in Mozilla's vendor extensions to pkcs11 that ncp11 isn't properly following.
• At this time I don't think this is blocking any NLnet milestones (ncp11 is mainly intended to target the Tor Browser NLnet milestone, and that milestone doesn't use the affected installation method), so it's lower priority to fix. But we still should look into it.

Investigate non-main package

It would be useful to check whether a package other than main can export functions in a C ABI shared library. If so, it would be useful to set the package to something other than main, so that the code can easily be reused by different pkcs11 module implementations, e.g. different main packages could supply a different pkcs11.Ctx-compatible interface instance as per #2.

Connect to the HTTP API via Unix domain socket / Windows named pipe

Unix domain sockets and Windows named pipes have substantial security advantages over TCP (specifically, they're much easier to manage permissions for, which helps for sandboxing). As such, it would be highly beneficial to make ncp11 communicate with the HTTP API via a Unix domain socket or Windows named pipe instead of the default TCP.

certMatchesTemplate doesn't handle CKO_NSS_BUILTIN_ROOT_LIST

My error logs indicate that occasionally, ncp11 is asked to match certs against a template that sets CKA_CLASS to CKO_NSS_BUILTIN_ROOT_LIST. Right now, ncp11 expects CKA_CLASS to always be either CKO_CERTIFICATE or CKO_NSS_TRUST, so it generates a warning (Template contains unknown CKA_CLASS 3461563220) in the error log. AFAICT the warning is harmless (ncp11 returns an empty list of objects, which is the correct behavior), but we should still fix it since it adds noise to the error logs.

Investigate compliance of loading CKBI multiple times

The pkcs11 spec says that an application shouldn't load the same module multiple times. This poses some interesting questions given our use case. We want to have a CKBI proxy module (or perhaps multiple CKBI proxy modules). Each CKBI proxy module wants to load the CKBI module, and NSS will load CKBI itself once as well. The spec seems to be unclear on whether we can do this. Specific questions:

1. What is the definition of an application? Specifically, if an application A loads modules C and P, and module P then loads module C as well, does this constitute application A loading module C multiple times?
2. What is the definition of a module? Specifically, if an application A opens the module "c1.so" and the module "c2.so", where both files have identical contents and deterministically behave identically, does the different filename cause them to be considered different modules, or are they the same module? What properties besides filename do or do not cause two .so files to be considered different modules?

My Google-fu seems to be failing on this one. Might be easiest to just ask on StackExchange.

Move NSS vendor-specific constants to miekg/pkcs11 package

Miek has indicated that we can move the NSS vendor-specific constants to miekg/pkcs11. We probably should do that, since presumably there exist projects besides ncp11 that might want to use those constants.

Proxy the incoming pkcs11 calls to a pkcs11.Ctx interface

To improve flexibility and abstraction, it would be useful for the main.go functions to simply call the corresponding methods of an instance of an interface that matches pkcs11.Ctx. This would trivially allow proxying to another .so file by passing an actual pkcs11.Ctx, and would also make it easier to supply a custom Go-based backend that uses standard Go types/idioms rather than cgo.

Look into updating pkcs11 version to 2.40

We're currently returning a pkcs11 version of 2.20, while the latest version is 2.40. I picked 2.20 because that's what pkcs11-mock's example code used, but we might want to evaluate whether switching to 2.40 would bring any benefits.

certMatchesTemplate doesn't handle CKO_NSS_CRL

My error logs indicate that occasionally, ncp11 is asked to match certs against a template that sets CKA_CLASS to CKO_NSS_CRL. Right now, ncp11 expects CKA_CLASS to always be either CKO_CERTIFICATE or CKO_NSS_TRUST, so it generates a warning (Template contains unknown CKA_CLASS 3461563217) in the error log. AFAICT the warning is harmless (ncp11 returns an empty list of objects, which is the correct behavior), but we should still fix it since it adds noise to the error logs.