3 ms·
Client authentication with publicly-trusted (i.e. chaining to roots in one of the major 4 or 5 trust-store programs) is bad. It doesn't actually authenticate an
by nickf 8mo ago
Client authentication with publicly-trusted (i.e. chaining to roots in one of the major 4 or 5 trust-store programs) is bad. It doesn't actually authenticate anything at all, and never has.
No-one that uses it is authenticating anything more than the other party has an internet connection and the ability, perhaps, to read.
No part of the Subject DN or SAN is checked. It's just that it's 'easy' to rely on an existing trust-store rather than implement something secure using private PKI.
Some providers who 'require' public TLS certs for mTLS even specify specific products and CAs (OV, EV from specific CAs) not realising that both the CAs and the roots are going to rotate more frequently in future.
- ajross 8mo agoA client cert can be stored, so it provides at least a little bit of identification certainty. It's very hard to steal or impersonate a specific client cert, so the site has a high likelihood of knowing you're the same person you were when you connected before (even though the initial connection may very well not have ID'd the correct person!). That has value. But it also doesn't involve any particular trust in the CA either. Lets Encrypt has nothing to offer here so there's no reason for them to try to make promises.
- nickf 8mo agoEh, it's pretty easy to impersonate if the values in the certificate aren't checked, and you could get one from any of a list of public CAs. If you're relying on a certificate for authentication - issue it yourself.
- ajross 8mo agoPoint being that if you get a valid TLS connection from a client cert, and then you get another valid connection from the same cert tomorrow, you can be very certain that the entity connecting is either the same software environment that connected earlier, or an attacker that has compromised it. You can be cryptographically certain that it is not an attacker that hasn't effected a full compromise of your client. And there's value there, if you're a server. It's why XMPP wants federated servers to authenticate themselves with certificates in the first place.
- ahmedtd 8mo agoIf that's all you want to accomplish, you don't need WebPKI. Just generate a private key and a self-signed certificate. (This is basically how Let's Encrypt / ACME accounts work)
- jeroenhd 8mo agoHow do I convince the tens of thousands of other servers that my private key can be trusted without some kind of third party trust architecture? There's DANE but outside of maybe two countries that's impractical to set up because DNS providers keep messing up DNSSEC.
- the456gamer 8mo agoIf you are trusting a user since they are the same one that originally contacted you, you don't. It's tofu
- lmz 8mo agoI can't believe this was downvoted. Seriously a Certificate is binding a public key and the attributes (mainly the identity). If you don't need to use the attributes, you don't need a certificate!
- ajross 8mo ago> This is basically how Let's Encrypt / ACME accounts work That's how they're implemented. How they "work" is a trivial pushbutton thing as documented by a well-known and trusted provider who cares deeply about simple user experience. "Just self-sign a cert" is very much not the story XMPP wants their federated server operators to deal with.
- nightpool 8mo agoNo part of the Subject DN or SAN is checked. Is this true of XMPP? I thought it enforced that the SAN matched the XMPP identifier in question