4 ms·

Have you ever used that? The user experience is horrible. Here [1] are a few more reasons why client certificate right now are just plain bad. [1] http://www.b

by brutos 12y ago

Have you ever used that? The user experience is horrible. Here [1] are a few more reasons why client certificate right now are just plain bad. [1] http://www.browserauth.net/tls-client-authentication http://www.browserauth.net/tls-client-authentication

icebraining 12y ago
But how is this solution any better?
derefr 12y ago
So why are people trying to replace the algorithm, when what we need to do is to replace the UX? Patches could be submitted for both Chromium and Firefox to give them a better client-cert flow, but I don't see anyone working on the problem; just a constant parade of restyling on tab-strip and toolbar and notification banner UX. I mean, ideally, a client cert would be treated pretty much exactly like a cookie: generated on first connection to a website and automatically stored by the client; synced across browsers; etc. And, I mean, you could treat a client cert like a permanently logged-in account credential, but it'd be much better to just treat it as essentially an unforgeable browser fingerprint+session ID: something that just "pairs" the client and the server, but where you still have to log in after that pairing process, but only once. (As long as the cert gets synced to another browser, that browser is now logged into the site, because it's now sending the fingerprint of a "session" that's logged into the site.) With such a setup, you would be able to just "clear" the client cert (like a cookie) to log out, and then get issued a new one and log in again on that one, if you wanted. You wouldn't have to worry about losing your cert. You'd be able to have multiple devices with multiple client certs that are each separately logged into the same account, if you wanted. But, since each client cert would be associated with an account, and vice-versa, you'd be able to revoke a client cert's access to a particular account: to, effectively, log another device out remotely. The nice thing about this workflow, actually, is that each and every HTTPS site could always issue each visitor a client cert, just as we currently generate server-side session IDs for each visitor. It'd become a best practice to have client cert issuance on by default at the load-balancer level, like HSTS is now. (And load balancers can just translate client certs into a plaintext "browser fingerprint hash" HTTP header, that can be detected by anything further along the request chain that currently knows how to deal with cookie or URL session IDs.)
- geographomics 12y ago
  How is this better than using cookies? I don't really see the advantage of moving session identification down a layer.
  - Sarien 12y ago
    It's better because your browser doesn't have a button to clear your ssh private keys. Cookies simply aren't meant for storing important data.
  - jimktrains2 12y ago
    A correctly done client cert provides mutual authentication (the server's ssl cert and priv key it had when you signed up with it is the one needed to sign in in the future).
  - rakoo 12y ago
    Because HTTP is stateless and session-less, and cookies are a hack to make it stateful. We introduced the notion of a session where we already had one, in the form of TLS sessions. Note that it would also make APIs much simpler by moving the authentification, authorization and session logic in the certificate, where it actually already is.
    - geographomics 12y ago
      > We introduced the notion of a session where we already had one, in the form of TLS sessions. But that would only apply to HTTPS. An extension to HTTP itself was necessary so state could be maintained for both HTTP and HTTPS. Especially in the mid-1990s (the era when cookies and HTTPS were introduced) when acquiring a CA-signed certificate was cumbersome and expensive.
      - rakoo 12y ago
        That is true, but I'm one of those guys who believe HTTP-only should die. Even without going as far as that, I believe that as soon as you have to manage some kind of session you're going to have private data flying around, and that should be protected in TLS.

by brutos 12y ago

icebraining 12y ago

But how is this solution any better?

derefr 12y ago

So why are people trying to replace the algorithm, when what we need to do is to replace the UX? Patches could be submitted for both Chromium and Firefox to give them a better client-cert flow, but I don't see anyone working on the problem; just a constant parade of restyling on tab-strip and toolbar and notification banner UX. I mean, ideally, a client cert would be treated pretty much exactly like a cookie: generated on first connection to a website and automatically stored by the client; synced across browsers; etc. And, I mean, you could treat a client cert like a permanently logged-in account credential, but it'd be much better to just treat it as essentially an unforgeable browser fingerprint+session ID: something that just "pairs" the client and the server, but where you still have to log in after that pairing process, but only once. (As long as the cert gets synced to another browser, that browser is now logged into the site, because it's now sending the fingerprint of a "session" that's logged into the site.) With such a setup, you would be able to just "clear" the client cert (like a cookie) to log out, and then get issued a new one and log in again on that one, if you wanted. You wouldn't have to worry about losing your cert. You'd be able to have multiple devices with multiple client certs that are each separately logged into the same account, if you wanted. But, since each client cert would be associated with an account, and vice-versa, you'd be able to revoke a client cert's access to a particular account: to, effectively, log another device out remotely. The nice thing about this workflow, actually, is that each and every HTTPS site could always issue each visitor a client cert, just as we currently generate server-side session IDs for each visitor. It'd become a best practice to have client cert issuance on by default at the load-balancer level, like HSTS is now. (And load balancers can just translate client certs into a plaintext "browser fingerprint hash" HTTP header, that can be detected by anything further along the request chain that currently knows how to deal with cookie or URL session IDs.)

geographomics 12y ago
How is this better than using cookies? I don't really see the advantage of moving session identification down a layer.
- Sarien 12y ago
  It's better because your browser doesn't have a button to clear your ssh private keys. Cookies simply aren't meant for storing important data.
- jimktrains2 12y ago
  A correctly done client cert provides mutual authentication (the server's ssl cert and priv key it had when you signed up with it is the one needed to sign in in the future).
- rakoo 12y ago
  Because HTTP is stateless and session-less, and cookies are a hack to make it stateful. We introduced the notion of a session where we already had one, in the form of TLS sessions. Note that it would also make APIs much simpler by moving the authentification, authorization and session logic in the certificate, where it actually already is.
  - geographomics 12y ago
    > We introduced the notion of a session where we already had one, in the form of TLS sessions. But that would only apply to HTTPS. An extension to HTTP itself was necessary so state could be maintained for both HTTP and HTTPS. Especially in the mid-1990s (the era when cookies and HTTPS were introduced) when acquiring a CA-signed certificate was cumbersome and expensive.
    - rakoo 12y ago
      That is true, but I'm one of those guys who believe HTTP-only should die. Even without going as far as that, I believe that as soon as you have to manage some kind of session you're going to have private data flying around, and that should be protected in TLS.