tl;dr: I fixed p11-capi to support SHA-256, thus making it useful again. In doing so, I basically acquired custodianship of an open source project.
P11-capi, developed by Stef Walter in 2008, is a very clever shim that allows Firefox-on-Windows to use the Microsoft Cryptographic API (CAPI). Natively, Firefox uses the PKCS#11 API to interface with cryptographic tokens. Unfortunately, PKCS#11 is not supported by middleware vendors as well as CAPI. P11-capi is a PKCS#11 module that just mediates to the appropriate CAPI calls.
I used p11-capi to access my US-government-issued smartcard from Firefox-on-Windows for years, mainly because I started using a 64-bit version of Firefox (Waterfox). I could not find extant Windows 64-bit PKCS#11 middleware, but I compiled 64-bit p11-capi without much trouble. In doing so, I discovered that p11-capi had the additional benefit of not causing other applications to lock up, because CAPI was mediating access to the smartcard in ways that PKCS#11 could not. In particular, I was using my smartcard with both Firefox and Outlook, and the two applications were fighting for access to the smartcard. Using p11-capi solved this problem.
In 2012, I started publishing 32-bit and 64-bit binaries for p11-capi as a convenience for anyone who wanted to use them, with a digitally signed assertion that I had inspected the code for back doors and compiled it myself.
Alas, sometime around 2013, I started having trouble with Firefox not authenticating to web sites with the smartcard, reporting “SSL_ERROR_SIGN_HASHES_FAILURE”. I tried to troubleshoot it, but my experience with the Microsoft Cryptographic API was virtually nonexistent, and my compile-debug-edit cycle was very slow because of factors beyond my control. Eventually I gave up and resigned myself to use Internet Explorer for any web sites that required PKI client authentication.
Recently (May 2016), I picked it up again and poked a little harder. Ultimately, I determined that Firefox was asking p11-capi to use a SHA-2 hash (SHA-256, in particular), but that CAPI was reporting that it couldn’t use that algorithm. In particular, when I ask CAPI to resolve the OID for SHA-256,
CertOIDToAlgId("2.16.818.104.22.168.4.2.1") (i.e. the OID for SHA-256) returns
CALG_OID_INFO_CNG_ONLY. I suspect that multiple Cryptographic Service Providers are registering the SHA-256 OID, and that some of them are registering it as “CNG Only” and other CSPs implement it. CertOIDtoAlgId() is basically returning the first (or last) registration of that OID. Possibly CryptEnumOIDInfo() is a better approach.
Long-story-short, I added some special cases just to handle SHA-2 algorithms, and solved the technical issue. Since Stef Walter has no particular interest in maintaining p11-capi, I guess I now “own” the project, for lack of someone more sensible. Stef was kind enough to add a note on his git repo that points to my git repo to make it “official”.
Pingback: Ozone and the Government Open Source Software (GOSS) Advisory Board | JFDI: Just Do It
I’m using your latest version and I’m still getting SSL_ERROR_SIGN_HASHES_FAILURE
I have been able to compile and connect the PKCS11 CAPI Bridge to Firefox (38.8.0 ESR), but also face “SSL_ERROR_SIGN_HASHES_FAILURE”, when attempting to make a TLS authentication. We are using Gemalto (ex Safenet) USB tokens, which work fine with Chrome or IE and the Windows Certificate store. The window allowing to choose a valid certificate for authentication even does not appear.
Would you some tips on how to get it through ?
My best regards,
Note to self: maybe there are other OIDs that don’t resolve to known algorithms properly. It would be cool to write a little program or even a WSH script that calls CertOIDtoAlgId() for all known algorithms… something that users could easily use to test.