5 ms·

I feel like using web pki for client authentication doesn't really make sense in the first place. How do you verify the common name/subject alt name actually ma

by bawolff 9mo ago

I feel like using web pki for client authentication doesn't really make sense in the first place. How do you verify the common name/subject alt name actually matches when using a client cert. Using web pki for client certs seems like a recipe for disaster. Where servers would just verify they are signed but since anyone can sign then anyone can spoof. And this isn't just hypothetical. I remember xmlsec (a library for validating xml signature, primarily saml) used to use web pki for signature validation in addition to specified cert, which resulted in lot SAML bypasses where you could pass validation by signing the SAML response with any certificate from lets encrypt including the attackers.

nickf 9mo 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.
- xg15 9mo ago
  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.
  - Avamander 9mo ago
    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.
    - xg15 9mo ago
      Huh? The entire purpose of that EKU change was to disallow that usecase. How did that demonstrate problems for WebPKI?
      - Avamander 9mo ago
        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.
        xg15 9mo 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?
        Avamander 9mo ago
        That's being overly pedantic. PKIs for different purposes have been separate for a while, if not from the start. LE is still giving you a "TLS cert".
        bawolff 9mo ago
        You are being pedantic but also pedantically incorrect. Lets encrypt provides value by providing signed TLS certs that are enrolled in webPKI (i.e. trusted by browsers). If they were just provided a (not necessarily trusted) tls cert, like what anyone can generate from the command line, nobody would use them.
        ge0rg 9mo ago
        Let's Encrypt also provides value by providing signed TLS certificates that are enrolled in all major operating systems, and that can be used to authenticate any TLS server. This is a significant and important use case that's totally ignored by the "WebPKI" proponents, and there is no alternative infrastructure that would provide that value if WebPKI would e.g. decide to add certificate constraints limiting issued certificates to TCP/433.
    - ge0rg 9mo ago
      Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?
      - Avamander 9mo ago
        Can you point out at which point in time exactly it was designed to serve every use-case?
        ge0rg 9mo 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.
        Avamander 9mo 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?
    - account42 9mo ago
      Great circular reasoning there buddy.
  - bawolff 9mo 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)
    - xg15 9mo ago
      No, the problem it was solving was "how do I verify that an incoming connection is actually from xmpp.foo.com and not from an impostor?" You could also solve this with API keys or plain old authentication, but all of those require effort on xmpp.foo.com's side to specifically support your server. Client certs seem better suited in that regard. A server can generate a trusted client cert once, and then everyone else can verify connections from that server without having to do any prior arrangements with it.
xg15 9mo ago
> 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.
- nickf 9mo 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.
  - xg15 9mo ago
    > 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.
    - bawolff 9mo 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.
      - nickf 9mo ago
        Not really, no. There are a number of reasons for cert lifetimes being made shorter.
bawolff 9mo ago
Too late for an edit, i read a bit more about how xmpp works, i guess the cert is not really about network access controls or authenticating the connection, but authenticating the data is coming from the right server. So i guess that could make sense.
account42 9mo ago
In this case the client is connecting with a DNS name because it's also a server. This applies to XMPP and any other federated network. The CA verifies the subject just like any server certificate, which is what LE has already been doing. The server verifies the subject by checking that the name in the certificate matches the name the client is claiming to be.

by bawolff 9mo ago

nickf 9mo 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.

xg15 9mo ago
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.
- Avamander 9mo ago
  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.
  - xg15 9mo ago
    Huh? The entire purpose of that EKU change was to disallow that usecase. How did that demonstrate problems for WebPKI?
    - Avamander 9mo ago
      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.
      - xg15 9mo 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?
        Avamander 9mo ago
        That's being overly pedantic. PKIs for different purposes have been separate for a while, if not from the start. LE is still giving you a "TLS cert".
        bawolff 9mo ago
        You are being pedantic but also pedantically incorrect. Lets encrypt provides value by providing signed TLS certs that are enrolled in webPKI (i.e. trusted by browsers). If they were just provided a (not necessarily trusted) tls cert, like what anyone can generate from the command line, nobody would use them.
        ge0rg 9mo ago
        Let's Encrypt also provides value by providing signed TLS certificates that are enrolled in all major operating systems, and that can be used to authenticate any TLS server. This is a significant and important use case that's totally ignored by the "WebPKI" proponents, and there is no alternative infrastructure that would provide that value if WebPKI would e.g. decide to add certificate constraints limiting issued certificates to TCP/433.
  - ge0rg 9mo ago
    Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?
    - Avamander 9mo ago
      Can you point out at which point in time exactly it was designed to serve every use-case?
      - ge0rg 9mo 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.
        Avamander 9mo 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?
  - account42 9mo ago
    Great circular reasoning there buddy.
- bawolff 9mo 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)
  - xg15 9mo ago
    No, the problem it was solving was "how do I verify that an incoming connection is actually from xmpp.foo.com and not from an impostor?" You could also solve this with API keys or plain old authentication, but all of those require effort on xmpp.foo.com's side to specifically support your server. Client certs seem better suited in that regard. A server can generate a trusted client cert once, and then everyone else can verify connections from that server without having to do any prior arrangements with it.

xg15 9mo ago

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

nickf 9mo 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.
- xg15 9mo ago
  > 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.
  - bawolff 9mo 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.
    - nickf 9mo ago
      Not really, no. There are a number of reasons for cert lifetimes being made shorter.

bawolff 9mo ago

Too late for an edit, i read a bit more about how xmpp works, i guess the cert is not really about network access controls or authenticating the connection, but authenticating the data is coming from the right server. So i guess that could make sense.

account42 9mo ago

In this case the client is connecting with a DNS name because it's also a server. This applies to XMPP and any other federated network. The CA verifies the subject just like any server certificate, which is what LE has already been doing. The server verifies the subject by checking that the name in the certificate matches the name the client is claiming to be.