💾 Archived View for rawtext.club › ~sloum › geminilist › 002291.gmi captured on 2020-10-31 at 14:27:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Alex Schroeder alex at gnu.org
Tue Jul 21 07:09:25 BST 2020
- - - - - - - - - - - - - - - - - - -
On Mon, 2020-07-20 at 23:11 -0400, Gary Johnson wrote:
I was under the impression that the Gemini spec already made it
mandatory to make CNs match the requested domain name. That's why I
implemented SNI in Space Age. Here's the relevant section of the
spec:
From gemini://gemini.circumlunar.space/docs/specification.gmi:
-----------------------------------------------------------------
4 TLS
Use of TLS for Gemini transactions is mandatory.
Use of the Server Name Indication (SNI) extension to TLS is also
mandatory, to facilitate name-based virtual hosting.
-----------------------------------------------------------------
If I'm misunderstanding something here, please clarify.
Hi Gary
Thanks for your response.
My thinking is this: SNI is how the client tells the server which hostit 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 andGary could host their sites on a single server, and they could both usetheir own server certificates. The server would receive requests fromclients for either Alex's site or Gary's site, know which certificateto send back to the client, and serve the appropriate content. This isthe benefit of SNI.
In my mind, this doesn't require hostname verification, though! Alex'scertificate could have used the common name "Alex Schroeder" and Gary'scertificate could have used the common name "Gary Johnson". All theclient sees is a certificate, which it trusts on first use (TOFU).Users might decide to look at the common name of the certificate, ornot. There's not even the need to provide a common name – we could havegenerated our certificates using nothing but our email address, or ourorganization name.
In short, I'm claiming all of these are valid certificates for a Geminisite at alexschroeder.ch, even if they are invalid certificates for aHTTPS site at alexschroeder.ch (maybe? I'm ignoring alt subject name):
openssl x509 -in cert.pem -noout -sha256 -text | grep Subject Subject: emailAddress = alex at 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 thesubject have a common name field that matches the domain? It would haveto be implied in the X.509 spec somewhere, I guess?
CheersAlex