It’s a rhetoric question. I think it does not because the Gemini world uses “trust on first use” (TOFU). That is, a Gemini client visits a Gemini server for the first time, and if it doesn’t know the certificate, it silently stores a fingerprint of said certificate. The next time the Gemini client visits the same Gemini server, the client verifies that the fingerprint still matches. If it does, then nobody has been meddling with the encryption. If it has changed, a warning is usually shown to the user.
The benefit is that we can use self-signed certificates. No promises are made, and you might run into a trap on your first use, but once you begin to trust a site, you can be sure that nobody is meddling with your encryption as long as the fingerprints stay the same.
Now, when you create a new, self-signed certificate, you are asked a few questions. Here’s an example. First, the openssl command to create new certificates, then the openssl output, and at the end, when it comes to the list of questions, I leave them all blank (entering a dot) except for the Common Name (CN). There, I provide any name I want:
openssl req -new -x509 -newkey ec \ -pkeyopt ec_paramgen_curve:prime256v1 \ -days 1825 -nodes -out cert.pem -keyout key.pem Generating an EC private key writing new private key to 'key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:. State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:. Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) []:. Common Name (e.g. server FQDN or YOUR name) []:Gemini Wiki Email Address []:.
Now, if I were using this certificate for a traditional website, I would have to use my domain name as the common name or as the “alt subject name”, and I would have to get the certificate signed by a certification authority, and so on. We don’t want to do all this in the Gemini World, so we’re free to pick any common name. You could pick a “fully qualified domain name” (FQDN) or you could pick “YOUR name” – that’s it. Just any name you want, actually. These questions and their significance is regulated by X.509.
An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed.
Thus, it’s true that on the web, we need to use those signed certificates. But for Gemini, we can pick the identities we want: our organisations, ourselves as individuals, it doesn’t matter. All that matters is that clients (and their users) “trust on first use” (TOFU).
So now we’re getting to the question I have: I have two websites, alexschroeder.ch and transjovian.org; on the web, browsers get the respective certificates when visiting one or the other. On Gemini, I thought I’d save myself some time and just use one certificate for both sites. And now some Gemini clients are complaining: they’re visiting the first site and getting the certificate for the second site, and the common name doesn’t match the hostname, and so they raise an error.
What do you think?
I think they’re wrong, for the reasons explained above. I could have used a certificate with the common names “Alex Schroeder” or “The Transjovian Council” and I decided to use the certificate with the common name “transjovian.org” – in the TOFU world, I don’t think it should matter whether this certificate “belongs” to alexschroeder.ch. The mismatch is irrelevant. All that matters is whether you trust it.
#Gemini #Cryptography
(Please contact me if you want to remove your comment.)
⁂
On the mailing list, Gary Johnson said he was under the impression that the Gemini specification already made it mandatory to make CNs match the requested domain name, and in support of this position he quoted the following:
Use of the Server Name Indication (SNI) extension to TLS is also mandatory, to facilitate name-based virtual hosting.
But my thinking is this: SNI is how the client tells the server which host it wants to reach in case multiple hosts are hosted on the same IP. Thus, the spec says: in order to facilitate name-based virtual hosting, we want SNI to be part of the standard. That is, both users Alex and Gary could host their sites on a single server, and they could both use their own server certificates. The server would receive requests from clients for either Alex’s site or Gary’s site, know which certificate to send back to the client, and serve the appropriate content. This is the benefit of SNI.
In my mind, this doesn’t require hostname verification, though! Alex’s certificate could have used the common name “Alex Schroeder” and Gary’s certificate could have used the common name “Gary Johnson”. All the client sees is a certificate, which it trusts on first use (TOFU). Users might decide to look at the common name of the certificate, or not. There’s not even the need to provide a common name – we could have generated our certificates using nothing but our email address, or our organization name.
In short, I’m claiming all of these are valid certificates for a Gemini site at alexschroeder.ch, even if they are invalid certificates for a HTTPS site at alexschroeder.ch (maybe? I’m ignoring alt subject name):
openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
Subject: emailAddress = alex@gnu.org
openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
Subject: CN = Gemini Wiki
openssl x509 -in /var/lib/dehydrated/certs/transjovian.org/cert.pem \
-noout -sha256 -text | grep Subject
Subject: CN = transjovian.org
What do you think? Do you think SNI inherently mandates that the subject have a common name field that matches the domain? It would have to be implied in the X.509 spec somewhere, I guess?
– Alex
---
I think I’m not alone.
This is what most browsers do before accepting a certificate for the first time (the specification suggests doing the first point, but does not mention the others): Check that the not-valid-after date of the certificate has not passed. Check that the not-valid-before date of the certificate has passed. Check that the host you’re asking for is mentioned in either the Common Name or Subject Alternative Names fields of the certificate. … The problem is that none of these fields matter in a TOFU scheme. – Your Gemini Browser and Server are Probably Doing Certificates Wrong
Your Gemini Browser and Server are Probably Doing Certificates Wrong
Anyway, the clients checking the certificates using the standard libraries without specifying that the library should not do its own verification (!) have refused to connect to my sites, forcing me to use the Let’s Encrypt certificates I use for my web site, resulting in exactly what Björn is warning us about:
A lot of gemini servers today use Let’sEncrypt certificates. This, as any Certificate Authority certificate, poses a challenge, because rotating certificates just don’t mix with TOFU. Remember what I said about at least verifying that we’re connecting to the same server as last time? Yeah... we don’t really know that when the certificate has changed. Every time the server changes its certificate a window of opportunity for a Man in the Middle Attack opens up. – ibid
This remains frustrating.
– Alex 2021-07-08 12:23 UTC