💾 Archived View for gemi.dev › gemini-mailing-list › 000495.gmi captured on 2024-08-19 at 00:55:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I'm building a lib to simplify gemini client development in python, and my current headache is certification handling. There's a few things that come to mind, some more philosophical than technical in nature.
On Wed Nov 25, 2020 at 7:58 AM EST, Bj?rn W?rmedal wrote: > I'm building a lib to simplify gemini client development in python, > and my current headache is certification handling. There's a few > things that come to mind, some more philosophical than technical in > nature. > > * Should I support verification of CA-issued certificates, or > self-signed only? Doing both at the same time leads to a "try this, if > fail then try this" sort of situation which isn't very pretty. How > common are CA-issued certificates in geminispace, and should they be > handled differently than TOFU? I strongly recommend not checking for CA-signed certificates, and only supporting TOFU. > * How does one even validate a self-signed cert? If ew0k.example.com > serves a certificate with the Common Name "ew0k's Awesome Site" and no > Subject Alternative Names, is that less valid than one that includes > the hostname? Or the IP? Does expiration time matter at all for a > self-signed cert? Yes, test the common name and/or alternative names, and the expiration time. > * When a browser has accepted one cert for example.com but is > presented another on the next visit, it shows a warning to the user > who will then decide whether to accept the new cert. What information > allows a user to make an informed decision in this case? Does it > matter that the last cert would still be valid for another 3 years? Or > 2 months? The SHA-256 of the certificate is helpful in this, because they use it to verify the certificate's authenticity out of band (e.g. email the operator, call a friend on a different ISP, etc). You may find this article I wrote on TOFU helpful: gemini://drewdevault.com/2020/09/21/Gemini-TOFU.gmi
> > * How does one even validate a self-signed cert? If ew0k.example.com > > serves a certificate with the Common Name "ew0k's Awesome Site" and no > > Subject Alternative Names, is that less valid than one that includes > > the hostname? Or the IP? Does expiration time matter at all for a > > self-signed cert? > > Yes, test the common name and/or alternative names, and the expiration > time. So basically at least one of Common Name and Subject Alternative Names should match the hostname provided? What if it doesn't, but it matches the IP? I guess I could press this issue even more, really. There's a technical difficulty in parsing wildcards, for example, depending on the libs available. If I request some.subdomain.example.com and the certificate lists "some.*.example.com" the ssl._dnsname_match() method in python3 won't be able to match it despite it being a valid wildcard (afaik). I don't really know what the certificate specification says here, but with self-signed certs we can write pretty much anything. My example of a Common Name that doesn't have a hostname would fail under your validation algorithm, but is it objectively *wrong*? Under a TOFU scheme I could also encounter a situation where a cert I have accepted has now expired, but the server still provides it. Is it
On Wed Nov 25, 2020 at 8:16 AM EST, Bj?rn W?rmedal wrote: > So basically at least one of Common Name and Subject Alternative Names > should match the hostname provided? What if it doesn't, but it matches > the IP? Hm, I'm not sure. Check the spec? I have never put an IP address into a certificate. > I guess I could press this issue even more, really. There's a > technical difficulty in parsing wildcards, for example, depending on > the libs available. If I request some.subdomain.example.com and the > certificate lists "some.*.example.com" the ssl._dnsname_match() method > in python3 won't be able to match it despite it being a valid wildcard > (afaik). I don't really know what the certificate specification says > here, but with self-signed certs we can write pretty much anything. Technically you can make up your own CA and sign whatever bullshit certs you want. So what? That doesn't change the interpretation of the specification. > My example of a Common Name that doesn't have a hostname would fail > under your validation algorithm, but is it objectively *wrong*? Yes. > Under a TOFU scheme I could also encounter a situation where a cert I > have accepted has now expired, but the server still provides it. Is it > *wrong* to still accept it? Yes.
Something worth mentioning is that the reason I discourage the use of CAs and encourage some baseline sanity checks on certificate validity is because I don't expect sysadmins to be handling certificates at all. Certificates are annoying and easily fucked up. That easily-fucked-up bit is probably why you're hand-wringing over whether or not to accept invalid certificates. However, with TOFU, there's no reason for sysadmins to generate their own certificates at all. My server software (gmnisrv) handles certificate generation and rotation entirely automatically, without any help from the sysadmin whatsoever. They cannot make a mistake because the software does it for them, and the software does it correctly. With a TOFU system like Gemini, there's no reason whatsoever that we should bring along the legacy nonsense of certificate authorities and manual human-operated certificate maintanence.
> I strongly recommend not checking for CA-signed certificates, and only > supporting TOFU. +1 However, an observation: If one goes for TOFU, please make the key expiry times decades or even centuries long. The expiry date is the point at which a man in the middle attack is certain to work [*] - the weakness of TOFU. This is a much graver concern than a hypothetical key compromise or similar. My cynical view is that expiration dates were added to guarantee certification authorities a steady revenue stream. Ssh doesn't expire its keys, and isn't worse for that. [*] If you can use the old key to validate the new one, then this is a different matter. regards marc
> Ssh doesn't expire its keys, and isn't worse for that. This is the analogue I was looking for. SSH doesn't care about Common Name or other cruft in the cert, either. I agree that some sort of sanity check is nice, but at the same time I have trouble finding a philosophical or practical reason for doing any sort of validation on first use, and any beyond "same as last time" on subsequent visits. Yes, Drew says I should. But are there any arguments supporting that position? Cheers, ew0k
On Thu Nov 26, 2020 at 6:02 AM EST, Bj?rn W?rmedal wrote: > > Ssh doesn't expire its keys, and isn't worse for that. > > This is the analogue I was looking for. SSH doesn't care about Common > Name or other cruft in the cert, either. We use TLS, not SSH. > I agree that some sort of sanity check is nice, but at the same time I > have trouble finding a philosophical or practical reason for doing any > sort of validation on first use, and any beyond "same as last time" on > subsequent visits. > > Yes, Drew says I should. But are there any arguments supporting that > position? These are configurable parameters. If they are configured incorrectly, then we should reject the certificate. Someone may have configured them with an expiration, for example, by design, knowing that their server would soon disappear, and that certificate reuse signals that something stinky is going on. Or the common name could be set because the admin has chosen to set up their own certificate authority, perhaps complete with signed client-side certificates, and the common name is used to strongly identify the server. Consider that the stakes are leaking your user's private information and do your goddamn job as a responsible steward of their needs.
On Thu, Nov 26, 2020 at 6:02 AM Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > > > Ssh doesn't expire its keys, and isn't worse for that. > > This is the analogue I was looking for. SSH doesn't care about Common > Name or other cruft in the cert, either. > > I agree that some sort of sanity check is nice, but at the same time I > have trouble finding a philosophical or practical reason for doing any > sort of validation on first use, and any beyond "same as last time" on > subsequent visits. > > Yes, Drew says I should. But are there any arguments supporting that position? > I fully agree that the expiration date is useless in TOFU schemes. I brought this up on the mailing list a while ago and I didn't see any rebuttals that really convinced me otherwise. The mailing list settled on recommending a long expiration times of several years, but that was just dodging the fundamental problem IMO. I think it will still take folks a while to come around to this conclusion. Thank you for giving me some hope :) I didn't make the logical jump at the time, but certificate hostnames are similarly useless in TOFU for the same reason. They don't verify anything since they can be trivially forged. On Thu, Nov 26, 2020 at 8:04 AM Drew DeVault <sir at cmpwn.com> wrote: > These are configurable parameters. If they are configured incorrectly, > then we should reject the certificate. Someone may have configured them > with an expiration, for example, by design, knowing that their server > would soon disappear, and that certificate reuse signals that something > stinky is going on. The expiration date does not protect against anything in this scenario. An attacker can trivially generate a new certificate to send to the client if they see the old one has expired. > Or the common name could be set because the admin > has chosen to set up their own certificate authority, perhaps complete > with signed client-side certificates, and the common name is used to > strongly identify the server. Now you're talking about CA verified certificates. There's nothing wrong with using self-signed CAs, but it's a completely different security model than TOFU and shouldn't be confused with it. - Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/f8b6 4432/attachment-0001.htm>
On Thu Nov 26, 2020 at 1:41 PM EST, Michael Lazar wrote: > Now you're talking about CA verified certificates. There's nothing > wrong with using self-signed CAs, but it's a completely different > security model than TOFU and shouldn't be confused with it. Mostly correct. What we have is TOFU on top of TLS, not just TOFU. And because these parameters are present, it's likely that someone may rely on them. And if they do, and put their personal security on the line for it, then we can hardly call that a mistake. Gemini uses TLS. That comes with warts. That's life.
On Thu, Nov 26, 2020 at 1:43 PM Drew DeVault <sir at cmpwn.com> wrote: > > On Thu Nov 26, 2020 at 1:41 PM EST, Michael Lazar wrote: > > Now you're talking about CA verified certificates. There's nothing > > wrong with using self-signed CAs, but it's a completely different > > security model than TOFU and shouldn't be confused with it. > > Mostly correct. What we have is TOFU on top of TLS, not just TOFU. And > because these parameters are present, it's likely that someone may rely > on them. And if they do, and put their personal security on the line for > it, then we can hardly call that a mistake. > > Gemini uses TLS. That comes with warts. That's life. I like to think of gemini as TLS + TOFU whereas the web uses TLS + PKI. TLS by itself is not a complete security model without something on top of it to establish trust. We're talking about validating x509 certs here which were literally designed to work with PKI [0]. Using them in any other context is throwing the whole security model out the window. Nobody can "rely" on x509 parameters in that sense. They might think they can, and giving them that false sense of security is the wrong thing to do. (are there other types of certs that can be used with TLS? I have no idea, but if so I bet they aren't supported by openssl...) - Michael [0] https://tools.ietf.org/html/rfc5280
> These are configurable parameters. If they are configured incorrectly, > then we should reject the certificate. First of all, you're completely right. They are configurable parameters. Which also means that a matching hostname or valid date range means absolute zilch, sadly. It's just letters and numbers. Secondly, I'd be much obliged if you could define "incorrectly" in some objective manner. I see how it's more informative to use my hostname as Common Name or SAN, but I don't see that it gives any more
On Thu, Nov 26, 2020 at 1:41 PM Michael Lazar <lazar.michael22 at gmail.com>
wrote:
> I fully agree that the expiration date is useless in TOFU schemes.
>
However, they make all kinds of sense in client certs. If you see an
expired cert coming from a client, it is most likely a replay attack (or a
broken client). If the client cert is meant for user identification, you
will of course need to provide the hash of the newly created cert to the
server administrator.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
How comes city and country to be filled with drones and rogues, our highways
with hackers, and all places with sloth and wickedness?
--W. Blith, Eng. Improver Improved, 1652
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/6022
1352/attachment.htm>
On Thu, Nov 26, 2020 at 7:04 PM John Cowan <cowan at ccil.org> wrote: > > On Thu, Nov 26, 2020 at 1:41 PM Michael Lazar <lazar.michael22 at gmail.com> wrote: > >> I fully agree that the expiration date is useless in TOFU schemes. > > However, they make all kinds of sense in client certs. If you see an expired > cert coming from a client, it is most likely a replay attack (or a broken > client). If the client cert is meant for user identification, you will of > course need to provide the hash of the newly created cert to the server > administrator. I think you're referring to a compromised client certificate and not a replay attack [0]. If you truly mean replay attack as in a MITM where neither the client or server has been compromised, I would be *very* interested in learning more about this because I thought the TLS handshake was resistant to this type of replay. On compromised client certificates: A compromised client certificate is in the same boat that a compromised server certificate would be in. There is no recourse within the TOFU model. You can rotate the cert, but the expiration date doesn't protect you against anything. Sending new fingerprints to the server administrator out-of-band would surely work, but you are no longer using trust on first use. You can argue that TOFU is a crappy model for client certificates since client certs are typically used to grant access to verified identities. I would mostly agree with that, although working on astrobotany has shown me that there
---