💾 Archived View for gemi.dev › gemini-mailing-list › 000766.gmi captured on 2024-08-19 at 01:59:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello, I have been using lagrange for a few months to browse Gemini, and I realize that I?m already making a habit of ignoring certificate mismatch warnings, and blindly trusting any certificate that shows. The certificate trust is one of the weak point of the current specification I think, and it would need to be clarified. Firstly, there is the idea of TOFU, but it does not say on which part of the certificate the TOFU works (some people consider it?s the whole certificate, some only the fingerprint), and it does not say how much the certificate needs to be valid (I?ve seen on the ML some people considering that a wrong domain in a certificate and a past expiration date should be ignored by clients). Reading the specification it appears that it recommends using fingerprint and to consider past expiration date invalid. Secondly, there is the good old CA system, nowadays mostly using letsencrypt. It seems badly supported in most clients which still use TOFU in this case and will complain at each renewal. A third possibility I think would be to use DANE and base validation on the DNS system, but I?ve not seen anyone advocating this, is there anything wrong with that idea? I?m failing to see how TOFU can provide any security, especially if there is no way to announce a renewal by sending both new and old cert or something, there is a MITM possibility at each renewal. The only TOFU example I?ve seen cited is openssh, which seems offtopic because you usually do not ssh into random machine on the internet by following links like you do with Gemini. C?me
On Sun, 28 Feb 2021 20:27:26 +0100 C?me Chilliet <come at chilliet.eu>: > Hello, > > I have been using lagrange for a few months to browse Gemini, and I realize that I?m already making a habit of ignoring certificate mismatch warnings, and blindly trusting any certificate that shows. > > The certificate trust is one of the weak point of the current specification I think, and it would need to be clarified. > > Firstly, there is the idea of TOFU, but it does not say on which part of the certificate the TOFU works (some people consider it?s the whole certificate, some only the fingerprint), and it does not say how much the certificate needs to be valid (I?ve seen on the ML some people considering that a wrong domain in a certificate and a past expiration date should be ignored by clients). Reading the specification it appears that it recommends using fingerprint and to consider past expiration date invalid. > Secondly, there is the good old CA system, nowadays mostly using letsencrypt. It seems badly supported in most clients which still use TOFU in this case and will complain at each renewal. > A third possibility I think would be to use DANE and base validation on the DNS system, but I?ve not seen anyone advocating this, is there anything wrong with that idea? > > I?m failing to see how TOFU can provide any security, especially if there is no way to announce a renewal by sending both new and old cert or something, there is a MITM possibility at each renewal. The only TOFU example I?ve seen cited is openssh, which seems offtopic because you usually do not ssh into random machine on the internet by following links like you do with Gemini. > > C?me > > Hi, I suggested something on IRC a while ago, I'm not sure this would be a good idea but I'll share it here. Instead of TOFU, 2 mecanisms could be used: 1) Check chain of trust of the certificate, with let's encrypt and other provider (they are not alone anymore) it's easy to get a valid certificate 2) If 1 is invalid, let's (introduce something new here) check if DNS doesn't have a TXT field with the certificate fingerprint and see if it matches the current one, accept if OK 3) if 2 found a TXT that doesn't match, tell the user, if it matches, accepts, if no TXT, TOFU? The fingerprint published in DNS is already done for SSH fingerprint using a SSHFP field. This allows to have a third party check. I agree it's not absolutely perfect but, it gives the opportunity for an extra check. This wouldn't have any backward incompatibilities because it's up to the client to implement it, if a person hosting a gemini server doesn't want to host it, just do TOFU as usual.
On Sun, 28 Feb 2021, C?me Chilliet wrote: > I?m failing to see how TOFU can provide any security, especially if Does SSH provide any security? Mk -- Martin Keegan, @mk270, https://mk.ucant.org/
On Sun, 28 Feb 2021 22:07:52 +0000 (GMT) Martin Keegan <martin at no.ucant.org>: > On Sun, 28 Feb 2021, C?me Chilliet wrote: > > > I?m failing to see how TOFU can provide any security, especially if > > Does SSH provide any security? > > Mk > With ssh you can use https://en.wikipedia.org/wiki/SSHFP_record to improve the security for first connection.
On Sun, Feb 28, 2021 at 08:32:53PM +0100, Solene Rapenne said unto me: > 2) If 1 is invalid, let's (introduce something new here) check if > DNS doesn't have a TXT field with the certificate fingerprint and > see if it matches the current one, accept if OK I think this is the perfect use of the TLSA record, instead of introducting a new use of TXT. It is already used by DANE to provide trust outside of the CA structure. --Matt --- Matthew Ernisse matt at going-flying.com https://www.going-flying.com/
> 2) If 1 is invalid, let's (introduce something new here) check if > DNS doesn't have a TXT field with the certificate fingerprint and > see if it matches the current one, accept if OK Unless your computer is using DoH or DoT (or DNSSEC?? Not sure) then your DNS lookup isn't secure either. If your adversary can sit in between your traffic and change a capsule's TLS certificate than I don't see why DNS would be very different. Seems like this just adds complexity but without benefit. makeworld
It was thus said that the Great Solene Rapenne once stated: > On Sun, 28 Feb 2021 20:27:26 +0100 > C?me Chilliet <come at chilliet.eu>: > > > I?m failing to see how TOFU can provide any security, especially if > > there is no way to announce a renewal by sending both new and old cert > > or something, there is a MITM possibility at each renewal. The only TOFU > > example I?ve seen cited is openssh, which seems offtopic because you > > usually do not ssh into random machine on the internet by following > > links like you do with Gemini. > > I suggested something on IRC a while ago, I'm not sure this would be a > good idea but I'll share it here. > > Instead of TOFU, 2 mecanisms could be used: > > 1) Check chain of trust of the certificate, with let's encrypt and other > provider (they are not alone anymore) it's easy to get a valid certificate The viability of this approach may depend upon the TLS library used. I use libtls, and I really only have two options: 1. Do the whole CA thang and let the underlying TLS library validate the certificate. 2. Do no validatation whatsoever, leaving the validation up to the client. To do this, I would have to disable validation entirely, and do it manually, dipping into the nasty API that is OpenSSL. I would have to check other servers to see how they are handling this and if I could do the same thing. > 2) If 1 is invalid, let's (introduce something new here) check if > DNS doesn't have a TXT field with the certificate fingerprint and > see if it matches the current one, accept if OK > > 3) if 2 found a TXT that doesn't match, tell the user, if it matches, > accepts, if no TXT, TOFU? The general problem with this is not the actual DNS RR used (TXT, SSHFP, etc), it's making the DNS call itself. If you haven't dived into the mess that is DNS and resolving libriaries, it gets about as nasty as TLS with about a half dozen libraries that aren't compatible at all. POSIX systems come with getaddrinfo(), but that only covers A and AAAA record types. If you want *any* other type of DNS record, you are pretty much forced to either use one of the horrible DNS resolving libraries or roll your own. I would tout my own DNS library [1], but it's in C (and has a Lua wrapper for it). I'm not saying this is a bad idea. I'm just saying there are issues with it ... -spc [1] https://github.com/spc476/SPCDNS
On Sun, 28 Feb 2021, Solene Rapenne wrote: >>> I?m failing to see how TOFU can provide any security, especially if >> >> Does SSH provide any security? > > With ssh you can use https://en.wikipedia.org/wiki/SSHFP_record > to improve the security for first connection. We are using two different definitions of "security". SSH, even without SSHFP, still provides security. The question is what is the threat model. Mk -- Martin Keegan, @mk270, https://mk.ucant.org/
> On Mar 1, 2021, at 02:27, Matthew Ernisse <matt at going-flying.com> wrote: > > perfect use of the TLSA record Oh, yes: https://www.cloudns.net/wiki/article/342/ https://tools.ietf.org/html/rfc6698 So many DNS records to keep track of :) On the other hand, TXT records are the universal DNS bandaid: easy to use, multi-purpose. ?0?
> On Mar 1, 2021, at 02:48, colecmac at protonmail.com wrote: > > DNSSEC Yes, one still needs a chain of trust of some sort. Turtles all the way down. ?0?
On Sun, Feb 28, 2021 at 08:27:26PM +0100, C?me Chilliet <come at chilliet.eu> wrote a message of 32 lines which said: > The certificate trust is one of the weak point of the current > specification I think, and it would need to be clarified. I agree with your statement. With the new issue tracking system that Sean configured, this is ticket #5 <https://gitlab.com/gemini-specification/protocol/-/issues/5>. > Secondly, there is the good old CA system, nowadays mostly using > letsencrypt. It seems badly supported in most clients which still > use TOFU in this case and will complain at each renewal. More precisely, each renewal, BY DEFAULT. But Let's Encrypt lets you request that we keep the public key, and then TOFU will still work iff it acts on the public key only. If you use the ACME client dehydrated, this is in the configuration file: PRIVATE_KEY_RENEW="no" With the ACME client certbot, this is an option on the command-line: --reuse-key > A third possibility I think would be to use DANE and base validation > on the DNS system, but I?ve not seen anyone advocating this, is > there anything wrong with that idea? This is certainly the best solution, technically speaking. Unfortunately, adding DANE support to your Gemini client typically requires some effort, the existing libraries are typically not sufficient. (Full disclosure: I did not even add DANE support to my own Gemini client, despites the fact I'm strongly pro-DANE.) Also, the Internet is very ossified by broken middleboxes (typically firewalls but not only them) and TLSA requests may be blocked (or, worse, any DNSSEC use, which DANE requires). This is something to keep in mind. > I?m failing to see how TOFU can provide any security, especially if > there is no way to announce a renewal by sending both new and old > cert or something, there is a MITM possibility at each renewal. The > only TOFU example I?ve seen cited is openssh, which seems offtopic > because you usually do not ssh into random machine on the internet > by following links like you do with Gemini. I fully agree. TOFU is great for SSH but Gemini is completely different.
On Mon, Mar 01, 2021 at 01:48:02AM +0000, colecmac at protonmail.com <colecmac at protonmail.com> wrote a message of 13 lines which said: > Unless your computer is using DoH or DoT (or DNSSEC?? Not sure) then > your DNS lookup isn't secure either. I fail to see the relationship with DoT and DoH. If you care about integrity and authenticity of DNS answers, DNSSEC is the solution. (This is why DANE requires it.)
On Sun, Feb 28, 2021 at 10:07:02PM -0500, Sean Conner <sean at conman.org> wrote a message of 56 lines which said: > If you want *any* other type of DNS record, you are pretty much > forced to either use one of the horrible DNS resolving libraries or > roll your own. I would tout my own DNS library [1], but it's in C > (and has a Lua wrapper for it). C programmers are lucky, there are two excellent free, documented, maintained and complete libraries to do DNS requests, ldns <https://www.nlnetlabs.nl/projects/ldns/> and getdns <https://getdnsapi.net/>. Python programmers have one, dnspython <https://www.dnspython.org/>. Other languages? it depends. Last time I checked for Elixir, it was not good.
On Sun, Feb 28, 2021 at 11:16:47PM +0100, Solene Rapenne <solene at perso.pw> wrote a message of 15 lines which said: > With ssh you can use https://en.wikipedia.org/wiki/SSHFP_record > to improve the security for first connection. Or you can, if you care about the first connection, ask the sysadmin about the public key to expect, and check it yourself. As C?me Chilliet explained, that's the *huge* difference between SSH and Gemini; with SSH, you typically connect to only a few servers and you know their admins (and they know you).
Hi, > On 1. Mar 2021, at 10:26, Stephane Bortzmeyer <stephane at sources.org> wrote: > > On Sun, Feb 28, 2021 at 10:07:02PM -0500, > Sean Conner <sean at conman.org> wrote > a message of 56 lines which said: > >> If you want *any* other type of DNS record, you are pretty much >> forced to either use one of the horrible DNS resolving libraries or >> roll your own. I would tout my own DNS library [1], but it's in C >> (and has a Lua wrapper for it). > > C programmers are lucky, there are two excellent free, documented, > maintained and complete libraries to do DNS requests, ldns > <https://www.nlnetlabs.nl/projects/ldns/> and getdns > <https://getdnsapi.net/>. > > Python programmers have one, dnspython <https://www.dnspython.org/>. > > Other languages? it depends. Last time I checked for Elixir, it was > not good. > No need to do manual/extra DNS queries to verify certificates via DANE. GnuTLS has DANE validation build in <https://www.gnutls.org/manual/html_node/Verifying-a-certificate-using-DANE.html> and OpenSSL has that as well <https://www.openssl.org/docs/man1.1.0/man3/SSL_dane_enable.html> Greetings Carsten
Le lundi 1 mars 2021, 10:42:15 CET cas a ?crit : > No need to do manual/extra DNS queries to verify certificates via DANE. > > GnuTLS has DANE validation build in > <https://www.gnutls.org/manual/html_node/Verifying-a-certificate-using-DANE.html> > > and OpenSSL has that as well > <https://www.openssl.org/docs/man1.1.0/man3/SSL_dane_enable.html> This is great news, but on an other subthread Stephane said: > This is certainly the best solution, technically > speaking. Unfortunately, adding DANE support to your Gemini client > typically requires some effort, the existing libraries are typically > not sufficient. (Full disclosure: I did not even add DANE support to > my own Gemini client, despites the fact I'm strongly pro-DANE.) Who is right? I would feel really comfortable building on a existing bloc like DANE as this way there is a lot more chance to see libraries supporting it than if we use something Gemini-specific. C?me
On Mon, Mar 01, 2021 at 11:44:06AM +0100, C?me Chilliet <come at chilliet.eu> wrote a message of 25 lines which said: > Who is right? Both :-) Programmers may not have a version of OpenSSL or GnuTLS recent enough, or they may use another TLS library, or the binding to GnuTLS/OpenSSL they use for their favorite programming language may not expose DANE validation yet.
> On Mar 1, 2021, at 11:44, C?me Chilliet <come at chilliet.eu> wrote: > > Who is right? No one. Everyone. It depends. It's self-inflicted as well, as Gemini insists on mandating TLS ? without having thought through how to actually use it, nor if it's even relevant to the protocol usage. It's also dogmatic: not every contexts require TLS. It could as well be redundant: different contexts may already provide their own security layer(s). It may also introduce build-in obsolescence: a few years ago, Gemini would have mandated SSL. What now? There is an easy way out of this conundrum: move the mechanical details of how to connect to a Gemini service out of the specification. Provide instead connection profiles, such as Protocol Labs' multiaddr or similar: https://multiformats.io/multiaddr/ That way, the gory details on how to connect to a Gemini service (THE HOW) is separated from the Gemini specification itself (THE WHAT). ?0?
Am 28.02.21 um 23:07 schrieb Martin Keegan: > On Sun, 28 Feb 2021, C?me Chilliet wrote: > >> I?m failing to see how TOFU can provide any security, especially if > > Does SSH provide any security In all of my life I used ssh to administer servers which had been my own or had been owned by the company I had been working on. So, if I set up a server from scratch I always did know exactly, why my ssh did warn me about a mismatch. Using servers of others gives a totally different situation. I don't know anything why or by whom a certificate had been changed. Anyways, if I gave trust to somebody the first time, why should I not trust him the next time? No matter for me if I'm just reading Gemini pages. Martin
---