6 ms·

> leave you with no upsides. Not even close. While TLS technically supports client-side certs, all extant implementations of it are unbearably clunky to use,

> leave you with no upsides. Not even close. While TLS technically supports client-side certs, all extant implementations of it are unbearably clunky to use, completely ignored by all vendors. Meanwhile the tooling around SSH keys (like ssh-agent) is seamlessly integrated with your OS and works so well that it's easy to forget it even exists. Browser vendors completely dropped the ball on this; they dropped it so hard it continues to hurt even after all these years.

tptacek 10y ago
I'm not suggesting that people should use browsers. Obviously I can't be, because browsers don't do SSH.
e12e 10y ago
This may be true, but at least x509 will get you certificates right out the gate (sadly without reliably working reject lists). I've yet to get to the point of moving to "modern ssh" (ed25519 key/certs, chacha20-poly1305 encryption etc) - with certificate only. Because keys are *so' convenient. But they're also, while better than passwords, pretty bad: No expiry, no easy rotation, no easy revocation. I will say this though: it should be quite feasible to move to modern ssh, banning keys and passwords (other than perhaps as a second factor), and moving to certs only. But clearly deployment of reasonable ssh setups are lacking behind the technological improvements.
hinkley 10y ago
> all extant implementations of [mutual auth] are unbearably clunky to use, completely ignored by all vendors. I hope things have gotten better now, but five years ago I ran into this in spades. Pulling teeth both to implement and then to explain. Especially if it's from a cert chain, and doubly so if you want to only trust certain from your CA. And I think across the whole stack we ended up with three TLS stacks, and some HSM hardware. So I got to figure out trust stores multiple times. I should have run screaming, but I stayed at that job an extra five months just to make sure that everyone really understood the mutual certificate auth code at a practical level. There's gotta be a better way. I really think we need a hybrid system that is more like PGP, where you have a key chain and get advisary info from your peer group about the veracity of a CA Signed cert.

tptacek 10y ago

I'm not suggesting that people should use browsers. Obviously I can't be, because browsers don't do SSH.

e12e 10y ago

This may be true, but at least x509 will get you certificates right out the gate (sadly without reliably working reject lists). I've yet to get to the point of moving to "modern ssh" (ed25519 key/certs, chacha20-poly1305 encryption etc) - with certificate only. Because keys are *so' convenient. But they're also, while better than passwords, pretty bad: No expiry, no easy rotation, no easy revocation. I will say this though: it should be quite feasible to move to modern ssh, banning keys and passwords (other than perhaps as a second factor), and moving to certs only. But clearly deployment of reasonable ssh setups are lacking behind the technological improvements.

hinkley 10y ago

> all extant implementations of [mutual auth] are unbearably clunky to use, completely ignored by all vendors. I hope things have gotten better now, but five years ago I ran into this in spades. Pulling teeth both to implement and then to explain. Especially if it's from a cert chain, and doubly so if you want to only trust certain from your CA. And I think across the whole stack we ended up with three TLS stacks, and some HSM hardware. So I got to figure out trust stores multiple times. I should have run screaming, but I stayed at that job an extra five months just to make sure that everyone really understood the mutual certificate auth code at a practical level. There's gotta be a better way. I really think we need a hybrid system that is more like PGP, where you have a key chain and get advisary info from your peer group about the veracity of a CA Signed cert.