💾 Archived View for gemi.dev › gemini-mailing-list › 000300.gmi captured on 2024-05-26 at 15:40:39. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello again, everyone. I'm happy to announce I have my first release of my bare bones server software and geminispace up-and-running! I hope to add more content and functionality to both in the coming weeks, but in the meantime, please check them both out. Denoscuri, a Deno/TypeScript Gemini server: https://github.com/caranatar/denoscuri My personal geminispace: gemini://caranatar.xyz Cheers, Caranatar P.S., I know it's a little absurd to write a gemini server in a language that compiles to javascript, but hey I'm job hunting and needed a practice project to start learning the language. Plus I wanted to try out Deno -- sent from emacs using mu4e
On 17-Jul-2020 08:42, Caranatar wrote: > Denoscuri, a Deno/TypeScript Gemini server: > https://github.com/caranatar/denoscuri > > My personal geminispace: > gemini://caranatar.xyz Hello Caranatar I'm getting "failed to connect to the server: hostname does not verify: x509: certificate is valid for celulinde, not caranatar.xyz" Does your certificate match your domain? > P.S., I know it's a little absurd to write a gemini server in a language > that compiles to javascript, but hey I'm job hunting and needed a > practice project to start learning the language. Plus I wanted to try > out Deno No its not absurd, JS is just another programming language with very widespread tooling. I think mostly the objections seem to be how using it for mobile code deployment is now a web browser client expectation so the number of client engines is dwindling to a small handful. And what is the real benefit - often not adding much actual value in many places, beyond marketing fluff and burning CPU cycles. But on the server, seems perfectly fine for me, why not build on top of the widespread tooling that exists? Best Wishes - Luke
Ah crap apparently none of the clients I was using to test were actually verifying the certificate, and I forgot to change the CN when I copy/pasted my cert generation command from my laptop. It should be working now... Luke Emmet writes: > On 17-Jul-2020 08:42, Caranatar wrote: > >> Denoscuri, a Deno/TypeScript Gemini server: >> https://github.com/caranatar/denoscuri >> >> My personal geminispace: >> gemini://caranatar.xyz > > Hello Caranatar > > I'm getting "failed to connect to the server: hostname does not > verify: x509: certificate is valid for celulinde, not caranatar.xyz" > > Does your certificate match your domain? > >> P.S., I know it's a little absurd to write a gemini server in a language >> that compiles to javascript, but hey I'm job hunting and needed a >> practice project to start learning the language. Plus I wanted to try >> out Deno > > No its not absurd, JS is just another programming language with very > widespread tooling. I think mostly the objections seem to be how using > it for mobile code deployment is now a web browser client expectation > so the number of client engines is dwindling to a small handful. And > what is the real benefit - often not adding much actual value in many > places, beyond marketing fluff and burning CPU cycles. > > But on the server, seems perfectly fine for me, why not build on top > of the widespread tooling that exists? > > Best Wishes > > - Luke -- sent from emacs using mu4e
Luke Emmet writes: > > I'm getting "failed to connect to the server: hostname does not > > verify: x509: certificate is valid for celulinde, not > > caranatar.xyz" On Fri, 2020-07-17 at 04:20 -0400, Caranatar wrote: > Ah crap apparently none of the clients I was using to test were > actually > verifying the certificate, and I forgot to change the CN when I > copy/pasted my cert generation command from my laptop. It should be > working now... What do other people think about this? My personal impression was that in a trust on first use (TOFU) world, the common name (CN) of a certificate could be anything. It could be "Alex Schroeder", for example. Or it could be "alexschroeder.ch". Even if it was served as the certificate for another domain, like transjovian.org. After all, the question is only whether you "trust on first use". My impression is that a client that tries to verify that CN and domain match is doing it wrong. What do you think? Sadly, my SSL know-how is weak, so any pointers to how things ought to work in a TOFU world are appreciated. Cheers Alex
On the surface I think you're right, that in the TOFU world, CN shouldn't matter, and neither should subjectAltName, etc. We shouldn't even need wildcard certs, because anything should be accepted. However, I hope someone more knowledgeable can chime in, maybe there's an issue I'm not considering. makeworld ??????? Original Message ??????? On Friday, July 17, 2020 5:09 AM, Alex Schroeder <alex at gnu.org> wrote: > Luke Emmet writes: > > > > I'm getting "failed to connect to the server: hostname does not > > > verify: x509: certificate is valid for celulinde, not > > > caranatar.xyz" > > On Fri, 2020-07-17 at 04:20 -0400, Caranatar wrote: > > > Ah crap apparently none of the clients I was using to test were > > actually > > verifying the certificate, and I forgot to change the CN when I > > copy/pasted my cert generation command from my laptop. It should be > > working now... > > What do other people think about this? My personal impression was that > in a trust on first use (TOFU) world, the common name (CN) of a > certificate could be anything. It could be "Alex Schroeder", for > example. Or it could be "alexschroeder.ch". Even if it was served as > the certificate for another domain, like transjovian.org. After all, > the question is only whether you "trust on first use". > > My impression is that a client that tries to verify that CN and domain > match is doing it wrong. What do you think? Sadly, my SSL know-how is > weak, so any pointers to how things ought to work in a TOFU world are > appreciated. > > Cheers > Alex
On Fri Jul 17, 2020 at 5:26 PM CEST, wrote: > On the surface I think you're right, that in the TOFU world, > CN shouldn't matter, and neither should subjectAltName, etc. > We shouldn't even need wildcard certs, because anything should be > accepted. There's some degree of sense in this, if the certificate is self-signed then none of the metadata attached to it is trustworthy in any sense, and anybody can make a cert with whichever domain(s) they like in the CN/SAN fields, so one could argue it should be ignored. I still wonder, though, if it doesn't make sense to check the domain names and expect them to match (AV-98 does this, for what it's worth), mostly just to help guard against configuration errors and things like that? Cheers, Solderpunk
On Sun, 2020-07-19 at 15:57 +0200, Solderpunk wrote: > I still wonder, though, if it doesn't make sense to check the domain > names and expect them to match (AV-98 does this, for what it's > worth), > mostly just to help guard against configuration errors and things > like > that? > I don't know. Do we HAVE to check? If we only have to check when the common name is an actual domain, how do we detect that, regular expressions? It seems to run counter to what TOFU promised. I fell it should be OK for transjovian.org to serve a wiki, and for alexschroeder.ch:1965 to show that wiki, even though it uses the certificate I used for transjovian.org. If the server domains have to match, then I have to do the SNI thing and server different certificates and that's going to make certificates harder, again. Please don't do this.
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. Thanks, Gary Alex Schroeder <alex at gnu.org> writes: > On Sun, 2020-07-19 at 15:57 +0200, Solderpunk wrote: >> I still wonder, though, if it doesn't make sense to check the domain >> names and expect them to match (AV-98 does this, for what it's >> worth), >> mostly just to help guard against configuration errors and things >> like >> that? >> > > I don't know. Do we HAVE to check? If we only have to check when the > common name is an actual domain, how do we detect that, regular > expressions? It seems to run counter to what TOFU promised. > > I fell it should be OK for transjovian.org to serve a wiki, and for > alexschroeder.ch:1965 to show that wiki, even though it uses the > certificate I used for transjovian.org. If the server domains have to > match, then I have to do the SNI thing and server different > certificates and that's going to make certificates harder, again. > > Please don't do this. -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
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 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 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 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?
Cheers
Alex
Hi Alex, I follow your rationale, and unfortunately, I don't know whether matching CNs are required by the x509 spec. I think I'd like to hear Solderpunk weigh in on this issue since it seems like a slightly ambiguous area in the spec. Cheers, Gary Alex Schroeder <alex at gnu.org> writes: > 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 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 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 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? > > Cheers > Alex -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
---