> The ISRG estimates ~80% of the vulnerabilities exploited in the wild are memory safety bugs.
Okay, but 1. How many vulnerabilities has openssh shipped, and 2. How many of those were memory issues? I would usually be tentatively on board, but you're competing with the OpenBSD folks, who have a shockingly good track record regardless of using C. No offense, but you could write in a formally verified Ada subset and I'd still hesitate to replace my SSH daemon.
(FWIW, I say all of this hoping to be wrong; an alternative implementation, if equally secure, would be great to have.)
The 2019 bug refers to a bug in an explicitly experimental area of SSH code (post-quantum crypto XMSS)
most of the other server-side bugs on the list relate to non-standard configs (of varying obscurity)
the fact that - in an era of increasingly hostile cyber threats - years had gone by without any serious threats says it all really.
for most people, they should just run normal SSH, enable public-key only authentication and get on with their lives.
I see no reason why anyone should jump ship to some shiny new untested ssh server. Especially as , when others have pointed out, the people behind OpenSSH are the same people behind OpenBSd and LibreSSL.
For reference, the first is with an experimental feature, second is a local privilege escalation, and the third allowed a malicious server to read the clients keys. For comparison, here's some CVEs from software written in Go:
No silver bullets! Though some have less lead in them. OpenSSH, along with other software developed by OpenBSD, has earned the highest level of trust in something written in C. C can be dangerous, but there is a chasm between such careful works and the typical offenders like OpenSSL (OpenBSD's alternative is LibreSSL, confusingly).
Another aspect is that security software has additional requirements that most other software doesn't, and that can be a problem. My impression is that the crypto community generally regards the Go crypto stack as fairly algorithmically solid, but it hasn't necessarily been hammered on to the n'th degree for things like timing attacks. I'm comfortable using it in my usecases, but I'd be a bit nervous about deploying it to my high-security stuff. Things like reaching out to the network for crypto keys is also a convenient feature in some ways but something I'd want to see much, much hardened compared to what I might ask of a non-security program doing something similar.
That said, I don't say this to discourage the project. I wish it all the best and hope that they continue to work out the issues involved. I'm speaking more here to dampen the set of programmers and/or ops I know who will read something like this and immediately begin converting their entire fleet, because this looks new and hot and uses $TECH I like and must therefore be better than the old and busted using $BADTECH I don't like. Hey, I'm on the cutting edge of hating C and thinking almost anything written in it should be banned from the network, but OpenSSH does have a pretty good track record and that shouldn't be chucked overboard for new untested hotness.
Best wishes to Caddy-SSH. I would encourage a bit of trying it out, just, you know, don't go crazy. I don't think they'd want you to either!
Ceteris paribus, I would feel safer with OpenSSH than with a new SSH server probably for several years after the release of that new server, simply because OpenSSH is so scrutinized and because there's more things that go wrong with SSH than memory safety bugs. It's been well over a decade since the last exploitable OpenSSH bug. But it would also be a very good thing to have a memory-safe trusted SSH server. This isn't an easy call.
I think it will just take some time. I'm glad we have a solid start on a new alternative, and hopefully people will use it, scrutinize it, and improve it. It's a little unsettling to realize that when the next vuln in OpenSSL is discovered, it will likely effect 99% of servers on the Internet. (Or something like that.) I'd feel a little better if that percentage is brought down by something that isn't susceptible to those kinds of vulns in the first place.
i think the point is that not everybody can be quite as awesome as the OpenBSD folks, and memory-safe languages can allow mortals to write secure software.
if this helps us get away from the scenario where literally everybody uses the same SSH server implementation, i think it's a great thing.
I'm assuming this being Go and the mention of being extensible through Caddy modules (in-process API) that this is a monolithic, non-privilege-separated server, which likely makes it quite a bit worse than OpenSSH sshd in terms of defense in depth.
> Finally, I really hope this is a separate daemon. SSH served by a web server invokes a certain systemd feeling
That's entirely up to you. Caddy v2 is designed as an "app platform"; the HTTP app is just one such app that Caddy happens to ship with, but anything else can be plugged in, like an SSH app in this case. You don't have to run both HTTP and SSH in the same process, you could run two instances of Caddy each with their own purpose, if you feel like. https://caddyserver.com/docs/architecture
Not sure what you mean with systemd. All big parts of it run as separate, locked down processes.
But yeah, just for the time when you're hammered with traffic that you want to investigate, you don't want your web server and SSH session to go through the same loop.
Not sure about the statistics but one of the most memorable vulnerabilities in recent history, Heartbleed, was exactly this, a OpenSSH memory safety issue.
Sibling commenters have already pointed out you're confusing OpenSSH with OpenSSL.
For additional context, since the gp mentioned that:
> the OpenBSD folks, who have a shockingly good track record
Not only is OpenSSH a BSD project, but so is LibreSSL (the OpenSSL fork that was a response to Heartbleed). Before LibreSSL, BSD folk were also working on assl - similarly an OpenSSL alternative motivated by the BSD guys having concerns about OpenSSL's codebase. So they very much have a solid track record of being pro-actively on top of this type of stuff.
However, on that note it's worth taking a moment to look at recent OpenSSL bugs and compare LibreSSL and see that unsurprisingly (to me anyway) the OpenBSD people did not magically fix the bugs in hairy C code. Once Libressl had taken out the unnecessary stamp collecting from OpenSSL (crypto algorithms you will never need, feature switches left over from experiments a decade ago, etc.) it did not in fact evolve the rest of the codebase as much as you might imagine.
If you've found a bug in pre-fork OpenSSL core material (not the stamp collecting), chances are that it still works in all the forks, none of them have the beyond wizard level competence to rewrite somebody's micro-optimised ECDHE implementation in a way that non-wizards can review, so even if they replaced it they'd just be swapping possibly-incorrect wizard magic for different possibly-incorrect wizard magic and what's the point of that?
Okay, but 1. How many vulnerabilities has openssh shipped, and 2. How many of those were memory issues? I would usually be tentatively on board, but you're competing with the OpenBSD folks, who have a shockingly good track record regardless of using C. No offense, but you could write in a formally verified Ada subset and I'd still hesitate to replace my SSH daemon.
(FWIW, I say all of this hoping to be wrong; an alternative implementation, if equally secure, would be great to have.)