💾 Archived View for gemi.dev › gemini-mailing-list › 000080.gmi captured on 2023-11-04 at 12:24:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
After being a long-time subscriber to this list while having no idea what Gemini (or even Gopher) is, I've gotten to the point of running my own server. You should be able to access it at gemini://kwiecien.us/ It's a dummy page for now before I figure out what to do with it, but I intend to keep Gemini running on this host for good. My first attempt was to use geminid (written in C) because I figure it'd compile most easily on my system, which runs FreeBSD. It did compile easy, but I haven't gotten it to work just yet likely because of not configuring it right. Next try was with Jetforce because I already had Python3 on the system, which has very limited storage so this seemed better than tinkering with the environment and installing stuff that I won't use for anything else. Jetforce seems to be working nicely enough, but if you find you can't access it let me know so I can figure out what's wrong. I'm having an issue with elpher where it asks me to approve the site's SSL cert because it says something like the issuer not being recognized... well that can't be right, so either I set up Jetforce a little bit wrong (specified the wrong files?), or this is some issue with elpher, which I noticed complains about the certs of most Gemini sites. My issuer is LetsEncrypt, which should be fine.
Ben wrote: > My first attempt was to use geminid (written in C) because I figure it'd > compile most easily on my system, which runs FreeBSD. It did compile > easy, but I haven't gotten it to work just yet likely because of not > configuring it right. Hi Ben Oh man, it still was listening on port 2222, because that's one of the ports that are opened for outbound connections in my company's network. Sorry about that. It's now fixed. Also, thanks for considering my little project for serving your stuff. I wouldn't put it into production just yet, though... :) Cheers, J.
Johannes, Thanks for the quick reply! Let me know if you ever want me to test it, since I have it set up to compile on my system it would not be difficult.
On Fri, May 15, 2020 at 11:14:44AM +0430, Ben wrote: > I'm having an issue with elpher where it asks me to approve the site's SSL > cert because it says something like the issuer not being recognized... well > that can't be right, so either I set up Jetforce a little bit wrong > (specified the wrong files?), or this is some issue with elpher, which I > noticed complains about the certs of most Gemini sites. My issuer is > LetsEncrypt, which should be fine. I'm not sure because I haven't used it, but perhaps Elpher is one of the few clients (the other I know of is Bombadillo) which have implemented the TOFU security model recommended in the spec. Current implementations of Gemini are fairly inconsistent with how they handle TLS, which admittedly is my fault for speccing that clients can validate certs however they like and just "strongly recommending" TOFU. Many people have fallen back on the standard CA approach. Heck, my own client so far doesn't do any certificate validation at all! I'll be TOFUising it this weekend, though. Cheers, Solderpunk
On Fri, May 15, 2020 at 11:14:44AM +0430, Ben wrote: > After being a long-time subscriber to this list while having no idea what > Gemini (or even Gopher) is, I've gotten to the point of running my own > server. You should be able to access it at gemini://kwiecien.us/ Thanks for letting us know, I've added it to the list! Cheers, Solderpunk
Hi Ben, Ben writes: > I'm having an issue with elpher where it asks me to approve the site's > SSL cert because it says something like the issuer not being > recognized... well that can't be right, so either I set up Jetforce a > little bit wrong (specified the wrong files?), or this is some issue > with elpher, which I noticed complains about the certs of most Gemini > sites. My issuer is LetsEncrypt, which should be fine. Elpher just relies on Emacs' default Network Security Manager behaviour, as described in the manual: https://www.gnu.org/software/emacs/manual/html_node/emacs/Network-Security.html. I'm not sure why this is claiming your cert is invalid. I'll look into it, but I suspect the issue will be upstream from elpher. That aside, elpher (or rather the NSM) does tend to raise warnings about every new gemini site you visit since it's common to use self-signed certificates. While the spec-spec suggests a trust-on-first-use behaviour, this doesn't seem to be possible with the NSM. This exposes three security levels: "low", which doesn't do any security checks, "medium", which is the default level and is what you're experiencing, and "high", which is even more stringent. Thus I've had to choose between no certificate validation at all and the current system. Seeing as (a) the number of gemini sites has (until recently) been extremely small, (b) emacs remembers accepted self-signed/invalid certificates and doesn't ask again, and (c) at least one person has expressed a preference for more security rather than less, I've stuck with the "medium" setting. However, I suspect I'm going to have to reconsider this stance the near future due to the amazing number of new gemini hosts appearing. Cheers, Tim
solderpunk writes: > I'm not sure because I haven't used it, but perhaps Elpher is one of the > few clients (the other I know of is Bombadillo) which have implemented > the TOFU security model recommended in the spec. Current Sadly not. As I said in my reply to Ben, it essentially implements inverse-TOFU: distrust-on-first-use. Tim
On Thu, May 14, 2020 at 11:44 PM Ben <benulo at systemli.org> wrote: > I'm having an issue with elpher where it asks me to approve the site's > SSL cert because it says something like the issuer not being > recognized... well that can't be right, so either I set up Jetforce a > little bit wrong (specified the wrong files?), or this is some issue > with elpher, which I noticed complains about the certs of most Gemini > sites. My issuer is LetsEncrypt, which should be fine. > > Isn't that just because, by default, Jetforce generates it's own certificates and they are self-signed? When browsing with elpher I get this warning all the time, it seems everyone is using self signed certificates. For gemini://gem.bestalbumsintheuniverse.com I am also using Jetforce and accessing with elpher, but I don't get the warnings because I used Let's Encrypt to generate CA certificates. If you've used Let's Encrypt and certbot before, the process is the same as if you were setting up an https site, except that instead of passing the certs in an nginx or Apache config, you pass the cert paths to the Jetforce startup command. For example, here is the startup command I'm using for Jetforce: python3 jetforce.py --host "" --hostname gem.bestalbumsintheuniverse.com --tls-certfile fullchain.pem --tls-keyfile privkey.pem This is of course after I copied the fullchain.pem and privkey.pem files from the /etc/letsencrypt/live/gem.bestalbumsintheuniverse.com/ directory and chown'd them to the user that runs the jetforce server. Hope this helps! -Travis
Thanks Travis, I was using "cert.pem" of my host's LetsEncrypt files already, and they are known to be good for the other services I run. (None of them ever complained.) I switched to "fullchain.pem" to see if the result would be any different, but elpher says: >the certificate was signed by an unknown and therefore untrusted authority So I guess the issue is not the cert itself, but maybe emacs or elpher need something to know that LetsEncrypt is a trusted authority. But anyway, I can just permanently accept the cert so it's no big deal. On 5/15/20 10:05 PM, Travis Briggs wrote: > python3 jetforce.py --host "" --hostname > gem.bestalbumsintheuniverse.com > <http://gem.bestalbumsintheuniverse.com> --tls-certfile fullchain.pem > --tls-keyfile privkey.pem
On Fri, May 15, 2020 at 10:35:24AM -0700, Travis Briggs wrote: > it seems everyone is using self signed certificates. Not everyone, but many people, because the spec strongly encourages this, in conjunction with a ssh-style TOFU model. Few clients are doing this yet, but I hope that will change. I'm unsure about somethings, though; I'm going to start a conversation about this in the near future. Cheers, Solderpunk
---