12 ms·

Timeline to remove DSA support in OpenSSH

257 points by throw0101d 3y ago

throw0101d 3y ago
About a one-year time frame for complete de-orbit: 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
- codetrotter 3y ago
  And then another 10 years until the last Linux distro LTS version has removed support for it :)
- ynik 3y ago
  Missing from your timeline: 2006-05-01 NIST SP 800-57 Part 1 Rev. 1 is published, which recommends to stop using 1024-bit DSA by 2010. 2010 passes, but OpenSSH never added support for DSA with keylengths larger than 1024-bit. 2015-08-11 OpenSSH 7 disables DSA at runtime. The new announcement is just removing the config option to re-enable the algorithm. Hopefully most people stuck on DSA already starting migrating in 2015 (ideally: finished migration before 2010).
rwmj 3y ago
Don't remove it, add a "--yes-I-really-want-to-use-DSA" option. We sometimes have to connect to older systems that use insecure keys, and no those systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc)
- throw0101d 3y ago
  * 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.
  - Sesse__ 3y ago
    So basically, the recommended solution is “instead of us maintaining DSA support, everybody should maintain their own fork of an old OpenSSH version”?
    - extinctpotato 3y ago
      Yes.
    - caboteria 3y ago
      https://xkcd.com/1172/ https://xkcd.com/1172/
    - morelisp 3y ago
      Not "everybody", just "not us".
    - mynameisvlad 3y ago
      DSA support isn’t free. It requires maintenance. We aren’t entitled to lifetime support.
      - pkaye 3y ago
        Is there active work being done on the DSA code recently?
        timv 3y ago
        The main source code for DSA is here https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-dss.c https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ss... You can see that the team did a big refactor of key handling about 14 months ago that required multiple rounds changes to the DSA code. That's the sort of cost that legacy code brings - it's not about make changing to the DSA feature, it's about the cost of maintaining the DSA code when you make changes across the codebase. In the original mail, DJM mentions that they'd like to explore a post-quantum signature algorithm. Adding that to the codebase is likely to require some broad changes to key management, and that will be less work if there are fewer supported key types.
- mschuster91 3y ago
  > We sometimes have to connect to older systems that use insecure keys, and no those systems cannot be fixed At least there's now a way to tell management "hey, there is no choice, <thing> must be replaced because we literally won't be able to connect to it any more".
  - patrakov 3y ago
    Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. At least it would be then plain obvious that there is no security, instead of the current security theater with DSA.
    - throw0101d 3y ago
      > Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. Possible reply for some folks: our cyber-insurance mandates encryption for all logins.
      - midasuni 3y ago
        Telnet uses double rot 13 encryption.
    - robertlagrant 3y ago
      Or just use an existing version of OpenSSL. They aren't sending a terminator back in time to purge DSA support from all of time.
      - oynqr 3y ago
        That would be a better timeline than this one.
    - acdha 3y ago
      The grind of audit requirements tends to mean those managers are a lot more willing to do the right thing now – it’s less risk than putting your name in writing on the thing which the auditors / insurance company will be using to fail you.
- csdreamer7 3y ago
  They said it has been disabled by default for years. There is a cost to maintaining it and a security risk for untested code. I agree with this removal. > those systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc) How old are these old systems? V2V conversions? What version of RHEL?
  - Arnt 3y ago
    I tried to look for active DSA keys now, and didn't see anything but don't feel confident that there are in fact none. Hmm.
    - SoftTalker 3y ago
      Yeah old switches, BMCs, and other embedded SSH servers often use it. Really that stuff is too old to be using in a production environment but sometimes reality is different. Keep an older release of openssh if you need it for those. No sense keeping obsolete code for obsolete use cases in the codebase, it's a maintenance an testing headache and a security risk.
      - Arnt 3y ago
        I don't want to be nervous about whether I need it, I'd prefer an alert when it's used, turned on by default for a year.
        roblabla 3y ago
        It's been disabled by default since 2015 - you need to enable support for them in the config file, otherwise the client will error out. In other words, if you don't have the following line in your ~/.ssh/config, you're fine: PubkeyAcceptedKeyTypes=+ssh-dss
        Arnt 3y ago
        That's great. Do you know what happens when an old unattended client with an old old key connects to a new server?
- Hizonner 3y ago
  I don't think I've ever seen an actual DSA key in use in SSH, and I was using it before there was an RFC. Even the oldest actual deployments tended to ignore the patent and use RSA. > systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc) If you can't update a system, you have no business exposing it to a network. Full stop.
  - o11c 3y ago
    When I got into Linux around 2010 there was something that encouraged me to make a DSA key instead of an RSA one ...
    - Macha 3y ago
      Arch Wiki was still recommending dsa around that time: https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66753 https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66...
      - dharmab 3y ago
        There was a lot of suspect advice on the TLS and SSH pages. I did a pass a couple of years ago, updating the recommendation to EC keys if possible and RSA otherwise, with links to relevant academic sources.
    - Piskvorrr 3y ago
      Encouraged, sure. Last time I saw something that actually required DSA, it was literally decades old, and that encounter didn't happen in this decade either. I do have some tools for ancient machines, such as with SSHv1 support, but it's more akin to archeology than access to working machines.
  - arisudesu 3y ago
    Don't confuse the Internet and networks please. Older machines are completely fine to be used in private firewall-protected networks, as long as they're facing only LAN. SSH still be required to access them.
- _jal 3y ago
  Worse that old network gear is technically incompetent business partners. Speaking in very general terms, let's just say that we've had to maintain an extremely locked down machine running a version of sshd from about a decade ago hosted in its own DMZ, all for one particular partner. It is monitored for everything we can think of, and I still find myself stressing about possible ways someone could escape from that machine - I'm mostly surprised we haven't been attacked through them yet. Their problem is they bought proprietary software that's no longer supported, and look at it as a one-time purchase rather than a forward commitment. Our problem is the nontechnical relationship is important and we can't cut them off.
  - freedomben 3y ago
    Indeed. I can't imagine what it's going to be like 10 years from now when the mountain of SaaS offerings start disappearing and there'se zero options to "run it a little longer"
- laserbeam 3y ago
  Write a guide for how to obtain and install an old version of openssh for that usecase. Make it available within your org. Problem solved.
- Lord_Zero 3y ago
  Use an older version of OpenSSH then.
- harshreality 3y ago
  Couldn't you grab an old distro image (or livecd), install/run it in a VM, and use that? Archive.org even has an iso of redhat 6.2. :)
- shawnz 3y ago
  It's already disabled by default, which is basically what you are asking for. However, disabling it by default doesn't solve the problem of the maintenance burden. That's what this change is meant to solve: > [...] we no longer consider the costs of maintaining DSA in OpenSSH to be justified.
  - V-eHGsd_ 3y ago
    exactly. and if the added burden of having to maintain (or more likely, just download) a version of ssh that supports dsa means that some piece of legacy hardware is no longer cost effective, then it's probably time to upgrade that legacy hardware. and you (the general you) should probably be thanking the openssh folks for all the work they've done for the last 8+ years keeping the dsa code around which allowed you (the general you) to externalize that cost.
- dehrmann 3y ago
  Do they support telnet?
- pbhjpbhj 3y ago
  But then Linus from LTT will end up using DSA by accident! /s
127361 3y ago
Telnet will still work. So if you're developing an embedded device that will keep functioning after 20 years, it's best to not use any crypto at all. I'm half joking here.
- bauruine 3y ago
  If you have an embedded device that has to work for 20 years without update you better design it's networking part so that telnet isn't an issue in your threat model.
  - deleted 3y ago
    [deleted]
  - 127361 3y ago
    It would have to be on a small isolated LAN, e.g. within a machine or section of a plant. Many buses used in industrial control equipment such as CAN bus and Modbus do not use encryption. I suppose there's more risk if you're using TCP/IP and connect laptops that have been online to the LAN, because it's such a common protocol. But again sophisticated malware could just wait until you have your USB CAN dongle connected to the laptop, and still attack the CAN bus. Heck, CAN bus and Modbus don't even have any password protection at all.
    - antoinealb 3y ago
      CAN Bus is more like a layer 2 bus, so it should not really bother with encryption, just like Ethernet doesn't provide it. It all comes from the layers above it, and there has been proposal to add encryption or authentication to CAN. The big issue is that in normal CAN you only have 8 bytes to work with.
      - deleted 3y ago
        [deleted]
      - mkipper 3y ago
        This is kind of a nitpick, but Ethernet _does_ bother with encryption, at least in recent versions of its standards. Obviously Ethernet has a long history and this is all optional, but it's pretty straightforward to set up 802.1X / MACsec (+MKA) on a LAN in such a way that all traffic is encrypted at L2. I've never heard of this being used with really low-power embedded stuff, but if you stretch your definition of embedded to the point where you include things running stripped down Linux, this is a pretty viable setup if you have those devices distributed across a LAN with a managed switch in the middle.
dochtman 3y ago
Does Azure support ed25519 keys yet?
- Svenstaro 3y ago
  No. :(
- er0k 3y ago
  I thought this was a joke, but they really don't: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/ed25519-ssh-keys https://learn.microsoft.com/en-us/troubleshoot/azure/virtual... what the fuck? What is Microsoft doing? ed25519 was added to openssh, what, 7 years ago? This boggles my mind.
  - Macha 3y ago
    Just about exactly 10 years ago, actually: https://lwn.net/Articles/590870/ https://lwn.net/Articles/590870/
  - pbhjpbhj 3y ago
    Maybe they're supporting TLAs abilities to crack Microsoft users when 'necessary'?
  - adastra22 3y ago
    It actually violates some federal contracting rules to support non-NIST keys. Maybe they don’t bother for that reason?
    - dharmab 3y ago
      Azure's gov cloud is a separate API.
      - adastra22 3y ago
        With a lot of shared software. Need a strong reason to introduce differences which if accidentally misconfigured could have large contract liabilities.
lxgr 3y ago
> DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key This should be 160 bit equivalent, right? An actual 160 bit (non-EC) DSA key would be trivially brute-forceable.
- crote 3y ago
  No, it's genuinely 160 bit keys. The SSHv2 protocol mandates FIPS-186-2, which only allows 160 bit keys. 224-bit and 256-bit keys were only introduced in the later FIPS-186-3.
  - lxgr 3y ago
    Ah, I mistook "private" for "public" key. The private key is indeed 160 bit for DSA per FIPS-186-3; it's the public key that's 1024 bit. That's commonly used as the "security parameter" for DSA, though; 160 is very easy to confuse with e.g. a symmetric encryption key or hash length.
cust 3y ago
[dead]
mynameisnoone 3y ago
[flagged]
shrubble 3y ago
Some of the HP iLO and other servers as well as some networking gear uses this. Not sure those devices can be upgraded.
- Piskvorrr 3y ago
  You'd need to keep an older client to keep around for old devices. Sort of like that VM with WinXP and IE6, the one that's only kept because it has a semi-working ActiveX that some ancient device only interfaces with... shudder
  - duozerk 3y ago
    This is already the case for very old target devices, that don't support the ssh v2 protocol at all; hence the existence of the ssh1 client (https://packages.debian.org/bookworm/openssh-client-ssh1 https://packages.debian.org/bookworm/openssh-client-ssh1).
  - szundi 3y ago
    Older clients may be a target for attack then.
    - pavon 3y ago
      Yes, but I'd be much more concerned about the SSH server.
      - px43 3y ago
        I dunno, exploiting a vulnerability that lets you steal SSH keys from a sysadmin seems a bit more useful than hitting a single server.
        NegativeK 3y ago
        As usual, it seems like it's a good idea for the open source project (ssh in this case) to drop old tech and move on while those dependent on it should maintain it, for whatever that means.
anonymousiam 3y ago
I don't understand the rationale for removing support for any algorithm. I can understand disabling support, but why remove it? I have often needed to connect to ancient systems that only support very old algorithms. From a modern ssh client, I will usually need to specify the needed algorithm on the ssh command line in order to connect. E.g. ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@x.x.x.x
- halJordan 3y ago
  Two of the big reasons are to keep code clean and security. Reference the latest linux kernels, and how they achieved most of their performance increases (hint they removed old code and simplified the codepaths). The second reason is to prevent it's use. It is not just good enough to consider the "happy path." There are unhappy paths where an adversary is able to make use of these abilities. When the aggregate unhappy paths overwhelm the single happy path, it's time to bite the bullet.
  - mistrial9 3y ago
    ... plus hardware vendors, some very large companies and security consultants financially benefit from churn
    - woodruffw 3y ago
      Consultants might benefit, I don't think that hardware vendors (especially network appliance vendors) really do: these kinds of changes are purely an expense for them, since they have to reallocate engineers to fix things that were otherwise on "autopilot" for their support contracts.
- imrejonk 3y ago
  They provide a good reason for completely removing the DSA code: > 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. Vulnerabilities like heartbleed and Log4Shell is what you get when you have limited developer capacity but insist on endlessly keeping legacy code around.
faeriechangling 3y ago
There's lots of ways to ensure security aside from at the protocol level, and DSA helps with compatibility, so this just seems like a bad idea to me. I don't think anybody was really accidentally using DSA not understanding the implications.
- kelnos 3y ago
  If you need this support, perhaps you should pay someone on the OpenSSH team (or an independent 3rd party) to support it. It's not free to keep code around, unfortunately; every bit adds a maintenance burden. It's an open source project, and no one is entitled to anything in particular.
charlieyu1 3y ago
What is DSA? I checked wiki and it looks like RSA for signatures, using modular exponentials. RSA is going to stay for a while, so why is DSA removed?
- skissane 3y ago
  DSA was an alternative to RSA developed by the NSA, which used (other parts of) the US government to push for its implementation. It was never entirely clear why they were doing that, and there have always been (unproven) suspicions that the NSA wanted it adopted over RSA for underhanded reasons. Due to this history, it was never anywhere near as popular as RSA. Anyway, the US government (NIST) now recommends use of DSA be discontinued. By contrast, RSA was developed in academia and its adoption was independent of the US government’s influence (and at times even against its preference for DSA instead)
  - jepler 3y ago
    My impression is that RSA was covered by patent (from 1983 until 2001). DSA was attractive in part because, while patented, the primary patent was held by the US government and royalty-free. I have vague memories (from circa 1995 comp sci undergrad coursework) that discrete log and integer factorization both appeared similarly difficult as mathematical/algorithmic problems. Thus, if you had to choose between a patent-encumbered protocol and a royalty-free one, it would make sense to choose DSA. That said, it seems to have never offered a particular advantage, and the modern view appears to be that DSA is weaker in practical terms.
- abraxis 3y ago
  RSA and DSA rely on different number theory problems. RSA relies on prime factorization being hard while DSA relies on the discrete logarithm being hard.
77pt77 3y ago
Does this include ECDSA?
- loeg 3y ago
  No.

257 points by throw0101d 3y ago

About a one-year time frame for complete de-orbit: 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

codetrotter 3y ago
And then another 10 years until the last Linux distro LTS version has removed support for it :)
ynik 3y ago
Missing from your timeline: 2006-05-01 NIST SP 800-57 Part 1 Rev. 1 is published, which recommends to stop using 1024-bit DSA by 2010. 2010 passes, but OpenSSH never added support for DSA with keylengths larger than 1024-bit. 2015-08-11 OpenSSH 7 disables DSA at runtime. The new announcement is just removing the config option to re-enable the algorithm. Hopefully most people stuck on DSA already starting migrating in 2015 (ideally: finished migration before 2010).

rwmj 3y ago

Don't remove it, add a "--yes-I-really-want-to-use-DSA" option. We sometimes have to connect to older systems that use insecure keys, and no those systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc)

throw0101d 3y ago
* 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.
- Sesse__ 3y ago
  So basically, the recommended solution is “instead of us maintaining DSA support, everybody should maintain their own fork of an old OpenSSH version”?
  - extinctpotato 3y ago
    Yes.
  - caboteria 3y ago
    https://xkcd.com/1172/ https://xkcd.com/1172/
  - morelisp 3y ago
    Not "everybody", just "not us".
  - mynameisvlad 3y ago
    DSA support isn’t free. It requires maintenance. We aren’t entitled to lifetime support.
    - pkaye 3y ago
      Is there active work being done on the DSA code recently?
      - timv 3y ago
        The main source code for DSA is here https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-dss.c https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ss... You can see that the team did a big refactor of key handling about 14 months ago that required multiple rounds changes to the DSA code. That's the sort of cost that legacy code brings - it's not about make changing to the DSA feature, it's about the cost of maintaining the DSA code when you make changes across the codebase. In the original mail, DJM mentions that they'd like to explore a post-quantum signature algorithm. Adding that to the codebase is likely to require some broad changes to key management, and that will be less work if there are fewer supported key types.
mschuster91 3y ago
> We sometimes have to connect to older systems that use insecure keys, and no those systems cannot be fixed At least there's now a way to tell management "hey, there is no choice, <thing> must be replaced because we literally won't be able to connect to it any more".
- patrakov 3y ago
  Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. At least it would be then plain obvious that there is no security, instead of the current security theater with DSA.
  - throw0101d 3y ago
    > Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. Possible reply for some folks: our cyber-insurance mandates encryption for all logins.
    - midasuni 3y ago
      Telnet uses double rot 13 encryption.
  - robertlagrant 3y ago
    Or just use an existing version of OpenSSL. They aren't sending a terminator back in time to purge DSA support from all of time.
    - oynqr 3y ago
      That would be a better timeline than this one.
  - acdha 3y ago
    The grind of audit requirements tends to mean those managers are a lot more willing to do the right thing now – it’s less risk than putting your name in writing on the thing which the auditors / insurance company will be using to fail you.
csdreamer7 3y ago
They said it has been disabled by default for years. There is a cost to maintaining it and a security risk for untested code. I agree with this removal. > those systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc) How old are these old systems? V2V conversions? What version of RHEL?
- Arnt 3y ago
  I tried to look for active DSA keys now, and didn't see anything but don't feel confident that there are in fact none. Hmm.
  - SoftTalker 3y ago
    Yeah old switches, BMCs, and other embedded SSH servers often use it. Really that stuff is too old to be using in a production environment but sometimes reality is different. Keep an older release of openssh if you need it for those. No sense keeping obsolete code for obsolete use cases in the codebase, it's a maintenance an testing headache and a security risk.
    - Arnt 3y ago
      I don't want to be nervous about whether I need it, I'd prefer an alert when it's used, turned on by default for a year.
      - roblabla 3y ago
        It's been disabled by default since 2015 - you need to enable support for them in the config file, otherwise the client will error out. In other words, if you don't have the following line in your ~/.ssh/config, you're fine: PubkeyAcceptedKeyTypes=+ssh-dss
        Arnt 3y ago
        That's great. Do you know what happens when an old unattended client with an old old key connects to a new server?
Hizonner 3y ago
I don't think I've ever seen an actual DSA key in use in SSH, and I was using it before there was an RFC. Even the oldest actual deployments tended to ignore the patent and use RSA. > systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc) If you can't update a system, you have no business exposing it to a network. Full stop.
- o11c 3y ago
  When I got into Linux around 2010 there was something that encouraged me to make a DSA key instead of an RSA one ...
  - Macha 3y ago
    Arch Wiki was still recommending dsa around that time: https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66753 https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66...
    - dharmab 3y ago
      There was a lot of suspect advice on the TLS and SSH pages. I did a pass a couple of years ago, updating the recommendation to EC keys if possible and RSA otherwise, with links to relevant academic sources.
  - Piskvorrr 3y ago
    Encouraged, sure. Last time I saw something that actually required DSA, it was literally decades old, and that encounter didn't happen in this decade either. I do have some tools for ancient machines, such as with SSHv1 support, but it's more akin to archeology than access to working machines.
- arisudesu 3y ago
  Don't confuse the Internet and networks please. Older machines are completely fine to be used in private firewall-protected networks, as long as they're facing only LAN. SSH still be required to access them.
_jal 3y ago
Worse that old network gear is technically incompetent business partners. Speaking in very general terms, let's just say that we've had to maintain an extremely locked down machine running a version of sshd from about a decade ago hosted in its own DMZ, all for one particular partner. It is monitored for everything we can think of, and I still find myself stressing about possible ways someone could escape from that machine - I'm mostly surprised we haven't been attacked through them yet. Their problem is they bought proprietary software that's no longer supported, and look at it as a one-time purchase rather than a forward commitment. Our problem is the nontechnical relationship is important and we can't cut them off.
- freedomben 3y ago
  Indeed. I can't imagine what it's going to be like 10 years from now when the mountain of SaaS offerings start disappearing and there'se zero options to "run it a little longer"
laserbeam 3y ago
Write a guide for how to obtain and install an old version of openssh for that usecase. Make it available within your org. Problem solved.
Lord_Zero 3y ago
Use an older version of OpenSSH then.
harshreality 3y ago
Couldn't you grab an old distro image (or livecd), install/run it in a VM, and use that? Archive.org even has an iso of redhat 6.2. :)
shawnz 3y ago
It's already disabled by default, which is basically what you are asking for. However, disabling it by default doesn't solve the problem of the maintenance burden. That's what this change is meant to solve: > [...] we no longer consider the costs of maintaining DSA in OpenSSH to be justified.
- V-eHGsd_ 3y ago
  exactly. and if the added burden of having to maintain (or more likely, just download) a version of ssh that supports dsa means that some piece of legacy hardware is no longer cost effective, then it's probably time to upgrade that legacy hardware. and you (the general you) should probably be thanking the openssh folks for all the work they've done for the last 8+ years keeping the dsa code around which allowed you (the general you) to externalize that cost.
dehrmann 3y ago
Do they support telnet?
pbhjpbhj 3y ago
But then Linus from LTT will end up using DSA by accident! /s

127361 3y ago

Telnet will still work. So if you're developing an embedded device that will keep functioning after 20 years, it's best to not use any crypto at all. I'm half joking here.

bauruine 3y ago
If you have an embedded device that has to work for 20 years without update you better design it's networking part so that telnet isn't an issue in your threat model.
- deleted 3y ago
  [deleted]
- 127361 3y ago
  It would have to be on a small isolated LAN, e.g. within a machine or section of a plant. Many buses used in industrial control equipment such as CAN bus and Modbus do not use encryption. I suppose there's more risk if you're using TCP/IP and connect laptops that have been online to the LAN, because it's such a common protocol. But again sophisticated malware could just wait until you have your USB CAN dongle connected to the laptop, and still attack the CAN bus. Heck, CAN bus and Modbus don't even have any password protection at all.
  - antoinealb 3y ago
    CAN Bus is more like a layer 2 bus, so it should not really bother with encryption, just like Ethernet doesn't provide it. It all comes from the layers above it, and there has been proposal to add encryption or authentication to CAN. The big issue is that in normal CAN you only have 8 bytes to work with.
    - deleted 3y ago
      [deleted]
    - mkipper 3y ago
      This is kind of a nitpick, but Ethernet _does_ bother with encryption, at least in recent versions of its standards. Obviously Ethernet has a long history and this is all optional, but it's pretty straightforward to set up 802.1X / MACsec (+MKA) on a LAN in such a way that all traffic is encrypted at L2. I've never heard of this being used with really low-power embedded stuff, but if you stretch your definition of embedded to the point where you include things running stripped down Linux, this is a pretty viable setup if you have those devices distributed across a LAN with a managed switch in the middle.

dochtman 3y ago

Does Azure support ed25519 keys yet?

Svenstaro 3y ago
No. :(
er0k 3y ago
I thought this was a joke, but they really don't: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/ed25519-ssh-keys https://learn.microsoft.com/en-us/troubleshoot/azure/virtual... what the fuck? What is Microsoft doing? ed25519 was added to openssh, what, 7 years ago? This boggles my mind.
- Macha 3y ago
  Just about exactly 10 years ago, actually: https://lwn.net/Articles/590870/ https://lwn.net/Articles/590870/
- pbhjpbhj 3y ago
  Maybe they're supporting TLAs abilities to crack Microsoft users when 'necessary'?
- adastra22 3y ago
  It actually violates some federal contracting rules to support non-NIST keys. Maybe they don’t bother for that reason?
  - dharmab 3y ago
    Azure's gov cloud is a separate API.
    - adastra22 3y ago
      With a lot of shared software. Need a strong reason to introduce differences which if accidentally misconfigured could have large contract liabilities.

lxgr 3y ago

> DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key This should be 160 bit equivalent, right? An actual 160 bit (non-EC) DSA key would be trivially brute-forceable.

crote 3y ago
No, it's genuinely 160 bit keys. The SSHv2 protocol mandates FIPS-186-2, which only allows 160 bit keys. 224-bit and 256-bit keys were only introduced in the later FIPS-186-3.
- lxgr 3y ago
  Ah, I mistook "private" for "public" key. The private key is indeed 160 bit for DSA per FIPS-186-3; it's the public key that's 1024 bit. That's commonly used as the "security parameter" for DSA, though; 160 is very easy to confuse with e.g. a symmetric encryption key or hash length.

cust 3y ago

[dead]

mynameisnoone 3y ago

[flagged]

shrubble 3y ago

Some of the HP iLO and other servers as well as some networking gear uses this. Not sure those devices can be upgraded.

Piskvorrr 3y ago
You'd need to keep an older client to keep around for old devices. Sort of like that VM with WinXP and IE6, the one that's only kept because it has a semi-working ActiveX that some ancient device only interfaces with... shudder
- duozerk 3y ago
  This is already the case for very old target devices, that don't support the ssh v2 protocol at all; hence the existence of the ssh1 client (https://packages.debian.org/bookworm/openssh-client-ssh1 https://packages.debian.org/bookworm/openssh-client-ssh1).
- szundi 3y ago
  Older clients may be a target for attack then.
  - pavon 3y ago
    Yes, but I'd be much more concerned about the SSH server.
    - px43 3y ago
      I dunno, exploiting a vulnerability that lets you steal SSH keys from a sysadmin seems a bit more useful than hitting a single server.
      - NegativeK 3y ago
        As usual, it seems like it's a good idea for the open source project (ssh in this case) to drop old tech and move on while those dependent on it should maintain it, for whatever that means.

anonymousiam 3y ago

I don't understand the rationale for removing support for any algorithm. I can understand disabling support, but why remove it? I have often needed to connect to ancient systems that only support very old algorithms. From a modern ssh client, I will usually need to specify the needed algorithm on the ssh command line in order to connect. E.g. ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@x.x.x.x

halJordan 3y ago
Two of the big reasons are to keep code clean and security. Reference the latest linux kernels, and how they achieved most of their performance increases (hint they removed old code and simplified the codepaths). The second reason is to prevent it's use. It is not just good enough to consider the "happy path." There are unhappy paths where an adversary is able to make use of these abilities. When the aggregate unhappy paths overwhelm the single happy path, it's time to bite the bullet.
- mistrial9 3y ago
  ... plus hardware vendors, some very large companies and security consultants financially benefit from churn
  - woodruffw 3y ago
    Consultants might benefit, I don't think that hardware vendors (especially network appliance vendors) really do: these kinds of changes are purely an expense for them, since they have to reallocate engineers to fix things that were otherwise on "autopilot" for their support contracts.
imrejonk 3y ago
They provide a good reason for completely removing the DSA code: > 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. Vulnerabilities like heartbleed and Log4Shell is what you get when you have limited developer capacity but insist on endlessly keeping legacy code around.

faeriechangling 3y ago

There's lots of ways to ensure security aside from at the protocol level, and DSA helps with compatibility, so this just seems like a bad idea to me. I don't think anybody was really accidentally using DSA not understanding the implications.

kelnos 3y ago
If you need this support, perhaps you should pay someone on the OpenSSH team (or an independent 3rd party) to support it. It's not free to keep code around, unfortunately; every bit adds a maintenance burden. It's an open source project, and no one is entitled to anything in particular.

charlieyu1 3y ago

What is DSA? I checked wiki and it looks like RSA for signatures, using modular exponentials. RSA is going to stay for a while, so why is DSA removed?

skissane 3y ago
DSA was an alternative to RSA developed by the NSA, which used (other parts of) the US government to push for its implementation. It was never entirely clear why they were doing that, and there have always been (unproven) suspicions that the NSA wanted it adopted over RSA for underhanded reasons. Due to this history, it was never anywhere near as popular as RSA. Anyway, the US government (NIST) now recommends use of DSA be discontinued. By contrast, RSA was developed in academia and its adoption was independent of the US government’s influence (and at times even against its preference for DSA instead)
- jepler 3y ago
  My impression is that RSA was covered by patent (from 1983 until 2001). DSA was attractive in part because, while patented, the primary patent was held by the US government and royalty-free. I have vague memories (from circa 1995 comp sci undergrad coursework) that discrete log and integer factorization both appeared similarly difficult as mathematical/algorithmic problems. Thus, if you had to choose between a patent-encumbered protocol and a royalty-free one, it would make sense to choose DSA. That said, it seems to have never offered a particular advantage, and the modern view appears to be that DSA is weaker in practical terms.
abraxis 3y ago
RSA and DSA rely on different number theory problems. RSA relies on prime factorization being hard while DSA relies on the discrete logarithm being hard.

77pt77 3y ago

Does this include ECDSA?

loeg 3y ago
No.