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