3 ms·

> I highly recommend using a password manager. I really wish websites would support use of client side TLS certificates as part of the authentication process.

by u801e 9y ago

> I highly recommend using a password manager. I really wish websites would support use of client side TLS certificates as part of the authentication process. Combining that with a username and password would give you two-factor authentication.

calebh 9y ago
You might want to look into the new web authentication API.
geofft 9y ago
Client side TLS certificates get sent in the clear before you authenticate the server. (You can send them in a renegotiation, but renegotiation has been a historic source of both implementation and protocol security bugs because it does complicated things to TLS state.) So you don't want a client-side certificate that includes your name; that's a huge privacy leak. You could imagine a scheme where you give a user a certificate with a random subject, and you have a server-side map of random string to user account (so leaking that map isn't the end of the world like leaking passwords, it merely reintroduces the privacy leak above). I recall some proposals for that several years ago. Today, Web Authentication effectively does something effectively equivalent, as does U2F, although they don't involve TLS client certificates specifically.
- u801e 9y ago
  > So you don't want a client-side certificate that includes your name; that's a huge privacy leak. If it matches the username I have on a website like reddit or HN, then is it really a privacy issue? Anyone, regardless of whether they're logged in or not, can see posts I've made under my username. Though what you say can be an issue for websites where privacy from other users is expected (e.g. banks). > Today, Web Authentication effectively does something effectively equivalent, as does U2F Both of those seem to rely on HTTP, while TLS could work with any application level protocol.
  - geofft 9y ago
    They can't see that the posts are coming from your IP address, though. That's one of the things TLS protects—I can post from a coffee shop and nobody at the coffee shop can know (except perhaps by traffic analysis) that the person at the table next to them is the person with this username.
- tialaramex 9y ago
  In TLS 1.3 client certs are sent over an encrypted link, and a reasonable client can and should wait for Finished from the server to arrive, at which point they're entirely sure of who their recipient is too. Another nice thing is that TLS 1.3 servers can send a CertificateRequest asking for a particular _type_ of certificate, so (if that's ever used in anger) it lets us have clients that don't need to waste the user's time when they don't actually have a suitable certificate anyway. In earlier versions servers could only hint about which CAs they trust, not anything else.
  - geofft 9y ago
    Oh nice, that might be enough to put me back on team client certs!
QasimK 9y ago
I looked into this and the user experience involved is very poor, in particular the browser interfaces. It sounds like a chicken-and-egg problem. On top of this, is the clear text sending of the client certificate as another poster mentioned.

by u801e 9y ago

calebh 9y ago

You might want to look into the new web authentication API.

geofft 9y ago

Client side TLS certificates get sent in the clear before you authenticate the server. (You can send them in a renegotiation, but renegotiation has been a historic source of both implementation and protocol security bugs because it does complicated things to TLS state.) So you don't want a client-side certificate that includes your name; that's a huge privacy leak. You could imagine a scheme where you give a user a certificate with a random subject, and you have a server-side map of random string to user account (so leaking that map isn't the end of the world like leaking passwords, it merely reintroduces the privacy leak above). I recall some proposals for that several years ago. Today, Web Authentication effectively does something effectively equivalent, as does U2F, although they don't involve TLS client certificates specifically.

u801e 9y ago
> So you don't want a client-side certificate that includes your name; that's a huge privacy leak. If it matches the username I have on a website like reddit or HN, then is it really a privacy issue? Anyone, regardless of whether they're logged in or not, can see posts I've made under my username. Though what you say can be an issue for websites where privacy from other users is expected (e.g. banks). > Today, Web Authentication effectively does something effectively equivalent, as does U2F Both of those seem to rely on HTTP, while TLS could work with any application level protocol.
- geofft 9y ago
  They can't see that the posts are coming from your IP address, though. That's one of the things TLS protects—I can post from a coffee shop and nobody at the coffee shop can know (except perhaps by traffic analysis) that the person at the table next to them is the person with this username.
tialaramex 9y ago
In TLS 1.3 client certs are sent over an encrypted link, and a reasonable client can and should wait for Finished from the server to arrive, at which point they're entirely sure of who their recipient is too. Another nice thing is that TLS 1.3 servers can send a CertificateRequest asking for a particular _type_ of certificate, so (if that's ever used in anger) it lets us have clients that don't need to waste the user's time when they don't actually have a suitable certificate anyway. In earlier versions servers could only hint about which CAs they trust, not anything else.
- geofft 9y ago
  Oh nice, that might be enough to put me back on team client certs!

QasimK 9y ago

I looked into this and the user experience involved is very poor, in particular the browser interfaces. It sounds like a chicken-and-egg problem. On top of this, is the clear text sending of the client certificate as another poster mentioned.