Live data from Hacker News

Why aren’t we using SSH for everything? (2015)

medium.com

61–70 of 87 posts

Re: Why aren’t we using SSH for everything? (2015)

#61

Earlier quoted context omitted.

It's not as simple as you make it out to be. HTTPS git still has no consistent way to cache credentials, so you're stuck either keeping it in plaintext on disk or re-authenticating every time you push. Even though client TLS certs are technically supported by a handful of services, there's nothing for HTTPS that matches the security and convenience of ssh-agent. It has a long way to go to catch up to where SSH was te…

git supports "credential helpers" [0] which allow arbitrary credential storage and retrieval schemes. I've successfully used it with a Yubikey, for example, although I promptly reverted to using SSH and my GPG authentication subkey when it became clear that there is no single scheme that works on all platforms I use. [0] https://git-scm.com/docs/git-credential

The parent has a great point about credentials and ssh-agent in general. Netrc isn't a great pattern.

But for git you have the right answer.

I completely forgot this aspect because on OS X you can delegate git auth to Keychain with a helper.

https://help.github.com/articles/caching-your-github-passwor...

Re: Why aren’t we using SSH for everything? (2015)

#62

To be clear, if you look through OPs posts, he's clearly a government shill. Trust his advice at your own peril.

I've seen this accusation thrown around for years now (often privately) and I just don't see it. Maybe I'm blind. Even if he's shilling for the government (stupid claim but whatever), what do they gain by him encouraging people to adopt better crypto habits? This seemingly-baseless personal attack doesn't even pass the laugh test for me. I'd like to see some hard evidence. What do government shills sound like? What a…

I think a better term would be apologist, not shill. For better or for worse, Thomas's interest in the law gives him a position on Federal power that is often at odds with the more old-school libertarian/anarchist members of the HN community.

Speaking for myself, his apologia of The State also irritates me quite a bit, but I try to keep my mouth shut because he contributes so much to the community.

Re: Why aren’t we using SSH for everything? (2015)

#63
post #10

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to…

Newer versions of OpenSSH have totally dumped the "90s crypto", although its important to note the problems with older ssh stuff are mostly due to things like RSA key lengths and use of RC4 and CBC. This stands in contrast to numerous gaping flaws in TLS stacks like the use of export ciphers, message maleability, inummerable weaknesses in x509 certs that allow spoofing/mitm and other horrible shit that is trivially c…

Not really. TLS and SSH have essentially the same crypto problems.

Legacy SSH uses conventional DH signed with pinned RSA keys to run CBC and HMAC. Legacy TLS uses conventional DH with RSA keys to run CBC and HMAC. Both have complicated negotiation schemes that include cipher parameters nobody should ever use.

Modern TLS uses forward-secure ECDH, signed with pinned RSA keys, to boot up an AEAD. Modern SSH uses ECDH signed with pinned RSA keys to boot up an AEAD.

There are two important reasons why TLS has more attacks than SSH:

1. Contra the article's claim of SSH's ubiquity, TLS is actually ubiquitously deployed, and so older version of the protocol by necessity live longer and cause more trouble.

2. TLS is used by browsers, and browsers support content-controlled code. You can't have BEAST or CRIME or AlFardan's RC4 attack without something to force a client to generate thousands of related connections.

But neither of these are factors for people who would consider using SSH instead of TLS. Those same people can deploy minimized configurations of TLS, and use native applications instead of browsers. See, for instance, what payments companies do with their iOS applications.

TLS has never supported ECB, by the way.

Re: Why aren’t we using SSH for everything? (2015)

#64
post #10

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to…

> 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 har…

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

Re: Why aren’t we using SSH for everything? (2015)

#65
post #10

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to…

> 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 har…

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.

Re: Why aren’t we using SSH for everything? (2015)

#66
post #10

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to…

If that's the case, how can I plug the HTTP/2 and TLS 1.3 stack into Linux-PAM and use it to login to my remote servers instead of using ssh? Or are they not suitable for that?

You could wrap TLS around telnetd (bound to localhost, with a TLS terminator in front) pretty trivially. I'm not sure I'd recommend it, but you certainly could. You could then login with openssl s_client.

Integration to the PAM-stack would be a little more complicated, but there are some tools for working with certificates[eg: 1]. I'm not aware of any that is designed to work for console-like login remotely, though.

[1] http://www.ftsafe.com/application/signon/linuxpampkcs11/

Re: Why aren’t we using SSH for everything? (2015)

#67
post #17

Earlier quoted context omitted.

Part of the appeal of the ssh chat server from the article is that you can connect to the server using an existing console tool. It's not necessary to have a purpose-built client. So I've been trying to think: how could you get that convenience, but using HTTPS instead of SSH. [based on your example above] In an update above I've talked about socat. That's less convenient than ssh, because socat is obscure vs ssh. A…

> Part of the appeal of the ssh chat server from the article is that you can connect to the server using an existing console tool. If what you're looking for is confirmation that ssh is indeed the most ubiquitous (at least ignoring Windows) console app to support encrypted console chat apps, then yes, I think you're correct for that very narrow design goal. For just about any other set of design constraints I think y…

You're not wrong (about most ssh deployments) - but ssh absolutely supports running your own CA. Perhaps there's a start-up opportunity in running a letsencrypt-like CA for ssh certs, though. I'm sure many people would be happy to pay a fee to have better key rollover, and arguably more secure server authentication.

Re: Why aren’t we using SSH for everything? (2015)

#68

Earlier quoted context omitted.

> Part of the appeal of the ssh chat server from the article is that you can connect to the server using an existing console tool. If what you're looking for is confirmation that ssh is indeed the most ubiquitous (at least ignoring Windows) console app to support encrypted console chat apps, then yes, I think you're correct for that very narrow design goal. For just about any other set of design constraints I think y…

CAs don't gaurentee identity either. If you care deeply about either, you need to be comparing fingerprints. SSH clients have built in support for this, web browsers do not. Although I concede mechanisms like HPKP exist, they are not the default.

I would argue that automating verification via signatures is mostly strictly better than manually verifying fingerprints. But for ssh, you'd have to turn off basic key authentication (of users and hosts), and force the use of an trusted CA.

Trusting a slew of CAs to identify your server, when you only actually use one CA is indeed nuts (not to mention the fragility of certificate revocation for TLS, due to a (misguided) effort to avoid denial-of-service attacks).

Re: Why aren’t we using SSH for everything? (2015)

#69
post #53
post #10

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to…

> and leave you with no upsides. The only place I've personally seen client-side certificates implemented in a browser was for StartSSL's site (which is famously janky in it's workflow). In contrast, pretty much anyone who does anything on the CLI in a unix environment has a client-side ssh key set up, already good to go.

Cacert.org has an option for logging in with certificates. It works well enough.

Re: Why aren’t we using SSH for everything? (2015)

#70
post #26

Earlier quoted context omitted.

You know, maybe I'm wrong, but I read the comment as a cheap way to register superiority over the OP - essentially saying "we already talked about this, so move along." That's not as valuable when "we" changes over time, and (as you pointed out) a lot of "us" don't participate in every discussion. IMHO we'd be better off if we didn't have to hear about it every time an old topic got resurrected.

> ...I read the comment as a cheap way to register superiority over the OP... Whose comment? fjarlq's comment? If so, I also might be wrong, but I read it as "Here's old discussion on the topic. Might be worth reading to see if what you want to talk about today has already been hashed out, or if there's discussion that you might find interesting.".

Yeah, I merely wanted to reference the old discussion in the hope that it might improve the discussion today. I think it's fine when a story gets discussed multiple times.
Post reply on HN