> What does this mean? It means that SSH has authentication built into the protocol. When you join ssh-chat, not only do I know who you claim to be, but I can also permanently and securely attach an identity to your connection without any user intervention on your part
This, known as fingerprinting, is collectively considered a bad thing. I am thankful this isn't elsewhere
This is not really a problem with the SSH protocol itself, but with certain things that the implementations may do automatically (although it would be easy to change them to not do such things automatically).
(This is unlike WWW. WWW is so complex and messy that it effectively does have fingerprinting and is difficult to change.)
> This, known as fingerprinting, is collectively considered a bad thing. I am thankful this isn't elsewhere
I mean, it depends, right? If you only surfed the web or connected to chats with a single pubkey, then yes - that's probably sub-optimal.
But pseudonymity, imo, works best when you can consistently prove that you own your identity, and that nobody can impersonate your pseudonymous account. (You can always burn it and get another one, or have multiples, etc, of course.) And pseudonymity is something that is, while contentious, is not collectively considered a bad thing.
The xz backdoor had nothing to do with SSH (protocol) or OpenSSH. A Debian version of OpenSSH became potentially vulnerable because of a package maintainer decision to patch OpenSSH.
One could make an argument that no one should be using packages from (Debian) package maintainers. The origin of the xz backdoor in relation to SSH was a Debian package maintainer patching OpenSSH in an effort to support systemd.
FWIW, the xz backdoor had zero potential effect on people using OpenSSH compiled from source without patches. (I do this b/c I prefer static binaries and dislike package managers.) The worst potential risk of the xz backdoor, IMO, was libarchive's use of xz project. After the backdoor was announced, I re-compiled libarchive without xz support:
These are problems with the server implementation though and not with the SSH protocol itself; you could design a SSH server software that does not run as root (if you do not need the capabilities that are available when it does run as root; for example, if you only want to allow SSH to one user account then it can run with that user account).
Basically all the benefits listed are already in https, just maybe not used often (thinks like client certificates). IMO it'd make more sense to make SSH use http2/http3 than it would to make HTTP use SSH.
Some kind of things are just not the things that HTTPS is meant to do and therefore does not do very well. For downloading and uploading files (and forms, etc), HTTP(S) is working, although some other things won't fit very well with it, and are often done in a rather complicated way that still won't fit very well with it.
Client certificates are a feature of TLS, and not of HTTPS; however, since HTTPS is using TLS that means that you can use client certificates with HTTPS too, even though they are not commonly used. (Client certificates are more commonly used with Gemini protocol.)
The article says SSH does not have virtual hosting. HTTP does, and so does TLS (although I think some older versions of TLS do not have virtual hosting), so HTTPS does have that benefit, at least.
> Some kind of things are just not the things that HTTPS is meant to do and therefore does not do very well.
I'm not sure I see what those are anymore. With http2 we got multiplexing with different priorities on streams, with http3/quic we got connection migration. I don't see many usecases where SSH has clear win anymore.
> although I think some older versions of TLS do not have virtual hosting
Virtual hosts came to TLS with SNI, added in 2003. It took a while for it to be reliable though, mainly since IE6 was slow to die.
Virtual hosting with SSH would be very useful for me since I want to run both a git SSH server (in my case gitea) and my normal SSH server as two different services, isolated from each other.
SSH has some advantages, but it is not perfect. (Neither is HTTPS, TLS, etc; none of them are perfect, of course.)
> SSH knows your username
It is not always desirable, although of course an implementation might not necessarily need to use your local username as the remote username (especially if the implementation is on a computer that does not have usernames). The existing implementation does allow you to override the usernames, as they describe there.
Sending environment variables is also useful. You might not want to send some (or you might, like above, use a computer system that does not have environment variables, in which case the SSH client will need to have its own mechanism to specify them).
Sending these things automatically even if you do not want to do, can be a problem.
> SSH validates against your key pair
This is a helpful method, although the user may wish to force a specific method (and the server also might wish to do so).
Automatically offering all of the keys doesn't seem like very good to me, but allowing the user to manually associate which keys to use for which connections (allowing keys to be shared between connections if wanted), can be helpful. (This is not a problem with the SSH protocol, though; it is an issue with the client implementation.)
> SSH connections are encrypted
Encryption is helpful, but sometimes unencrypted connections are helpful (e.g. in case it is to another program on the same computer and encryption is not needed). If the client requests encryption and the server does not have it (or does, but with a weaker cipher than the client intends), then the client should display an error message and refuse to connect.
Key fingerprint validation is very helpful. This is not really specific to the SSH protocol though, and is possible with other protocols such as TLS, although the SSH client has a better user interface and user experience for this than some other programs (such as most web browsers).
(TLS has many complexity too though; most kinds of encryption will have many, although there are some experimental ideas for a somewhat simpler kind.)
> SSH supports multiplexing
Multiplexing in the protocol really is a useful feature for many purposes (although not everything should need it). Some examples are mentioned there, although others can be possible too.
> SSH is ubiquitous
It is true, and this is a good thing; but nevertheless there are some issues with this. There is still some complexity, even though it is fortunately not even half as complicated as modern WWW (although it also has a few complexities that WWW lacks).
There are also some issues having to do with different types of computers and user preferences. (WWW has these problems too and is even worse in many ways.) Environment variables can solve some of these things, but not all of them. (Some things can be solved without the server needing to know about them; e.g. you could easily program the terminal emulator to ignore the colours specified by the server, e.g. in case the server ignores the client's NO_COLOR variable.)
> SSH sounds awesome, and familiar… Binary protocol, mandatory encryption, key pinning, multiplexing, compression (yes, it does that too).
I think there are some benefits of binary protocols especially if it makes it simpler to parse than text protocols; however, text has different benefits.
TLS also supports compression, even though it is not always used (and there are aparently security issues with it that have to do with HTTP, is what I seem to remember), and also seems to be deprecated.
Multiplexing also would be possible with other kinds of protocols that are designed to support it.
Key pinning also can be done independently of the protocol; the SSH client does that, and it is helpful, but it isn't something that necessarily needs the SSH protocol in order to work.
They also mention that virtual hosting is not supported, so this is another problem with SSH. (TLS does have virtual hosting.)
> Why aren’t we using SSH for everything?
Well, I think although it has many benefits, there are also many problems with it (e.g. SSH does not have virtual hosting). However, both many of these benefits and many of these problems are mostly independent of the protocol.
Also, different protocols and different file formats are useful for different purposes, rather than needing only one kind. There are many kinds.
In my opinion, the user interface for SSH tends to be better designed in some ways, than the user interface of web browsers; however, this is not really an issue with either protocols themself.
> Key pinning also can be done independently of the protocol; the SSH client does that, and it is helpful, but it isn't something that necessarily needs the SSH protocol in order to work.
While it was not entirely perfect Google threw in the towel with HPKP and they do not seem to want to reopen the debate. All the meanwhile they utilize static pinning for their own properties in Chromium [1] and 'secure' domain registration (MarkMonitor) that is very difficult to obtain when not a large corporation. Leaving the rest of us as fine pickings against those who can hijack domains and obtain a CA issued certificate to conduct MiTM attacks.
This, known as fingerprinting, is collectively considered a bad thing. I am thankful this isn't elsewhere