OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 14:22 UTC (Fri) by pizza (subscriber, #46)
In reply to: OpenSSH announces DSA-removal timeline by grawity
Parent article: OpenSSH announces DSA-removal timeline

> 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).

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)

OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 16:00 UTC (Fri) by draco (subscriber, #1792) [Link] (3 responses)

If they provide legacy support for obsolete crypto forever, nothing will ever change until it's a five alarm fire and lots of people are getting hurt.

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

OpenSSH announces DSA-removal timeline

Posted Jan 14, 2024 6:52 UTC (Sun) by wtarreau (subscriber, #51152) [Link] (2 responses)

The method that works best to deprecate outdated security mechanisms is adding delays. It continues to work but pisses the users off every time, and gives a strong incentive for updating everything that can be updated. Nobody wants to endure a 5s pause at every connection to a device that can be fixed. When you know the device is unfixable, that's quite annoying but better than not being able to connect.

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 :-/

OpenSSH announces DSA-removal timeline

Posted Jan 13, 2025 11:58 UTC (Mon) by akostadinov (guest, #48510) [Link]

Nowadays better use a container image and run ssh from it. You can mount safe local filesystem paths if you need to transfer files.

You can use VPNs to connect to old vulnerable devices. If ISP is providing an insecure router, just use it to forward your traffic through your own secure router.

Sounds like OpenSSH and other crypto-professional teams need to provide more details with such announcements but maybe they don't realize how clueless generally people are about security. I don't exclude myself from this in different areas. Such lingering vulnerable devices are perfect for running somebody's bot farm. And perhaps that's why they became so cheap.

OpenSSH announces DSA-removal timeline

Posted Jan 13, 2025 15:11 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Yeah, I've set up a bastion host with an ancient Firefox to support old SSL ciphers to manage old equipment (APC NMC1 cards) until it ages out. We are just getting around to retiring pre-SSH serial terminal servers from our OOB. When equipment is capable of doing the job it was purchased for, and segmented off with network security controls, it's hard to justify spending capital budget to replace a working thing when there are always higher priority devices which need capacity expansion or are exposed to customer or malicious traffic and should maintain vendor support.

Just migrated to RHEL9 and had to deal with update-crypto-policies and ssh_config to be able to connect to our remaining IOS 12 (and 15?) devices, hopefully they are gone before moving to RHEL11, or we'll need to need to run an old bastion VM on our bastion management hosts. ssh natively supports the idea of a jump host these days so it's possible to integrate with automation just by throwing a few more options (-J iirc).

OpenSSH announces DSA-removal timeline

Posted Jan 13, 2024 11:57 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (11 responses)

The browsers expect TLS 1.2, defined in RFC5246 in 2008 not TLS 1.3. Earlier versions make assumptions we've known are definitely not true for years now and also require browsers to carry around the awful (known security hole) "fallback" strategy because server implementers apparently cannot read or don't want to.

OpenSSH announces DSA-removal timeline

Posted Jan 13, 2024 14:33 UTC (Sat) by pizza (subscriber, #46) [Link] (10 responses)

> The browsers expect TLS 1.2, defined in RFC5246 in 2008

*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
[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

Posted Jan 13, 2024 15:28 UTC (Sat) by pizza (subscriber, #46) [Link] (1 responses)

> My "new" 10GbE PoE switch was discontinued by its manufacturer in _2015_.

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.

OpenSSH announces DSA-removal timeline

Posted Jan 14, 2024 8:57 UTC (Sun) by cjwatson (subscriber, #7322) [Link]

That sounds like the sort of thing you can probably deal with using client options. Have you tried the various things on https://www.openssh.com/legacy.html ?

OpenSSH announces DSA-removal timeline

Posted Jan 14, 2024 17:52 UTC (Sun) by vadim (subscriber, #35271) [Link] (2 responses)

> Current-model replacements run at least $1000 for tier-2 gear [2]

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.

OpenSSH announces DSA-removal timeline

Posted Jan 14, 2024 19:40 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> Try something from Mikrotik perhaps? They have plenty 10G stuff,

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..)

OpenSSH announces DSA-removal timeline

Posted Jan 14, 2024 20:42 UTC (Sun) by vadim (subscriber, #35271) [Link]

Do you actually need 48 ports of PoE though?

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.

OpenSSH announces DSA-removal timeline

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:

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

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:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oCiphers=aes256-cbc -oHostKeyAlgorithms=+ssh-dss …

Network hardware vendors are the worst.

OpenSSH announces DSA-removal timeline

Posted Jan 15, 2024 10:19 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

> 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. :(

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,
Wol

OpenSSH announces DSA-removal timeline

Posted Jan 15, 2024 11:47 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

That's interesting, I may try that. Thanks!

OpenSSH announces DSA-removal timeline

Posted Jan 15, 2024 16:46 UTC (Mon) by Wol (subscriber, #4433) [Link]

Not knowing where you're based, so if you're elsewhere in Europe don't assume the rules are the same.

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,
Wol

OpenSSH announces DSA-removal timeline

Posted Jan 18, 2024 23:14 UTC (Thu) by rknight (subscriber, #26792) [Link]

> 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:

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.