What You Need to Know About the New OpenSSH Security Updates
Table of Contents
Daniel Elkabes is the Senior Security Researcher at Mend
OpenSSH released v8.2, implementing proactive security measures to protect users from future threats
Earlier this week the OpenSSH project announced the release of version 8.2. The new release includes a few impressive security updates like first steps towards deprecation of RSA-SHA1, and support for FIDO/U2F hardware tokens. OpenSSH’s v8.2 security updates is an impressive example of a project taking the initiative to upgrade security methodologies to address and prevent security risks.
Before we dive into what the security updates are, why they are important, and what they mean to you, let’s take a step back to take a look at the OpenSSH project. OpenSSH is one of the most popular implementations of the SSH protocol, enabling encrypted and secure network traffic. The developers behind it are the OpenBSD Project, that also developed and maintain the OpenBSD Unix-like operating system.
OpenSSH is the primary reference for SSH clients, and has become the standard for anyone using the SSH protocol. Since it supports macOS, Windows, and almost any Linux distributions, OpenSSH can and is used by pretty much everybody.
What Are the New Security Updates in OpenSSH v8.2?
There are two major security measures that the OpenSSH team presented in version 8.2:
#1 OpenSSH v8.2 now supports FIDO/U2F
The first significant security enhancement is that OpenSSH now fully supports FIDO/U2F hardware authenticators. The FIDO Alliance is an open industry association that aims to help reduce what they call “the world’s over-reliance” on passwords. One of FIDO’s solutions is U2F (Universal 2nd Factor), a simple 2-factor authentication key, developed by Google and Yubiko, that allows users to access online services securely, via a USB that they can insert into any port.
Why?
Passwords have been the conventional form of authentication for decades. In that time, attackers developed several techniques to bypass password-secured resources, while users have not been giving secure passwords the attention that they need. 2-factor authentication is one of the best ways to address this issue and protect against various types of attacks like session hijacking, man-in-the-middle, keyloggers, brute-force, and phishing, to name a few.
#2 RSA-SHA1 Deprecation
In a proactive step to enhance security, the OpenSSH team also announced the deprecation of RSA-SHA1, one of the most commonly used encryption algorithms. This release excludes the RSA-SHA1 algorithm from the list of accepted certificate signatures and will use the RSA-sha2-512 signature algorithm by default when signing new certificates.
Why ?
Last month a group of researchers published their findings which showed that chosen-prefix collision could be used to attack against SHA-1. While we already know that SHA-1 collision is possible, chosen-prefix collision is on a completely different scale.
The difference between a chosen-prefix collision attack and the classic collision attack is that a chosen-prefix collision attack depends only on the prefix, and an entirely arbitrary certificate can be used. A chosen-prefix collision attack can break an SSH handshake and that’s why it is important to address it as soon as possible.
According to OpenSSH v8.2 release notes, “Certificates are at special risk to the aforementioned SHA1 collision vulnerability as an attacker has effectively unlimited time in which to craft a collision that yields them a valid certificate”.
OpenSSH v8.2 Patch for RSA-SHA1 Users
For users that are still relying on the RSA-SHA1 public key, it’s important that you know that the OpenSSH team still hasn’t removed the RSA-SHA1 public key by default. They stated it will happen in a near-future release. In addition, they will enable “UpdateHostKeys” by default, so that the hosts will automatically migrate to better algorithms.
Until then, we suggest verifying that your servers aren’t using the weak public key algorithm for authentication. To check that, you need to remove the RSA-SHA1 from the list of allowed host key algorithms:
If the verification fails and no other key types are available, then you need to upgrade the server software.
Key Takeaways from the OpenSSH v8.2 Security Updates
The proactive approach that OpenSSH is taking with this release, addressing recently discovered security threats that still haven’t been found in the wild, is impressive and uncommon in the software development eco-system.
It’s important to note that while research about chosen-prefix collision attacks is certainly alarming, it is probably not the type of attack that your average everyday hacker will pursue, because it’s extremely time-consuming and expensive. Researchers estimate that the cost of this attack today is around $45,000 — certainly not worth the trouble for attackers looking for quick cash.
It’s also important to keep in mind that while RSA-SHA1 was found vulnerable to chosen-prefix collision attacks, that doesn’t mean that everyone that uses the SHA1 algorithm needs to panic and find alternatives.
The OpenSSH’s choice to take preventative steps to address potential security threats is a great example for the open source and security community.