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 compromised.

Also consider attack surfaces here, how many exploits have there been on say openssl and apache/nginx over the Past 1/5/10 years. How many on OpenSSH?

>For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to prevent accidental forwarding. The SSH stack, on the other hand, requires you to opt out of arbitrary TCP/IP port forwarding. Screwing that up will, more often than not, get you owned up Phineas Phisher-style.

Lets not forget that libraries like OpenSSL require you to "opt out" of shit like ECB mode and NULL ciphers.....

*"Also consider attack surfaces here, how many exploits have there been on say openssl and apache/nginx over the Past 1/5/10 years. How many on OpenSSH?"

This. I can't believe the top comment on this post is supporting TLS (as implemented currently) over SSH (where everyone is basically using openssh). There's pretty much a guaranteed "named" widespread TLS based attack exposed every month or so. Whether it's due to TLS the spec or the prevalent implementations, it doesn't matter. Any application designer choosing a protocol has to contend with the fact of shitty implementations of the underlying layer when thinking of security.

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.

> 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.

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.

> 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.

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

I agree - the killer advantage of SSH is that OpenSSH is very, very good.

In the article, it shows a chat server as an example. Imagine the same app implemented using HTTPS. Would openssl s_client be effective as a client? [I suspect not, as HTTPS != SSL, but perhaps my naive question will prompt suggestion of a better approach from someone with a clear understanding of the layers.]

Update: looks like an effective tool could be socat, which seems to be a SSL-capable take on netcat. On the server side, reckon it would work to use stunnel. You could have xinetd host a launcher that wraps stunnel around a simple socket server. Clients could connect to that with socat.

I'm not sure I understand the comparison. openssl s_client creates a TLS connection, but doesn't drive the HTTP protocol; it's a generic bidirectional encrypted transport. Lots of chat protocols use TLS in exactly this manner.

But I'm going a step further: I think even if you're stuck with HTTPS/HTTP/2, you're still better off tunneling your application protocol over that than SSH.

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 hassle I've had trying to get a SSL server going in this last hour - it seems like you need to be signed by a recognised authority. ssh is convenient in that you get solid encryption, but you only need a fingerprint, not an authority sig.

> 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 you have a much harder argument to make that ssh is more usable than HTTPS.

> A hassle I've had trying to get a SSL server going in this last hour - it seems like you need to be signed by a recognised authority. ssh is convenient in that you get solid encryption, but you only need a fingerprint, not an authority sig.

What you call a hassle is a major feature of all correct TLS implementations. SSH offers no guarantee that the server you're connecting to is who they say they are. I don't count SSHFP DNS entries because (a) they're rare, and (b) DNS is trivially intercepted. DNSSEC may fix that but support is rare. Without the ability to guarantee the identity of the site you're connecting to, encryption doesn't really matter. You may just be having an encrypted conversation with an attacker.

https://letsencrypt.org/ takes much of the hassle of getting a verified TLS certificate away and can even be fully automated for example: https://caddyserver.com/

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).

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.

You can use Lynx. It is a terminal based web browser, and is older than SSH. It exists for many platforms and is not particularly obscure or difficult to use.

https://en.m.wikipedia.org/wiki/Lynx_(web_browser)

This doesn't work as a solution to the problem in focus here.

Consider: could you implement a chat app that worked as effectively as the ssh one if you used lynx as the client? No, because interaction with lynx is synchronous.

The original article is making a point that you can build effective apps that work over ssh. The post at the root of this thread raised concerns about using ssh specifically.

Hypothetically you could have a console based web browser that supported javascript and websockets, and then expose the chat server over javascript. But that wouldn't be a good solution either: it's a specialised client and a large number of layers to achieve something that the ssh chat app shows to be straightforward - a secure, generic approach to exposing async functionality to a thin console tool.

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/

tinysshd does not have the 90's crypto by default. It is optional. Nor does it have the "extreme complexity".

> 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.