Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Tuesday June 02 2020, @12:50PM   Printer-friendly
from the about-time dept.

Dangerous SHA-1 crypto function will die in SSH linking millions of computers:

Developers of two open source code libraries for Secure Shell—the protocol millions of computers use to create encrypted connections to each other—are retiring the SHA-1 hashing algorithm, four months after researchers piled a final nail in its coffin.

The moves, announced in release notes and a code update for OpenSSH and libssh respectively, mean that SHA-1 will no longer be a means for digitally signing encryption keys that prevent the monitoring or manipulating of data passing between two computers connected by SSH—the common abbreviation for Secure Shell. (Wednesday's release notes concerning SHA-1 deprecation in OpenSSH repeated word for word what developers put in February release notes, but few people seemed to notice the planned change until now.)

Cryptographic hash functions generate a long string of characters that are known as a hash digest. Theoretically, the digests are supposed to be unique for every file, message, or other input fed into the function. Practically speaking, digest collisions must be mathematically infeasible given the performance capabilities of available computing resources. In recent years, a host of software and services have stopped using SHA-1 after researchers demonstrated practical ways for attackers to forge digital signatures that use SHA-1. The unanimous agreement among experts is that it's no longer safe in almost all security contexts.

"Its a chainsaw in a nursery," security researcher Kenn White said of the hash function, which made its debut in 1995.

[...] The final death knell for SHA-1 sounded in January, when researchers unveiled an even more powerful collision attack that cost as little as $45,000. Known as a chosen prefix collision, it allowed attackers to impersonate a target of their choosing, as was the case in the MD5 attack against Microsoft's infrastructure.

It was in this context that OpenSSH developers wrote in release notes published on Wednesday:

It is now possible to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.

[...] In an email, Gaëtan Leurent, an Inria France researcher and one of the co-authors of the January research, said he didn't expect OpenSSH developers to implement the deprecations quickly. He wrote:

When they completely disable SHA-1, it will become impossible to connect from a recent OpenSSH to a device with an old SSH server, but they will probably take gradual steps (with big warnings) before that. Also, embedded systems with an SSH access that have not been updated in many years probably have a lot of security issues, so maybe it's not too bad to disrupt them...

In any case, I am quite happy with this move, this is exactly what we wanted to achieve :-)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by DannyB on Tuesday June 02 2020, @06:12PM (2 children)

    by DannyB (5839) Subscriber Badge on Tuesday June 02 2020, @06:12PM (#1002274) Journal

    I've had Firefox crash because a library it was using was updated.

    That is an interesting problem, but I don't run Firefox on servers. That problem could happen to any program if underlying libraries are replaced under your nose.

    I forgot to mention that the ease of rolling back is of course an important consideration.

    Yes.

    I mostly think in terms of rolling back Java, Tomcat or some third party library. But this type of problem is caught long before going to production. I would be surprised if an OS upgrade could cause a problem, since Java is a layer in between, and Java is "almost" an OS. Everything ultimately goes through Java. File I/O, Network I/O, Threads. That's why it works on very different OSes.

    I'm thankful that in ten years I manage to keep everything up to date, not bleeding edge, but not too far behind leading edge. Letting some things get way out of date is a ticking time bomb. You go to upgrade it leapfrogging multiple versions, and have major problems. Even if those problems are not experienced in production.

    Basically: testing, and production doesn't get new things that haven't been tested.

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Tuesday June 02 2020, @10:17PM (1 child)

    by Anonymous Coward on Tuesday June 02 2020, @10:17PM (#1002428)

    That problem could happen to any program if underlying libraries are replaced under your nose.

    Open if the application uses dlopen() or the OS is immature. On mature operating systems, linked shared libraries are kept open while the application is running, and that link is maintained even if the filesystem entry gets removed (that's why it's called unlink, not delete).

    • (Score: 0) by Anonymous Coward on Tuesday June 02 2020, @10:51PM

      by Anonymous Coward on Tuesday June 02 2020, @10:51PM (#1002472)

      And? Things like Firefox and Apache and other daemons, to name a few, use multiple processes working in concert in a single program. If different processes of the program start at different times, then you can easily run into the situation where they are using different versions of the same library. It isn't uncommon that those processes end up conflicting or crashing.