-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
There are a few issues I noticed with certificates generated by Lagrange:
First is that they aren’t compliant with TLS’ requirements. RFC 8446 §4.4.2.3 requires client certificates be in X.509v3 format unless otherwise negotiated; digging through the source and some traces from OpenSSL don’t seem to indicate that any such negotiation takes place, rendering Lagrange’s client auth out-of-spec.
Another issue is that certificates don’t currently have any key use information. They really ought to have a PKIX extension (marked as critical) indicating that the certs are only for clientAuth (RFC 5280 §4.2.1.12). This requires the certs to be in X.509v3 format.
Another “issue” (this one probably unnecessarily pedantic) is that the AlgorithmIdentifier field of the Subject Public Key Info sequence is set to rsaEncryption. This is a non-specific OID from PKCS#1 (the self-signature uses a more specific OID from PKCS#1). Whilst AFAICS the TLS spec is not concerned with the certificate signature, it actually forbids the use of PKCS#1 systems for on-line certificate verification, instead interpreting rsaEncryption to mean RSASSA-PSS (RFC 8446 §4.4.3, see also RFC 4055 §3). IMO it would be extra nice if the certificates were just generated with RSASSA-PSS AlgorithmIdentifiers and self-signatures, just to be extra sure that usage of the certs in other contexts aren’t vulnerable to cipher substitution shenanigans (“usage in other contexts” in this instance referring to something I’m cooking up 😉).
Thanks 🙂
2023-06-28 · 11 months ago
Hmm, okay, maybe that last one isn’t such a good idea. It doesn’t look like TLS v1.2 supports RSASSA-PSS at all, so maybe it could cause interop issues. It probably isn’t necessary with the clientAuth EKU, anyway.
Also, if you wanted to put this off for a little while, I might end up with a patch in the course of fiddling with my current project. I had to write something similar not too long ago, so I might be able to spare you some digging through the god-awful OpenSSL man pages 😉
While I agree the client certificate generator could use some flexibility and improvement when it comes to selection of version and type of encryption, the Gemini specification's only requirement here is that the client certificates are compatible with TLS 1.2. Any other aspects are undefined at the moment. This means having Lagrange enforce a specific type or format is inappropriate.
The downside of letting the user choose is that they may pick the "wrong" values, making the certificate incompatible with some servers. Thus the current "lowest common denominator" approach.
I’m actually inclined to think that offering users such options is probably handing them a foot-gun (they can always import certs they generated themselves if they really want, right?). My suggestions are more around spec compliance and safe defaults.
As for the spec compliance bit, TLS v1.2 also requires X.509v3 certs.
Hmm, I checked the TLS 1.2 RFC and it does seem version 3 client certificates are required.
With that in mind, I should check again whether this is an appropriate default for Gemini. I'm inclined to make the change, however see earlier discussion:
And yeah, you can always import whatever externally generated client certificates you have.
-- Response ended
-- Page fetched on Sat Jun 1 09:59:08 2024