undefined

[-]

> How do you verify the common name/subject alt name actually matches when using a client cert.

This seems exactly like a reason to use client certs with public CAs.

You (as in, the server) cannot verify this at all, but a public CA could.

by nickf3 hours ago|

[-]

A public CA checks it one-time, when it's being issued. Most/all mTLS use-cases don't do any checking of the client cert in any capacity. Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to.

If it's for auth, issue it yourself and don't rely on a third-party like a public CA.

by ge0rg3 hours ago|

[-]

A federated ecosystem of servers that need to verify each other based on their domain name as the identity is the prime use-case for a public CA to issue domain-verified client certificates. XMPP happens to be this ecosystem.

Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort, essentially redoing all the hard work of LetsEncrypt, but without the major funding, thus ending up with an insecure solution.

We make use of the public CAs, that have been issuing TLS certificates based on domain validation, for quite a few years now, before the public TLS CAs have been subverted to become public HTTPS-only CAs by Google and the CA/Browser Forum.

[-]

> Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort

Rolling out a change that removes the EKU check would not be that much effort however.

[-]

That's exactly what prosody is doing, but it's a weird solution. Essentially, they're just ignoring the missing EKU flag and pretend it would be there, violating the spec.

It seems weird to first remove the flag and then tell everyone to update their servers to ignore the removal. Then why remove it in the first place?

by Avamander2 hours ago|

[-]

I think you're confusing different actors here. The change was made by the CA/B Forum, the recommendation is just how it is if you want to use a certificate not for the purposes intended.

by ge0rg2 hours ago|

[-]

Yes, this is what is happening. It isn't happening fast enough, so some implementations (especially servers that don't upgrade often enough, or running long-term-support OS flavors) will still be affected. This is the impact that the original article is warning about.

My point was that this is yet another change that makes TLS operations harder for non-Web use cases, with the "benefit" to the WebPKI being the removal of a hypothetical complexity, motivated by examples that indeed should have used a private PKI in the first place.

[-]

> A public CA checks it one-time, when it's being issued.

That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes".

> Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to.

Not an expert there, but isn't the point of EV that the CA verified the "real life entity" that requested the cert? So then it depends on what kind of access model the finance company was specifying for its API. "I don't care who is using my API as long as they are a company" is indeed a very stupid access model, but then I think the problem is deeper than just cert validation.

by bawolff1 hours ago|

[-]

> That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes".

No it isn't, and that's not the reason why cert lifetimes are getting smaller.

Cert lifetimes being smaller is to combat certs being stolen, not man in the middle attacks.

by nickf4 hours ago|

[-]

You are correct, and the answer is - no-one using publicly-trusted TLS certs for client authentication is actually doing any authentication. At best, they're verifying the other party has an internet connection and perhaps the ability to read.

It was only ever used because other options are harder to implement.

[-]

It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com. Now I get some random incoming connection. How would I verify that this connection indeed originates from xmpp.bar.com? LE-assigned client certs sound like a good solution to that problem.

by bawolff1 hours ago|

[-]

> It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com.

If you already trust xmpp.foo.com, then you probably shouldn't be using PKI, as PKI is a complex system to solve the problem where you don't have preexisting trust. (I suppose maybe PKI could be used to help with rolling over certs)

[-]

Which is almost exactly why WebPKI doesn't want to support such use-cases. Just this EKU change alone demonstrates how it can hinder WebPKI changes.

by ge0rg3 hours ago|

[-]

Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?

[-]

Can you point out at which point in time exactly it was designed to serve every use-case?

by ge0rg2 hours ago|

[-]

The public TLS PKI was never supposed to serve every use case and you know it. But let me point out when it was possible to get a public CA certificate for an XMPP server with SRVname and xmppAddr:

  Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1096750 (0x10bc2e)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
        Validity
            Not Before: May 27 16:16:59 2015 GMT
            Not After : May 28 12:34:54 2016 GMT
        Subject: C = DE, CN = chat.yax.im, emailAddress = hostmaster@yax.im
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:chat.yax.im, DNS:yax.im, xmppAddr:chat.yax.im, dnsSRV:chat.yax.im, xmppAddr:yax.im, dnsSRV:yax.im

Ironically, this was the last server certificate I obtained pre-LetsEncrypt.

by Avamander2 hours ago|

[-]

So you understand that there are different purposes as well. Are you saying that you can't get a client auth certificate any more?

[-]

Huh? The entire purpose of that EKU change was to disallow that usecase. How did that demonstrate problems for WebPKI?

[-]

This post here is the demonstration, that some non-WebPKI purpose is causing issues and complaints. This has happened before with SHA-1 deprecation. WebPKI does not want this burden and should not have this burden.

by xg152 hours ago|

[-]

Ok, so this is an official split of "WebPKI" and "everything else PKI" then?

Last time I checked, Let's Encrypt was saying they provide free TLS certs, not free WebPKI certs. When did that change?

by Avamander2 hours ago|