In a First, Cryptographic Keys Protecting SSH Connections Stolen in New Attack 95
For the first time, researchers have demonstrated that a large portion of cryptographic keys used to protect data in computer-to-server SSH traffic are vulnerable to complete compromise when naturally occurring computational errors occur while the connection is being established. ArsTechnica: Underscoring the importance of their discovery, the researchers used their findings to calculate the private portion of almost 200 unique SSH keys they observed in public Internet scans taken over the past seven years. The researchers suspect keys used in IPsec connections could suffer the same fate. SSH is the cryptographic protocol used in secure shell connections that allows computers to remotely access servers, usually in security-sensitive enterprise environments. IPsec is a protocol used by virtual private networks that route traffic through an encrypted tunnel.
The vulnerability occurs when there are errors during the signature generation that takes place when a client and server are establishing a connection. It affects only keys using the RSA cryptographic algorithm, which the researchers found in roughly a third of the SSH signatures they examined. That translates to roughly 1 billion signatures out of the 3.2 billion signatures examined. Of the roughly 1 billion RSA signatures, about one in a million exposed the private key of the host. While the percentage is infinitesimally small, the finding is nonetheless surprising for several reasons -- most notably because most SSH software in use has deployed a countermeasure for decades that checks for signature faults before sending a signature over the Internet. Another reason for the surprise is that until now, researchers believed that signature faults exposed only RSA keys used in the TLS -- or Transport Layer Security -- protocol encrypting Web and email connections. They believed SSH traffic was immune from such attacks because passive attackers -- meaning adversaries simply observing traffic as it goes by -- couldn't see some of the necessary information when the errors happened.
The vulnerability occurs when there are errors during the signature generation that takes place when a client and server are establishing a connection. It affects only keys using the RSA cryptographic algorithm, which the researchers found in roughly a third of the SSH signatures they examined. That translates to roughly 1 billion signatures out of the 3.2 billion signatures examined. Of the roughly 1 billion RSA signatures, about one in a million exposed the private key of the host. While the percentage is infinitesimally small, the finding is nonetheless surprising for several reasons -- most notably because most SSH software in use has deployed a countermeasure for decades that checks for signature faults before sending a signature over the Internet. Another reason for the surprise is that until now, researchers believed that signature faults exposed only RSA keys used in the TLS -- or Transport Layer Security -- protocol encrypting Web and email connections. They believed SSH traffic was immune from such attacks because passive attackers -- meaning adversaries simply observing traffic as it goes by -- couldn't see some of the necessary information when the errors happened.
Re: Many Eyes Strike Again! (Score:5, Informative)
From the source article : "The researchers traced the keys they compromised to devices that used custom, closed-source SSH implementations that didnâ(TM)t implement the countermeasures found in OpenSSH and other widely used open source code libraries"
Re: (Score:2)
Re: (Score:2)
MS actually use OpenSSH too. It's other vendors that came up with their own implementation.
Re: (Score:2)
This underscores the sage advice that when it comes to crypto, avoid rolling your own if you can. If they had just used the Free Software available to them, they could have avoided this.
Re: (Score:2)
My take as well. Some vendors (Zyxel, Cisco and others) did an incompetent closed-source implementation and _those_ are insecure. So, most insight-less comment today! Well done AC!
Re: Many Eyes Strike Again! (Score:5, Interesting)
These vulnerabilities were found ONLY in closed-source implementations. The OSS versions protect the key in these same situations.
SSH is less secure as a practical matter (Score:5, Interesting)
Because of the TOFU (Trust-on-first-use) nature of SSH, most people don't actually validate signatures when they connect to a server, a MITM can cause a new signature validation request, and people connecting to lots of servers often enable an option to skip checking host keys so they don't have to accept them all the time.
For these reasons, SSH is, in practical terms, much easier to compromise than TLS. As long as your operating system & tools are set up to validate certificates, you aren't vulnerable to the above problems, thus TLS is practically more secure. In addition, HTTPS connections allow overlaying extra authentication methods, like HTTP Basic Auth and OAuth2/OIDC, so even if the encryption of the connection is tainted, access still requires something more.
I get that people are emotionally attached to SSH and "prefer it" over other secure transport methods, but it's irrational. You are more likely to get pwnd using SSH.
Re:SSH is less secure as a practical matter (Score:4, Interesting)
"Trust on first use" is intended for applications where both computers are on the same local "secure" network.
If memory servers, Amazon AWS doesn't share the server's SSH keys on first-use for this reason.
And most security can be defeated by users ... :(
Re: (Score:2)
"Trust on first use" is intended for applications where both computers are on the same local "secure" network.
If memory servers, Amazon AWS doesn't share the server's SSH keys on first-use for this reason.
And most security can be defeated by users ... :(
I think you're talking about something VERY different and your mods are very confused.
It's on by default for openssh deployments at any scale, on any Linux OS I have ever seen. Non-local and non-secure networks were kind of the entire reason SSH was invented, so there's that.
Start a new AL2023 instance, ssh to it. Do you accept this server's host key? It's the same as it's always ever been.
So what do you do, write some cloud-init junk to copy your new instance's host key in first boot to an S3 bucket which
Re:SSH is less secure as a practical matter (Score:5, Informative)
The nice thing about TLS is that it only addresses the security of the communications channel between two systems. As you pointed out, this can be paired with authentication inside the channel. SSH is, by nature, a tunnel with user authentication. SSH is awesome for setting up port forwarding and virtual networks with tun/tap.
Of course, there's nothing stopping anyone from running SSH inside a TLS tunnel. This doubles the encryption overhead, though that hardly matters for most users. Such an approach would require both protocols to be breached for an attacker to succeed.
It wouldn't be too hard to modify ssh to link to a TLS library and have an option of using TLS directly to avoid having to set up stunnel to wrap it. It could even multiplex on port 443 with a web server (you can do this now with stunnel and sslh).
I do like how ssh remembers the host key. It's much more the model of key sharing used by PGP, eliminating the central authority. I only turn off checking that for specific cases where I'm connecting to internal development systems at work where a new system often replaces an old one at the same name/IP.
Re: SSH is less secure as a practical matter (Score:1)
Nope. TLS authenticate by a third-party and SSH leave that up to you. Both authenticate but noone is a silver bullet. EFF has shown that TLS third parties were not doing their duty well, random admin might be doing the same with SSH. But in the end, it's the same.
Re: (Score:2)
No, you're missing the point. TLS only does one level of authentication. In the most common case, that's host-level authentication. SSH does both host and user authentication using separate keys.
Re: (Score:2)
No, you're missing the point. TLS only does one level of authentication. In the most common case, that's host-level authentication. SSH does both host and user authentication using separate keys.
Well that's wrong, sorry.
Client certificate authentication is old as dirt. Not only does SSL/TLS have a chain of trust and metadata for server certs, but a chain of trust and metadata for client auth. You have expiration dates on client keys enforceable by the server, delegated signing, whatever policy you can dream up using x509 attributes or adding custom ones, centralized key revocation, etc.
Vs ssh which has the same pki methodology but using bare keys without x509 certs or any key metadata beyon
Re: (Score:2)
Re: (Score:2)
For a remote shell I require a more secure tunnel like wireguard, or a TLS VPN like OpenSwan, or a web app displaying a shell in-browser, or a remote access gateway in-browser like Guacamole.
Re: (Score:2)
And for those in AWS, you can use SSM connect. Don't even need port 22 open.
Re:SSH is less secure as a practical matter (Score:5, Informative)
SSH is less secure in some way, but between machine to machine, it is quite solid. For example, host "A" communicating to host "B", where a firewall is in place to remove all but the IP block needing to connect, both hosts know their SSH key, and both using public keys for authentication, it can be very secure, just as secure as a TLS VPN.
The only place where SSH over the Internet can run into trouble is not validating the key, where Alice is trying to connect to Bob's server, but the connected is MITM-ed by Mallory, and Mallory's public key info shows up on the initial trust. However, SSH is not designed to be a top-down protocol like TLS. It is designed to make connections ad hoc, and ensure the existing connections can't be tampered with. If SSH were a top-down protocol, just logging into a host that was freshly installed would be a PITA to an impossibility.
SSH does have the ability to accept certificates, but it isn't used by default.
Re: (Score:2)
It is designed to make connections ad hoc, and ensure the existing connections can't be tampered with. If SSH were a top-down protocol, just logging into a host that was freshly installed would be a PITA to an impossibility.
Literally the same way you connect to anything using TLS the first time. Accept the untrusted certificate warning. Replace it with a chain-of-trust signed certificate. Or you provision that when the system/application/thing was being created. With ssh you're just doing the first two steps.
How do you log into a freshly installed host? Not with a blank password right? So how did that get on the system? Creating servers is top down ...
Re: (Score:3)
Re: (Score:2)
And in the world of Terraform and Git, you can pre-populate keys on systems while provisioning.
If implementing infrastructure-as-code, there's basically no reason to turn off signature verification unless you are constantly connecting to ephemeral resources where you aren't necessarily going to have the signature, and it's happening fast enough that there are unresolvable race conditions. And then if you are disabling signature verification on a regular basis, you should probably re-examine the processes t
Re: (Score:1)
By doing so, people understand they don't validate the host in any way, and expose themselves to mitm. I don't know anyone who does that. Its like going beyond the big fat warning while navigating to https://wrong.host.badssl.com/ [badssl.com]; or rather like disabling this warning in your browser settings.
HTTPS connections allow overlaying extra authentication methods
Once the ssh client authenticated the server, the server m
Re: (Score:2)
This would be a non-issue if the proprietary SSH clients that were compromised properly checked for weak signatures before transmitting them like OpenSSH does.
A nice thing about SSH is you don't have to be a slave to a CA and whatever their rules of the day might be just to allow yourself an encrypted remote login.
I would prefer that browsers stop telling me what MY security policy should be and let me pin a cert without expiration.
Re: (Score:2)
Nope. What is easier to compromise is ssh _users_. SSH is a professional tool. Used incompetently, it may well be insecure, but so what? You "argument" is bullshit. May as well claim a chef's knife is dangerous and should not be used or similar nonsense. In actual reality, what you do is you _learn_ how to use the tool right.
Re: (Score:2)
Oh, and try having users actually install client certs for TLS. Good luck with that.
Re: (Score:2)
I bet more people blindly install self-signed TLS certificates or approve expired ones when prompted than disable ssh host key checking.
Re: (Score:2)
Both numbers will be quite small and pretty irrelevant.
Re: (Score:2)
Because of the TOFU (Trust-on-first-use) nature of SSH, most people don't actually validate signatures when they connect to a server, a MITM can cause a new signature validation request, and people connecting to lots of servers often enable an option to skip checking host keys so they don't have to accept them all the time.
That's human nature for you. They hate doing crap that inconveniences them. So they get the security they deserve as a result.
As long as your operating system & tools are set up to validate certificates, you aren't vulnerable to the above problems, thus TLS is practically more secure.
Funny, I thought those problems being an issue was why they came up with HTTP Public Key Pinning [wikipedia.org] and is the core backbone of HSTS [wikipedia.org].
If anything TLS is more vulnerable than SSH because the people using TLS are more likely to be completely in the dark about the risks or indeed completely ignorant as to what TLS even is. (Hard to securely use something you have zero knowledge about.)
In addition, HTTPS connections allow overlaying extra authentication methods, like HTTP Basic Auth and OAuth2/OIDC, so even if the encryption of the connection is tainted, access still requires something more.
Re: (Score:1)
> don't actually validate signatures when they connect to a server
In practice, to exploit this, an attacker would have to MITM your connection _the very first time you ever connect to the sever_ from your computer or device. They can't do it later. Thus, although it's arguable that you aren't perfectly verifying that the server is run by who you think it's run by in some cases, what you *are* meant to be verifying, is that it's the
Compiler solution? (Score:5, Interesting)
This requires one of the two computers to have an infrequent hardware error. If one assumes a low error rate (1 in a billion) and a multi-core processor, then it should be possible to fix this class of bugs in software.
Theoretically, it should be possible to create a compiler that takes any given encryption algorithm, compiles it in two different heterogeneous ways, confirms the calculation, and only sends correct information out over the wire. This is already done in some safety sensitive applications, often with two processors to run each of the two different programs.
For software like SSH, the software would need to move to coding security sensitive algorithms with language / compiler / toolchain that automatically confirms the results before sending them out.
Re: (Score:3, Informative)
Theoretically, it should be possible to create a compiler that takes any given encryption algorithm, compiles it in two different heterogeneous ways, confirms the calculation, and only sends correct information out over the wire.
This was already fixed in OpenSSL almost twenty years ago.
The problem occurs only during new key-pair generation, not during TLS connection setup.
OpenSSL simply runs the same function twice in a row in different areas of memory, and if they differ it rejects the result and starts over.
Solutions like ECC memory were deemed not a solution, because *both* sides of the connection need to have their own key-pairs.
ECC is wise to have on servers, even if not an expectation.
Yet ECC on the client end is completely u
Page 2 of the article contains the critical info (Score:5, Informative)
Re:Page 2 of the article contains the critical inf (Score:5, Funny)
Think of how much they improved their time to market by not implementing these checks. That's the part no one is talking about.
Re:Page 2 of the article contains the critical inf (Score:5, Insightful)
Think of how much they improved their time to market by not implementing these checks. That's the part no one is talking about.
The sad part is that they could have just used OpenSSH and saved even more time. I can't imagine why anyone would roll their own implementation, unless their implementation predates OpenSSH/OpenSSL. Forking it, maybe (and hopefully frequently pulling from upstream), but not writing a whole separate implementation.
Re: (Score:2)
There could be very good reasons. I wonder if you can trigger these errors, maybe with a specific pattern of connection attempts. Wouldn't that be convenient?
Maybe they do use OpenSSH, they just forked it to add specific features.
Re:Page 2 of the article contains the critical inf (Score:5, Insightful)
"The researchers traced the keys they compromised to devices that used custom, closed-source SSH implementations that didn't implement the countermeasures found in OpenSSH and other widely used open source code libraries. The devices came from four manufacturers: Cisco, Zyxel, Hillstone Networks, and Mocana. ..."
Oh, good Lord. Shouldn't that teeny bit of information have landed somewhere in the SLASHDOT SUMMARY?
This is still important news... but it changes the entire complexion of the problem.
Re: Page 2 of the article contains the critical in (Score:2)
Good thing the summary has "only RSA".
We're not using RSA these days, right. I hope. I haven't for 10 years now, ever since https://www.scientificamerican... [scientificamerican.com] was critical enough for me to switch to DSA.
Re: (Score:2)
For the past several years, I've been using ed25519, not because of security, but because of the much shorter key length. Hopefully that is less vulnerable to stuff than RSA.
Re: (Score:2)
I've been using ed25519 as well. But for quite some time I also had to keep an older RSA key around as fallback, since we had some research labs that refused to move off CentOS 6 for some time after its EOL. But I believe we got those all remediated as of a few years ago (fingers crossed... it's not beyond the bounds of possibility that some old box has been sitting, powered off, in a dark corner somewhere).
Re: (Score:2)
Re: (Score:2)
> somewhere in the SLASHDOT SUMMARY?
Nah, headline.
Embedded SSH Stacks Can Leak Private Keys under Error Conditions
Liars. This is for closed source crapware. (Score:5, Insightful)
Re: (Score:2)
you are going to hear us singing "SHUT THE FUCK UP" with the tune of the hallelujah chorus
Thanks. Won't be able to unhear that one for a while. Though I don't disagree with the sentiment.
Re: (Score:2)
you are going to hear us singing "SHUT THE FUCK UP" with the tune of the hallelujah chorus
Thanks. Won't be able to unhear that one for a while. Though I don't disagree with the sentiment.
Likewise. I'm hearing the second strain as "For words of such an imbecile draineth," and the third strain as "The cluelessness you spew has become an ever-present pain that hurts my head," followed by "And you shall cease forever and ever, ding-a-ling and troll of trolls."
Re: (Score:2)
Re: (Score:2)
OpenSSH isn't used everywhere. In fact, "crapware" is probably more widely used. And TFS went into considerable detail going including years of testing outlining who and what is affected. Not sure what the FUCK you're bitching about.
As far as the "liars" creating headlines, clickbait makes money today. Go figure liars gonna lie. For profit. Welcome to 21st Century "news" reporting.
The NSA? You mean expect a big cash payout from the country struggling to fund their own government? Good luck with that
Re: (Score:2)
The NSA? You mean expect a big cash payout from the country struggling to fund their own government? Good luck with that.
You may have noticed that the people that do their best to obstruct funding the government never fail to fully fund the defense establishment, usually buying shit through the force of federal law that the Pentagon doesn't even want because it happens to be manufactured in an electoral swing state, or some Congress critter's district where the party leadership decides that they want to keep a particular useful idiot member around a little longer.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
LibreSSH is probably safer, though.
Re: (Score:2)
Re: (Score:2)
"Sufficient processing power" in modern times is generally measured in computers that use all the matter in the universe and/or lifetimes of the universe.
If you figure out the other guy's private key, as described here, you can decrypt any message you like and encrypt completely new ones too.
Re: (Score:2)
It makes for good headlines, but bad descriptions of reality. A plague of our times.
Okay, but the footprint should be small (Score:2)
Oh, and this is why changing your SSH port is functionally useless, so if you're doing that thinking it adds anything, just stop it, please!
Re:Okay, but the footprint should be small (Score:5, Insightful)
Changing the ssh port just keeps a lot of noise out of the logs of scripted attacks. It does nothing directly for security from a focused attacker. If there's some big hole being exploited in the future, it may give you another day or two before you get hit, during which time you may get a patch applied. It may mean that you notice a more sophisticated attack because it's not hidden in the flood of stupid scripted attacks. It may mean your log file doesn't fill up your disk if you messed up on managing that.
So not useless, but it doesn't buy you much security. I wouldn't bother on an internal network, but on a firewall, shutting off the noise is nice.
Re: (Score:2)
Re: (Score:2)
You need to find new people to have security conversations with, if security-through-obscurity is their go-to playbook.
Changing the SSH port just makes someone that has any clue at all run nmap and continue about their business with the new port number.
Re: (Score:2)
Indeed. Security-by-obscurity is one of these really bad ideas that seem to be unable to die. Always a reliable indicator the person recommending it has no clue at all. That no-clue often comes with a big ego on the crypto-space though.
There is a use-case for a changed ssh-port though: Idiotic mobile carriers that block port 22. I had to run ssh on port 443 for a while to get through. Fortunately enough people seem to have yelled at them to stop it and now it works.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
But in practice, it merely mitigates the impacts in case of compromise. Thats the reason why we are bugged with password and key rotation: so that in case its compromised, it cannot be reused (much longer).
Re: (Score:2)
Incidentally, _no_ major security catalog is any longer asking for password rotation and many have started to actively discourage it. It does not prevent attacks, but it leads to users selecting worse passwords. As a security mechanism enforced password rotation is a complete fail. Another bad idea that refuses to die.
Re: (Score:2)
I'm not buying that one at all, if there's any exposure whatsoever of the SSH keystores to possible automation, or if the device / service vendor is doing anyone a favor and exposing providers or an API for management and configuration. One could trivially write some scripting that generates new keys, store them in a proper secrets management system, and then insert the public keys where they need to be across your infrastructure if you are using any infrastructure-as-code concepts whatsoever. You then go
Re: (Score:2)
Ironically, not using the standard port would make you less vulnerable to this attack since it's based on scanning zillions of machines and relying on a one in a million error. Or you could just use a proper implementation of SSH.
I run an ssh server on a nonstandard port because some dum dums block outgoing port 22.
Re: (Score:2)
Re: (Score:2)
I can understand some ISPs blocking outgoing 22 just to be annoying. How I get around that is that I have a VM in a cloud provider. The internal machine uses AutoSSH to connect to that VM (which has a static IP) and forward that port. If I want to connect, I use SSH's "-j" functionality to connect to the VM, then jump through loopback and use the other SSH tunnel to the internal machine.
Of course, using a different port works, but with a lot of ISPs using CG-NAT, even moving it may not work.
Re: (Score:2)
Not sure about ISPs. Mine doesn't seem to care. Hospitals though. I know one that blocks everything coming in (reasonable) and everything except 80 and 443 going out. Want to check your e-mail? Go find a Starbucks.
So I just happen to have an ssh server that listens on port 80.
Re: (Score:2)
Ah, what? That is complete bullshit. You are probably making things less secure with that "common sense". The only reason why you do IP locking is to cut down on the log-volume, not for security reasons. And either your keys are secure, then you do not need to change them, or they are not, then you must not use them even for a short time.
Sound slike amateur-level secure protocol design, where somebody without a clue just throws some more-or-less random security mechanisms together and thinks that improve se
Re: (Score:2)
Re: (Score:2)
Exactly. The risk that you may make a mistake when changing the keys is is a real concern. Key insecurity is not. Well, unless some nil wit messes with CPRNG initialization (Debian), but that is fortunately very rare. https://www.schneier.com/blog/... [schneier.com]
Re: (Score:2)
You also left out the rest of what I said, use MFA, so you still have a password, and TOTP
Re: (Score:2)
You really should look into "if it is not broken, do not fix it". It applies to security even more than to other things.
Re: (Score:2)
I'm going to assume, and please correct me if I'm wrong, you don't force PGP use with email?
Re: (Score:2)
Common sense SSH practices tell you one key for one server / service, and generate new keys every 3–6 months.
Man, I bet you're a lot of fun at parties. Who changes keys every 3-6 months? I usually keep the keys to a server throughout not only its life, but the replacement hardware's life. If you change them often and have to accept new keys every 3-6 months, how will you know you're not getting MITM attacks one of those times? How would you go about even being sure that it's the right key you're accepting? Do you print them and keep a hard copy?
Re: (Score:2)
People have to sign their keys with my PGP key, and I run / control our GPG key ring, so I can validate any PGP key against any user identity. When I change the host keys, I properly sign / encrypt the email with the new information, so people can validate the host keys signature. The last time I changed the keys, I think it took less than 1 hour, which is my mind is pretty good.
Do you print them and keep a hard copy?
18 years? (Score:1)
Re: (Score:2)
Maybe they're quoting someone from a decade ago?
Re: (Score:2)
Are Accounts With PSKs Vulnerable? (Score:2)
Or even better.... (Score:2)
Friends don't let friends use RSA (Score:4, Insightful)
RSA, especially with the old deterministic padding schemes, is just too fragile. It can be implemented safely, but doing so requires a lot of care to mitigate the raft of subtle pitfalls. When you add to that the fact that the keys, signatures and ciphertexts are annoyingly large, and that generating keys is very time-consuming, there's just no reason to use RSA, and everyone should stop.
Every competent cryptographic security engineer I know treats use of RSA as a "design smell", an indicator that a design is likely bad, and a very strong indicator that the designer doesn't know what they're doing. That's not to say there's never a reason to use it, but the reasons are few, and rare.
Re: (Score:2)
Re: (Score:2)
Its not like its hard to understand what the pitfalls are.
You think? Then why -- nearly 50 years after its creation -- do we still have articles like this one?
If your answer is "because people are stupid", my response is that if you have two saws which both do exactly the same job, but one requires people to use it carefully or it'll cut their fingers off while the other doesn't, and is smaller, cheaper and faster, you're the idiot if you keep the dangerous one in your shop. There's just no reason to use the slow and dangerous tool when the fast and safe one is
Re: (Score:2)
Re: (Score:2)
If openssh uses the same RSA but took steps to fix the exposure than clearly this RSA is a requirement for ssh.
It's not. SSH has supported other, better, options and even made them the default for many years now.
OpenSSH not affected? (Score:2)
As far as I can tell from a brief look at the paper, OpenSSH is actually not affected, probably because it verifies the signature before sending it. What seems to be affected is several commercial closed versions by Zyxel, Cisco and others.
Not new (Score:2)