Implement mutual TLS/client certificate auth with optional SAN checking

[jonbayl]

These patches implement mutual TLS authentication, checking the client certificate for a) a valid CA signature and b) (optionally) that the leaf certificate has a Subject Alternative Name from an allow-list (supporting both DNS and IP SANs). This implements two new configuration options to enable the feature, and to provide the list of SANs.

I developed this as part of a personal lab project. I'm by no means a brilliant C developer, so my apologies if anything is amiss, but given I had put this together anyway, I thought I may as well at-least submit it. 😄

[chucklever]

Today, the upper layer protocol implementation (the NFS server, for example) decides whether mutual authentication is required. When it is required, tlshd already implements it. Can you elaborate on exactly what is being added here that tlshd doesn't already implement?

[jonbayl]

NFS was actually the upper layer protocol I was playing around with here. Firstly, I think I made some assumptions based on a misconfiguration I had in my NFS server - i.e. not enforcing mtls through xprtsec=mtls in /etc/exports. I think this gave me the initial misconception that tlshd was accepting any old TLS connection, which with that configuration - it was doing correctly.

Reviewing your comments and once I enforced that configuration, I can see that tlshd does indeed authenticate the client from the perspective that the certificate it offers is signed by a mutually trusted CA.

My changes here have two parts:

1. enforce mutual TLS at the tlshd level. Given the above, it's moot. Given my renewed understanding, the upper layers control this already. It potentially gives some extra levers at the tlshd level, but I'm not really sure they add much value (and I can see the argument for it ending up confusing). It makes sense to drop it.

2. Provides the ability to be more granular in the certificates that tlshd accepts. As I've tested it, and as far as I can see - if the certificate presented by the client is signed by a CA that tlshd trusts, it will accept it. In many cases this may be enough. However, you may also have a situation where the certificate authority signs quite a number of certificates, and you want to restrict access only to a handful of trusted clients. This is where the SAN allow-listing here potentially adds value as it would allow the user of tlshd to configure a list of SANs that they wish to allow. If a certificate signed by the trusted CA is presented, but it's issued to a client not in the list, it would still be rejected.

In summary, part 1 - is not implementing a whole lot that tlshd doesn't already - makes sense to drop, part 2 - possibly still adds value and gives some more granular access control capabilities.

Apologies - I think I may have dived in a little prematurely here, mainly caused by my assumptions/mishap with my NFS set-up. I'd welcome your view on whether the SAN allow-list capability would be useful as a standalone feature?

[chucklever]

I'd welcome your view on whether the SAN allow-list capability would be useful as a standalone feature?

Is the allow-list on the server side, or the client side?

Currently the server-side approach is to use TLS session tagging, which is implemented in tlshd but not yet in NFSD. There are man pages available in this repo that explain session tagging in detail. It can include examining SAN fields in incoming certificates, but those fields are a Swiss Army knife, making that challenging to implement with generality.

[jonbayl]

It was server-side. A bit embarrassing, I think I've missed the obvious twice here, I think possibly due to some of the missing functionality on the NFS side to use the session tags, making it slightly less obvious (to me, anyway!).

Your feedback and patience is very much appreciated! This one has definitely been a learning experience for me on a couple of fronts (but also an interesting insight into kTLS).

I'll close this PR, I think with the session tagging and what was discussed earlier, this is pretty much redundant. Thank you again.