Client verification - handy for use with smartcards like CAC

[mpyne-navy]

Intro

I saw the HN post about Redbean 2.0 a month ago and was inspired by the reference on the Redbean 2 page to a ProgramSslClientVerify function to look further.

I knew that client verification is how smartcard-based authentication schemes that use a public key infrastructure works. And in particular this is what is needed if you want to enforce usage of the DoD's public key infrastructure using smartcards ("Common Access Cards").

Anyways, I'm happy to announce that I've tested adding the DoD root certificates to the CA trust store for a redbean and confirmed that they work for DoD Common Access Cards (or at least, mine).

How to build

I've attached a Makefile (rename to remove .txt extension) that works on Linux with base tools available to download redbean-2.0.3.com, download DoD root certs (which are public), and update the redbean's trust store, enforce TLS, and ban unsecured connections within .init.lua.

Verification of function

To prove it works I add a basic log output from OnHttpRequest(). By doing so, you get in your console logs an output like:
I2022-06-19T16:30:14+000006:/.init.lua:14:redbean-cac:691275] The peer subject name is C=US, O=U.S. Government, OU=DoD, OU=PKI, OU=USN,CN=PYNE.MICHAEL.XXXXX.XXXX046

This is pretty incredible! To do this "for real" in the DoD, we usually use things like fancy network firewalls doing SSL termination with built-in PKI support to handle client verification and set HTTP headers for the upstream app server, or heavy Java-based things that are meant to run in entire k8s clusters, both of which require eye-watering expense and team size. But here, it works in a client of 2.0 megabytes that you can just copy up to an EC2 and have it go nuts (and yes, I've tried that too).

Obviously this will be pretty impossible to test without some kind of DoD-signed certificate you can present. You can create your own CA and mint your own certs to do mutual TLS and that's described online already (and probably a good idea for test-driven development or benchmarking), but that's not quite the use case I was exploring here (more worried about people logging in than I am worried about other servers).

Thoughts for future work

Despite this, there's a few reasons why the DoD would probably find this currently impractical.

1. Certificate revocation checking. The easiest method for something like redbean to handle checking for revoked clients would seem to be OCSP, but mbedTLS doesn't appear to support OCSP.
   • The second easiest method might be certificate revocation lists (CRLs), which mbedTLS does seem to support. It would be annoying to gather the CRLs but they are published by each intermediate CA and I think you could pull the list of URLs to those from the DoD public certificate bundle we pull the root certs out of. The harder part here would be getting redbean to load the CRLs into mbedTLS, I don't think that's currently supported.
2. Shared root store for Fetch and client verification. It's good that redbean has common root certs embedded so that we can safely make secure connections using Fetch. But for a case like this where I'm using client TLS for auth, I don't necessarily want an Amazon server to be able to login into our redbean. Especially since, in principle, a non-DoD CA can sign an end user certificate with a subject name of the exact same format as DoD uses and the current code would be unable to tell that apart. For auth purposes we really want to narrow the possible CAs we trust. The easiest way is to make this a separate trust store for server verification and client verification.
   • Workaround: This is only a problem if you need to Fetch from in-process so if I needed to use this today I'd just delete all the other root certs and make any outbound comms happen out-of-process (maybe tied to a shared Sqlite database?)
3. FIPS-140-3 cryptographic verification. I won't even pretend to support this requirement (it's well-intentioned but overly limiting in the modern age and even sometimes problematic on its own, e.g. with Heartbleed), but it is formally a requirement for government users, including DoD. Alas.

Also this is more a gripe but documenting the GetSslIdentity() function on redbean.dev would also be nice. If it wasn't for searching in this repo I'd have said the function was undocumented, but that's because I was assuming the redbean.dev docs were an authoritative source or mirror. Knowing the identity of your peer is critical for auth purposes so this function will be as essential for client verification use as functions like ProgramSslClientVerify().

All in all this is really cool stuff! I think it would be neat for prototyping in DoD (if we're going to spend lots of money on official systems, we can at least cheaply kick the tires on the concepts first).

[pkulchenko]

@mpyne-navy, thank you for sharing your experience. GetSslIdentify() is actually documented in the help.txt file:

  GetSslIdentity() → str
          Returns certificate subject or PSK identity from the current SSL
          session. `nil` is returned for regular (non-SSL) connections.

help.txt is usually my first stop, as we try to keep the descriptions in it in sync with the list of available functions (although there are still some gaps that we're working on).

@jart, it would be good to keep the description on redbean.dev in sync (or maybe generate it based on help.txt including the cross-links that are not present in help.txt).