OpenSSH announces DSA-removal timeline
The only remaining use of DSA at this point should be deeply legacy devices. As such, we no longer consider the costs of maintaining DSA in OpenSSH to be justified. Moreover, we hope that OpenSSH's final removal of this insecure algorithm accelerates its deprecation in other SSH implementations and allows maintainers of cryptography libraries to remove it too.
| From: | Damien Miller <djm-AT-mindrot.org> | |
| To: | openssh-unix-dev-AT-mindrot.org | |
| Subject: | Announce: timeline to remove DSA support in OpenSSH | |
| Date: | Thu, 11 Jan 2024 15:40:37 +1100 | |
| Message-ID: | <[email protected]> |
Hi, OpenSSH plans to remove support for DSA keys in the near future. This message describes our rationale, process and proposed timeline. Rationale --------- DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key and use of the SHA1 digest. Its estimated security level is <=80 bits symmetric equivalent[1][2]. OpenSSH has disabled DSA keys by default since 2015 but has retained optional support for them. DSA is the only mandatory-to-implement algorithm in the SSHv2 RFCs[3], mostly because alternative algorithms were encumbered by patents when the SSHv2 protocol was designed and specified. Since then, the world has moved on. RSA is unencumbered and support for it is ubiquitous. ECDSA offers significant performance and security benefits over modp DSA, and EdDSA overs further performance and security improvements over both again. The only remaining use of DSA at this point should be deeply legacy devices. As such, we no longer consider the costs of maintaining DSA in OpenSSH to be justified. Moreover, we hope that OpenSSH's final removal of this insecure algorithm accelerates its deprecation in other SSH implementations and allows maintainers of cryptography libraries to remove it too. Process and timeline -------------------- The next release of OpenSSH (due around 2024/03) will make DSA optional at compile time, but still enable it by default. Users and downstream distributors of OpenSSH may use this option to explore the impact of DSA removal in their environments, or to hard-deprecate it early if they desire. Around 2024/06, a release of OpenSSH will change this compile-time default to disable DSA. It may still be enabled by users/distributors if needed. Finally, in the first OpenSSH release after 2025/01/01 the DSA code will be removed entirely. In summary: 2024/01 - this announcement 2024/03 (estimated) - DSA compile-time optional, enabled by default 2024/06 (estimated) - DSA compile-time optional, *disabled* by default 2025/01 (estimated) - DSA is removed from OpenSSH Questions --------- * What if I have devices that only support DSA? Removing DSA from OpenSSH will not remove endpoints that require DSA from the world and users may still need to connect to them. Although new releases of OpenSSH will no longer support DSA, past releases and alternate SSH implementations will continue to do so. We recommend that users with an ongoing need to connect to DSA-only endpoints maintain a legacy release of an OpenSSH client for this purpose, similar to what was recommended when support for the SSHv1 protocol was removed. For example, Debian maintains a "openssh-client-ssh1" package built from OpenSSH 7.5 for the purpose of connecting to SSHv1 endpoints. This package or something similar is likely to be sufficient for DSA-only endpoints too. * Doesn't this make OpenSSH non-compliant with RFC4253? Practically, no more than we've been since 2015 when we stopped offering DSA by default. * Why make this change now? Why not earlier/later? We feel like enough time has passed since DSA was disabled by default for the overwhelming majority of users to have abandoned use of the algorithm. We are also likely to start exploring a post-quantum signature algorithm soon and are mindful of the overall size and complexity of the key/signature code. * I want to discuss this change further The https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev mailing list is the best place to discuss this. Alternately you can email the OpenSSH developers at [email protected]. Thanks, Damien Miller, on behalf of the OpenSSH project [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIS... [2] https://www.rfc-editor.org/rfc/rfc9142.html#section-1.1 [3] https://www.rfc-editor.org/rfc/rfc4253.html#section-6.6
Posted Jan 11, 2024 16:34 UTC (Thu)
by james (subscriber, #1325)
[Link] (30 responses)
I think that if
I can't think of a reliable equivalent for DSA-only clients, but in my experience, it's rarely the clients that are the problem.
Otherwise you'll see a list of servers which have used DSA keys in the past, or a message that .ssh/known_hosts doesn't exist, in which case you probably don't use SSH.
If I'm wrong about that, I'm sure somebody will correct me!
Posted Jan 11, 2024 20:03 UTC (Thu)
by ewen (subscriber, #4772)
[Link] (29 responses)
So I’d suggest scanning ~/.ssh/config and shell scripts for options re-enabling DSA at runtime. In my experience it’s only very old embedded devices (eg old Mikrotik routers or console servers) that went DSA only, for patent reasons. And similar newer devices usually have RSA2 and/or Ed25519 now. Most of that DSA-only hardware is so old that it shouldn’t be in production use any more anyway. So by 2025 it’s possibly only lab setups reusing old hardware that can’t get updates which will be affected.
Ewen
Posted Jan 11, 2024 21:14 UTC (Thu)
by pizza (subscriber, #46)
[Link] (28 responses)
There's a _long_ tail of old hardware finding their second or third lifes since the OEM ceased supporting 'em.
Guess I'll have to switch over to using telnet next year.
Posted Jan 11, 2024 23:18 UTC (Thu)
by gus3 (guest, #61103)
[Link] (11 responses)
Posted Jan 11, 2024 23:40 UTC (Thu)
by pizza (subscriber, #46)
[Link] (10 responses)
Pray tell, how exactly are we to use DSA-lacking OpenSSH to communicate with DSA-only gear?
It's easy to say "you shouldn't be using X any more" when you aren't having to pay for X's replacement.
Posted Jan 12, 2024 0:31 UTC (Fri)
by hmanning77 (subscriber, #160992)
[Link] (3 responses)
Posted Jan 12, 2024 5:59 UTC (Fri)
by lkundrak (subscriber, #43452)
[Link]
I guess there might be other SSH clients out there which might be used for the same purpose. PuTTY maybe?
Posted Jan 13, 2024 16:31 UTC (Sat)
by mgb (guest, #3226)
[Link] (1 responses)
Posted Jan 14, 2024 8:51 UTC (Sun)
by cjwatson (subscriber, #7322)
[Link]
Posted Jan 12, 2024 2:49 UTC (Fri)
by geofft (subscriber, #59789)
[Link] (2 responses)
There is a very well-written section in the announcement to which you are replying that answers your exact question. For your convenience, here is a copy of that section:
Posted Jan 12, 2024 9:33 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (1 responses)
Posted Jan 12, 2024 9:43 UTC (Fri)
by tomsi (subscriber, #2306)
[Link]
And only use the DSA client to connect to DSA equipment.
Posted Jan 15, 2024 5:20 UTC (Mon)
by ssmith32 (subscriber, #72404)
[Link]
Then pay someone to maintain SSH with DSA. OR return the favor of the community-maintained SSH, and maintain an open-source one. Not mutually exclusive.
Posted Jan 15, 2024 12:32 UTC (Mon)
by taladar (subscriber, #68407)
[Link] (1 responses)
It's easy to say "you should support X forever" when you don't have to pay for the cost of ongoing support.
Posted Jan 15, 2024 14:25 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Ahem.
Telling folks what they "should" be doing is not "paying the cost of ongoing support"
...and I say that as someone that actively maintains software and drivers for equipment that was EOL'd well over a decade ago.
Posted Jan 12, 2024 9:35 UTC (Fri)
by grawity (subscriber, #80596)
[Link] (15 responses)
Public Service Announcement: Other SSH Clients Than OpenSSH Also Exist
That being said, I've already gone the easy way of "just using Telnet" for some devices... We bought a bunch of "brand new" TP-Link T2600G's in 2018 and they still had SSHv2 disabled by default. You had to manually turn off SSHv1 and enable SSHv2 through the web UI (which, too, was only accessible via cleartext or SSLv3 by default). We didn't bother; went with Telnet + Expect (and some WireGuard). Fortunately it seems their new models do better.
Posted Jan 12, 2024 14:22 UTC (Fri)
by pizza (subscriber, #46)
[Link] (14 responses)
Exactly this problem. Just like the "every browser now refuses TLS < 1.3" effectively means "gotta downgrade to plain http".
The two-decade-long 1GbE networking plateau has meant a _very_ long usable lifecycle for network gear. Stuff capble of higher speeds has only now begun to become affordable, but even two-generations-old corporate castoff PoE+ switches with 10GbE SFP ports remain quite pricey.
Ironically, the newest bit of kit I have is $ISP-supplied modem/router, containing intentional $ISP management backdoors, along with software with confirmed vulnerabilities. Use of said gear is the only way $ISP will provide more than a single static IP address. Oh, did I mention $ISP has been compromised several times since I've been a customer, and is currently undergoing Chapter 11 bankrupcy reorganization? (Ain't a lack of competition grand?)
Meanwhile, while DSA's weaknesses may have reduced the theoretical cost of attack from $$$$$ to $$, even $$ is a lot better than $0. Especially when _my_ threat vector consists of opportunistic script-kiddies or phishers [1] or collateral damage from $ISP being compromised.
[1] Which, like everything else these days, has gone corporate. But they're still just performing blind, drive-by opportunistic attacks, and any attack that costs more than $0 is too expensive to bother with)
Posted Jan 12, 2024 16:00 UTC (Fri)
by draco (subscriber, #1792)
[Link] (1 responses)
And then the bigwigs will solemnly proclaim that security is their top priority despite blatant evidence to the contrary (cf. Boeing re safety).
At least if people get forced to HTTP, they can't pretend they thought it was still secure.
Browsers used to grade connection security quality, but I assume they found that it wasn't an effective lever to get people to improve
Posted Jan 14, 2024 6:52 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link]
Note that another method to continue to reach outdated machines is to use a less outdated bouncing machine. I've done this quite a bit, leave an old always-up arm or atom board somewhere with an outdated (hence vulnerable) distro that you don't care about too much, and connect to that one over a modern SSH with ed25519 to bounce to the other one. I had to use that to connect to certain labs whose gateways only supported algorithms my implementation couldn't support in the past :-/
Posted Jan 13, 2024 11:57 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (11 responses)
Posted Jan 13, 2024 14:33 UTC (Sat)
by pizza (subscriber, #46)
[Link] (10 responses)
*shrug* So I was off by one iteration. Big whoop.
(And just because something was defined on a certain date doesn't imply any sort of schedule for implementations to be widely available! Case in point: IPv6...)
Meanwhile. Not everything is a general-purpose system with freely upgradeable (client &| server) software, there is a very real, non-trivial cost associated with replacing said equipment, and most of us don't have unlimited budgets.
(My "new" 10GbE PoE switch was discontinued by its manufacturer in _2015_. Current-model replacements run at least $1000 for tier-2 gear [2]. It's also not internet-facing; in order for the switch to be a security risk my network would need to have already been completely compromised!)
[1] released in 2011
Posted Jan 13, 2024 15:28 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
Apparently this particular unit is running OpenSSH 5.8, and current OpenSSH 9.x (at least as shipped by Fedora 38+) refuses to negotiate a session key [1] I haven't needed to get into this thing for the better part of a year, when I expanded one of the VLANs. I'm glad I found out about this problem now, when I have physical access to connect to the switch's serial console and no emergency going on.
[1] Can't negotiate a mutually perceptible host key algorithm. I _might_ be able to resolve this with a config change on the switch. But that requires being able to log in first.
Posted Jan 14, 2024 8:57 UTC (Sun)
by cjwatson (subscriber, #7322)
[Link]
Posted Jan 14, 2024 17:52 UTC (Sun)
by vadim (subscriber, #35271)
[Link] (2 responses)
Try something from Mikrotik perhaps? They have plenty 10G stuff, and some stuff that goes higher, and it's very affordable.
The UI is definitely for technically minded people, but the software gets very regular updates and is the same for all their modern stuff.
Posted Jan 14, 2024 19:40 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
I actually have two mostly-SFP 10GbE Microtik switches in use, and I'm quite pleased with them.
Unfortunately, PoE is a big cost driver; a Microtik 48-port PoE with 10G SFP ports will still run about $900 shipped.
(...Why SFP? Because fiber lets me not worry about lightning strikes. Or care about cable run length/bandwidth limitations..)
Posted Jan 14, 2024 20:42 UTC (Sun)
by vadim (subscriber, #35271)
[Link]
If this is for an enterprise environment, then $900 isn't that much money. If it's for home use, you probably don't have 48 devices that need PoE there. Since it's a switch you can just have two of them.
Posted Jan 14, 2024 20:52 UTC (Sun)
by zdzichu (subscriber, #17118)
[Link] (4 responses)
Ah yes. I've bought a TP-Link TL-SG2216 switch with 5 year warranty for home. Managed – over HTTPS and SSH.
During the last year of the warranty, I've noticed it only supported TLS1.0 with laughable ciphers: I've noticed because web browsers disabled TLS < 1.2 some time ago (and this is good). I've opened a support issue with TP-Link, after all the feature (which was a selling point to me) stopped working. After a longish email thread explaining that I would like the feature to work again(*) my issue got closed, because: 1) my 5 year warranty just ended; 2) I should have opened a ticket with the reseller, not TP-Link themselves. :( * - getting the HTTPS fixed would require TP-Link to implement TLS 1.2 in their firmware. Which may be impossible, but was not business-sensible for sure. They discontinued the switch in the meantime, despite having units covered by 5 year warranty in the field. Oh, and the second management option, SSH? Since the beginning I had to use this invocation: Network hardware vendors are the worst.
Posted Jan 15, 2024 10:19 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
Okay, this is UK rules, but under them, point 2 is valid. HOWEVER. You now just raise the issue with the reseller - the fact that your five-year warranty has expired is irrelevant. The warranty covers faults THAT EXISTED in the warranty period. If you claim outside the period, then you have the burden of proving they were pre-existing faults, but "the warranty has expired" on its own is not sufficient to turn down a warranty claim. You've got a dead-easy proof - you raised the issue with TP-Link during the warranty period ...
Cheers,
Posted Jan 15, 2024 11:47 UTC (Mon)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Posted Jan 15, 2024 16:46 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
For Directives, the national implementation must implement the directive *as a minimum*. UK rules are noticeably different from the directive, but because they are much stricter that's not a problem. However, I would have thought this would be covered by the directive.
Cheers,
Posted Jan 18, 2024 23:14 UTC (Thu)
by rknight (subscriber, #26792)
[Link]
Not sure what family the TL-SG2216 is in, but at least a couple of TP-Link switches have some support from OpenWrt now and therefore have support for modern HTTPS and SSH. See https://openwrt.org/docs/techref/targets/realtek for a current list of supported switches. Note that some enterprise features of the switch are not yet supported, but basic switching and PoE support are there.
Posted Jan 22, 2024 13:45 UTC (Mon)
by gus3 (guest, #61103)
[Link]
Pity they didn't tell you how to work out if you connect to any DSA servers.
OpenSSH announces DSA-removal timeline
grep ' ssh-dsa ' ~/.ssh/known_hosts| cut -d' ' -f1
returns nothing then you're fine (or at least, you've never connected to servers using DSA keys from your account, or you've deleted or truncated .ssh/known_hosts, or...).
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
You are not expected to use DSA-lacking OpenSSH. There are more options in the world than just telnet and the version of OpenSSH that will be released next year. In fact, you're using one of those options right now!
OpenSSH announces DSA-removal timeline
* What if I have devices that only support DSA?
Removing DSA from OpenSSH will not remove endpoints that require DSA
from the world and users may still need to connect to them. Although
new releases of OpenSSH will no longer support DSA, past releases and
alternate SSH implementations will continue to do so.
We recommend that users with an ongoing need to connect to DSA-only
endpoints maintain a legacy release of an OpenSSH client for this
purpose, similar to what was recommended when support for the SSHv1
protocol was removed.
For example, Debian maintains a "openssh-client-ssh1" package built
from OpenSSH 7.5 for the purpose of connecting to SSHv1 endpoints.
This package or something similar is likely to be sufficient for
DSA-only endpoints too.
(In particular, if you're considering telnet as a possible option, then clearly you don't care that much about security, and so running an outdated OpenSSH version shouldn't be a concern.)
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
[2] eg Linksys or Netgear as opposed to, say, top shelf Dell/HPE/Cisco or the syllable soup brands found on Aliexpress)
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
Preferred TLSv1.0 128 bits RC4-SHA
Accepted TLSv1.0 128 bits RC4-MD5
Accepted TLSv1.0 112 bits DES-CBC3-SHA
Accepted TLSv1.0 56 bits TLS_RSA_WITH_DES_CBC_SHA
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oCiphers=aes256-cbc -oHostKeyAlgorithms=+ssh-dss …
OpenSSH announces DSA-removal timeline
Wol
OpenSSH announces DSA-removal timeline
OpenSSH announces DSA-removal timeline
Wol
OpenSSH announces DSA-removal timeline
having discussions is the point of LWN.net