6 ms·

I"m not sure exactly what client-side certificates means here, but I have long wondered why we can't just use public key/private key authentication for most log

by bo1024 6y ago

I"m not sure exactly what client-side certificates means here, but I have long wondered why we can't just use public key/private key authentication for most logins. Is it the same?

mortehu 6y ago
Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication, and a very small number of websites supported it. After Chrome became popular, those sites were forced to switch to a different form of second factor authentication, and it's fallen almost completely out of use. Part of the reason was that the user interfaces for installing certificates were terrible, and websites needed to have guides on how to use it in each browser.
- bo1024 6y ago
  Thanks. I’m still not clear what the authentication method is, but I don't see why we can’t have a one click browser button “give this site my public key” and another “authenticate to this site with my private key”.
  - chipsa 6y ago
    Who gives you the private key? Is it generated on the device? How do you move the keys to your different devices? I can end up working at any of 20 computers on a given day, not counting my personal devices.
    - bo1024 6y ago
      Not sure what the best solution is, but some thoughts. First, you definitely want a different keypair per device. One approach is to just supplement passwords. You could use a password (2FA, etc) to log in, then the site gives you the option of adding that device's public key and from then on you can log in on that device automatically. The site would maintain a list of public keys associated with your account, just like github does for repositories. Of course, if you don't trust those 20 work computers, you wouldn't want it set up so that anyone using them can log in to all your accounts. One thing the browser could do is password-protect your private key, so you have to enter the master password when you start the browser, and as long as you remember to exit out of the browser, the next person to use it won't be able to use your logins.
- Avamander 6y ago
  > Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication Chrome has an interface for it.
  - mortehu 6y ago
    Last I checked it could only install from the filesystem, and not directly generate a key and install a certificate through the web. Do you have an example site where this works with Chrome?
    - jessaustin 6y ago
      Has the goalpost been moved? Upthread you compared Chrome to "all popular web browsers [which] had a user interface for installing client side HTTPS certificates for user authentication". I just opened up Firefox, and found a very similar menu to Chrome's: the only option was to "import" a cert from the filesystem. I agree that we should expect more from our tools, but has any popular browser ever allowed the user to generate a new cert? If one were to do so, how would the generated cert be connected to PKI -- who would sign the cert and how would they do that?
      - mortehu 6y ago
        Yes, browsers other than Chrome can generate keys, submit the public key to a site you're logged into and install the certificate you get in response (usually after a second factor verification). I am not aware of any site that still does this, so I can't show it to you. Skandiabanken in Norway used to do it before Chrome. You won't be able to see this in Firefox in any way other than visiting such a site.
        jessaustin 6y ago
        Now I'm curious. This seems like a procedure that would need to be precisely defined. Is there a standard protocol for this? Does it have an RFC or similar I could read? If nothing else, it would be nice to have a short bumper-sticker "Chrome destroyed protocol X!" complaint.
GoblinSlayer 6y ago
Private key is not much better than a strong password. A certificate would physically identify you and would allow to apply social credit system.
q3k 6y ago
This is exactly how TLS client certificates work - except that instead of the server storing the public keys of clients, the clients present a cryptographic proof generated by the server/CA that they represent some identity (ie., a certificate).
- chipsa 6y ago
  Uh? They normally store the User Principal Name from the cert, and then use the public/private key as part of the connection. Specifically, the connection is negotiated after the client sends the public client certificate, and uses it as part of the key exchange. It doesn't necessarily need to store the public key, but it does need to store which certificate goes with which account. And the certificate is validated by checking that it's been issued by a CA the server trusts.
  - q3k 6y ago
    The server doesn't need to store the certificate, or even a mapping from certificate to identity. Just retrieving information encoded in the DN or SANs of a certificate presented by a client is enough to tie the connection originator/client to an identity. I mean, it's a design decision, whether you want to have a layer of indirection there - but keeping it without one allows TLS client certificates to be fully stateless, and be used across multiple backends that do not share any session/mapping store between them. In addition, if I'm being picky, TLS 1.3 changes how client certificates are used, and they are now not part of the initial handshake.
cestith 6y ago
You're familiar I'm sure with your browser authenticating that a TLS certificate is within its valid date range and assigned to the hostname of the server? You're probably also aware that your OS and/or browser have a list of certificate authorities one of which must have signed the certificate (or via a chain of CAs from a trusted root, with each CA cert signed by one closer to the root). Client certs work the same way except it's the server verifying all of this for the client (browser, mail user agent, whatever). At $work we have several systems in which the server only accepts requests, or only accepts certain kinds of requests, from clients with client certificates with specific restrictions. Depending on the application and its authN/authZ needs, any of the solutions I'm about to mention might be combined with some combination of a username/password, with a time-based token, a JWT, IP range restrictions, an API key, or whatever else in addition to the client cert requirement - or sometimes the cert is sufficient by itself. Some just trust anything that was issued by the right CA and is in its proper date range. Sometimes we also verify that the certificate matches an assigned hostname of the client. Sometimes we trust certs by the right CA to connect, but parse the hostname out of the cert and check whether that client's hostname or the subdomain it's in has authorization to do certain things. Semantic hostnames might look long and confusing at first, but they can be used very easily for things like that. Semantic host names and naming schemes could be its own article. This isn't a general use case for the general public because of deployment headaches. Which CAs do we trust? Is it the same as those issuing server certs? Will services be set up especially to issue client certs? Who's supporting the users to get the certs installed, many of whom enter the wrong email when signing up for services? We can do this in a corporate network pretty easily. We have automation systems for servers. We have another, different automation system for administration of Laptop, desktop, and mobile client devices. We just put what cert we want everywhere we want it. A big problem I see with client certs and the general public is multi-device users. If you're logging into Google from your home desktop, your work desktop, a couple of laptops, a tablet, and a phone that's one email address but half a dozen different certificates. Some applications, especially cross-platform ones, insist on their own certificate store even if the OS provides a shared one. So for mail, a couple of browsers, and two other native apps, congratulations that's maybe two dozen. One can export and import client certs, but there's no simple way to get less technical end users to do that. So do we make it easier to configure multiple client devices and all their applications with the same certificate and key? Are end users going to remember to update them all when one is lost in a breach or it expires? Or do we expect all the service providers to trust multiple certificates signed by multiple different CAs for each user, then have the user upload the public (but not the private!) part of each cert/key pair to all of those services to say they should be trusted? Or does every service require its own CA to sign your cert for its own service, so you need an Apple cert, a Google cert, an Amazon cert... ad nauseum? Tools like Bitbucket or Gitlab let you upload your public SSH key in the web UI to provide auth for the git repos. You can also have (hopefully with separate keys) automated applications that interact with git auth against a repository or all the repos in a project. That's the sort of interface one might expect a web application to offer for TLS certificates. * * A certificate is basically the public key portion of a public/private key pair that's been signed by some CA. Preferably that CA is a broadly trusted one, except in very particular circumstances.

by bo1024 6y ago

I"m not sure exactly what client-side certificates means here, but I have long wondered why we can't just use public key/private key authentication for most logins. Is it the same?

mortehu 6y ago

Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication, and a very small number of websites supported it. After Chrome became popular, those sites were forced to switch to a different form of second factor authentication, and it's fallen almost completely out of use. Part of the reason was that the user interfaces for installing certificates were terrible, and websites needed to have guides on how to use it in each browser.

bo1024 6y ago
Thanks. I’m still not clear what the authentication method is, but I don't see why we can’t have a one click browser button “give this site my public key” and another “authenticate to this site with my private key”.
- chipsa 6y ago
  Who gives you the private key? Is it generated on the device? How do you move the keys to your different devices? I can end up working at any of 20 computers on a given day, not counting my personal devices.
  - bo1024 6y ago
    Not sure what the best solution is, but some thoughts. First, you definitely want a different keypair per device. One approach is to just supplement passwords. You could use a password (2FA, etc) to log in, then the site gives you the option of adding that device's public key and from then on you can log in on that device automatically. The site would maintain a list of public keys associated with your account, just like github does for repositories. Of course, if you don't trust those 20 work computers, you wouldn't want it set up so that anyone using them can log in to all your accounts. One thing the browser could do is password-protect your private key, so you have to enter the master password when you start the browser, and as long as you remember to exit out of the browser, the next person to use it won't be able to use your logins.
Avamander 6y ago
> Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication Chrome has an interface for it.
- mortehu 6y ago
  Last I checked it could only install from the filesystem, and not directly generate a key and install a certificate through the web. Do you have an example site where this works with Chrome?
  - jessaustin 6y ago
    Has the goalpost been moved? Upthread you compared Chrome to "all popular web browsers [which] had a user interface for installing client side HTTPS certificates for user authentication". I just opened up Firefox, and found a very similar menu to Chrome's: the only option was to "import" a cert from the filesystem. I agree that we should expect more from our tools, but has any popular browser ever allowed the user to generate a new cert? If one were to do so, how would the generated cert be connected to PKI -- who would sign the cert and how would they do that?
    - mortehu 6y ago
      Yes, browsers other than Chrome can generate keys, submit the public key to a site you're logged into and install the certificate you get in response (usually after a second factor verification). I am not aware of any site that still does this, so I can't show it to you. Skandiabanken in Norway used to do it before Chrome. You won't be able to see this in Firefox in any way other than visiting such a site.
      - jessaustin 6y ago
        Now I'm curious. This seems like a procedure that would need to be precisely defined. Is there a standard protocol for this? Does it have an RFC or similar I could read? If nothing else, it would be nice to have a short bumper-sticker "Chrome destroyed protocol X!" complaint.

GoblinSlayer 6y ago

Private key is not much better than a strong password. A certificate would physically identify you and would allow to apply social credit system.

q3k 6y ago

This is exactly how TLS client certificates work - except that instead of the server storing the public keys of clients, the clients present a cryptographic proof generated by the server/CA that they represent some identity (ie., a certificate).

chipsa 6y ago
Uh? They normally store the User Principal Name from the cert, and then use the public/private key as part of the connection. Specifically, the connection is negotiated after the client sends the public client certificate, and uses it as part of the key exchange. It doesn't necessarily need to store the public key, but it does need to store which certificate goes with which account. And the certificate is validated by checking that it's been issued by a CA the server trusts.
- q3k 6y ago
  The server doesn't need to store the certificate, or even a mapping from certificate to identity. Just retrieving information encoded in the DN or SANs of a certificate presented by a client is enough to tie the connection originator/client to an identity. I mean, it's a design decision, whether you want to have a layer of indirection there - but keeping it without one allows TLS client certificates to be fully stateless, and be used across multiple backends that do not share any session/mapping store between them. In addition, if I'm being picky, TLS 1.3 changes how client certificates are used, and they are now not part of the initial handshake.

cestith 6y ago

You're familiar I'm sure with your browser authenticating that a TLS certificate is within its valid date range and assigned to the hostname of the server? You're probably also aware that your OS and/or browser have a list of certificate authorities one of which must have signed the certificate (or via a chain of CAs from a trusted root, with each CA cert signed by one closer to the root). Client certs work the same way except it's the server verifying all of this for the client (browser, mail user agent, whatever). At $work we have several systems in which the server only accepts requests, or only accepts certain kinds of requests, from clients with client certificates with specific restrictions. Depending on the application and its authN/authZ needs, any of the solutions I'm about to mention might be combined with some combination of a username/password, with a time-based token, a JWT, IP range restrictions, an API key, or whatever else in addition to the client cert requirement - or sometimes the cert is sufficient by itself. Some just trust anything that was issued by the right CA and is in its proper date range. Sometimes we also verify that the certificate matches an assigned hostname of the client. Sometimes we trust certs by the right CA to connect, but parse the hostname out of the cert and check whether that client's hostname or the subdomain it's in has authorization to do certain things. Semantic hostnames might look long and confusing at first, but they can be used very easily for things like that. Semantic host names and naming schemes could be its own article. This isn't a general use case for the general public because of deployment headaches. Which CAs do we trust? Is it the same as those issuing server certs? Will services be set up especially to issue client certs? Who's supporting the users to get the certs installed, many of whom enter the wrong email when signing up for services? We can do this in a corporate network pretty easily. We have automation systems for servers. We have another, different automation system for administration of Laptop, desktop, and mobile client devices. We just put what cert we want everywhere we want it. A big problem I see with client certs and the general public is multi-device users. If you're logging into Google from your home desktop, your work desktop, a couple of laptops, a tablet, and a phone that's one email address but half a dozen different certificates. Some applications, especially cross-platform ones, insist on their own certificate store even if the OS provides a shared one. So for mail, a couple of browsers, and two other native apps, congratulations that's maybe two dozen. One can export and import client certs, but there's no simple way to get less technical end users to do that. So do we make it easier to configure multiple client devices and all their applications with the same certificate and key? Are end users going to remember to update them all when one is lost in a breach or it expires? Or do we expect all the service providers to trust multiple certificates signed by multiple different CAs for each user, then have the user upload the public (but not the private!) part of each cert/key pair to all of those services to say they should be trusted? Or does every service require its own CA to sign your cert for its own service, so you need an Apple cert, a Google cert, an Amazon cert... ad nauseum? Tools like Bitbucket or Gitlab let you upload your public SSH key in the web UI to provide auth for the git repos. You can also have (hopefully with separate keys) automated applications that interact with git auth against a repository or all the repos in a project. That's the sort of interface one might expect a web application to offer for TLS certificates. * * A certificate is basically the public key portion of a public/private key pair that's been signed by some CA. Preferably that CA is a broadly trusted one, except in very particular circumstances.