On certificates and validation

[Björn Wärmedal]

> 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
*security* or objective *correctness* than, say, "ew0k's Server" or
even just "ew0k". If I decide that my client requires the hostname to
match one of those provided by the cert that's an entirely arbitrary
decision. In the best case it just gives me some more code to write,
while in the worst case it lulls users into a false sense of security.

> 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.

Let's say I as a sysadmin did that. Then my cert and domain
registration expired, and someone else snatched it up and presented
their own certificate. The gemini browsers would now tell users that
"there's a new cert here, and the previous had expired". What security
did we achieve in this scenario?

> 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.

I don't see how this is an argument for clients attempting to validate
the server certs... Did I misunderstand something here?

Consider this scenario: I have the domain tinyrabbit.ml (not serving
much of anything on any protocol, but still). Say I create a cert with
the CN "tinyrabbit.ml" and set up a gemini server there. I get
recurring visitors. After a few months I want to set up a subdomain
app.tinyrabbit.ml. Oh, shoot, I should have made that cert a wildcard.
Oh, well.

My choices are now to either create another certificate strictly for
app.tinyrabbit.ml, and then have two certs to keep track of. Or I
create a new certificate for "*.tinyrabbit.ml" to future proof it, and
serve this on the full domain. But now I opened a window for a MitM
attack -- or at least a lot of questions from concerned users who
wonder why my cert suddenly changed. Both of these are avoided if I
can just keep using the old certificate for the full domain, and no
security is lost.

> 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 probably have huge blindspots concerning cert handling in TLS
specifically, but I don't understand at all what this means in this
case o.õ

> Consider that the stakes are leaking your user's private information and
> do your goddamn job as a responsible steward of their needs.

I'm trying to do it. No need to be snarky.

Cheers,
ew0k