4 ms·

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

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.

rho138 3y ago
They’re the perfect target to hit when looking to pivot across/through a network though. Not to mention the risk of being hit during a ransomware event. Keeping around legacy hardware/software is the pinnacle of fuck around and find out.
- mynameisnoone 3y ago
  You're offering hypothetical, worst-case whataboutisms. In the real world, any shop that isn't stupid will use defense-in-depth to protect the unupgradable bits.
  - afavour 3y ago
    > You're offering hypothetical, worst-case whataboutisms Otherwise known as “security”, yes
    - mynameisnoone 3y ago
      Whatever. Imaginary paranoia strawman that is the wrong kind of paranoia: the unactionable, ego-based kind. You completely ignored defense-in-depth approaches like airgapped systems and adding additional layers and protections to mitigate your hypothetical non sequitur. If you fail at these then you don't actually understand security and are just arguing without a leg to stand on.
      - afavour 3y ago
        Your attitude here is confusingly hostile. But sure! If I have a server I currently use OpenSSH to connect then I certainly _could_ airgap the machine and require anyone using it to be in physical proximity to it. But don't you think that might be unrealistic in the vast majority of scenarios?
        anonymousiam 3y ago
        But the airgap scenarios are very real, and they make it more difficult to just go online and grab an old ssh client that will do the job. It seems that the argument for removing support for the old algorithms involves the need to maintain them in the new releases. This only becomes a problem if/when the code and/or regression testing is refactored. So eventually the effort required to remove support becomes less than the effort needed to continually support the old algorithms. The OpenSSH maintainers can of course do anything they like, but removing support for legacy algorithms is basically passing the problem down to (probably less capable) users who are stuck without the ability to connect to their legacy systems.
        Piskvorrr 3y ago
        You do recall that the source control doesn't disappear, even after support is pulled? I've built ancient versions (specifically in case of SSH, to get arcfour for whatever convoluted system); this wasn't a simple operation, but feasible, even for someone with just a general knowledge of SSH and its build toolchain. Maintaining code also takes time and effort: smaller codebase, effort better spent. If it's too costly to just keep an ancient version of ssh around, and even too costly to pay someone to do that for you, how's it suddenly NOT too costly for the maintainers? If you're going to the lengths of having a special airgapped network of legacy systems, how do you NOT have the tools to use with those systems?
        anonymousiam 3y ago
        I think you missed my remark about the inability to pull an old version from within an airgapped environment. It's usually still possible, but the level of difficulty can vary depending upon security requirements. Imagine a security officer refusing to approve the introduction of an older and insecure program into a secure environment.
        Piskvorrr 3y ago
        I very much did not miss that: "how do you NOT have the tools to use with those systems?" The hypotetical airgapped secure environment, running an old version of SSH (which only supports DSA) has no requirements for a SSH client, just "eh, just bring whichever openssh that you happen to have, and let's assume it works"? That's a failure to plan: if your network is airgapped, you can't expect to have client software in compatible versions appear out of thin ether.
    - faeriechangling 3y ago
      Security is about risk profiling and making good tradeoffs between things like cost, convenience, timeliness, and confidentiality/integrity/availability. All computer security is basically futile because in the face of a sufficiently motivated attacker, so chasing perfection is wasting your time. If you're doing home security, you don't use armed guards and reinforced steel doors, with the defense of depth of an extra-secure bulletproof safe room, because the security would cost more than the value it provides. You might use a good deadbolt though. The same goes for computer security. In combination with certain security approaches like air gapping, a technically insecure out of band management network can quickly become a dramatically less plausible means of being exploited compared to say - unsexy things like email phishing attacks. So replacing all your servers with ones with supported out of band management systems can simply not be a reasonable priority to have.
- 127361 3y ago
  Instead we'll have the company going bust for constantly having to replace critical machinery in the name of "security". Sometimes it is necessary to keep old equipment around and it can be secured using physical methods (an air-gap).
mynameisnoone 3y ago
Exactly. There are untold 10's to 100's of millions of critical infrastructure systems that cannot be upgraded containing insecure and horrible SSH implementations. Defense-in-depth by layers of other security measures and isolation permits them to be reasonably secure for their use prior to lifecycle replacement where possible. Furthermore, no one should place remote access servers on the internet and should instead place them on a private, internal network behind an infrastructure VPN-jumpbox such as OpenVPN or Wireguard. Only a few extremist developers in control of all of their own software and who don't have to interact with anything in the real world can maintain the idealistic purity to forever run only the latest version of everything.
- afavour 3y ago
  > idealistic purity to forever run only the latest version of everything But the OpenSSH devs are specifically saying “just use the old version if you need this”?
  - mynameisnoone 3y ago
    You're sweeping several huge assumptions under the rug. While it might work for the moment incidentally but it isn't a long-term solution.
    - afavour 3y ago
      It seems only fair to me that if someone is insisting that they must connect to ancient systems that they should be expected to use only-slightly ancient software to do so. Or fork it, of course. If the team doesn’t want to be responsible for maintenance you’re welcome to take it on.
    - chlorion 3y ago
      I'm not sure that I understand this. The openssh developers supporting outdated systems and software forever also isn't a long term solution. Why should they pay this cost, but not you (or your company)? If you can keep unsupported hardware in operation, why can't you keep a containerized openssh image around, or maybe a VM image, or ideally a statically linked executable? Maybe your company can hire an expert in software archival to set this up and maintain it if needed, or an extra developer to maintain an openssh fork that supports your environment. Expecting other people (who you don't even pay) to support your outdated systems doesn't really make sense.
autoexec 3y ago
Old outdated versions of OpenSSH are are also fine to use in private protected environments where security isn't a concern so there's not much problem

rho138 3y ago

They’re the perfect target to hit when looking to pivot across/through a network though. Not to mention the risk of being hit during a ransomware event. Keeping around legacy hardware/software is the pinnacle of fuck around and find out.

mynameisnoone 3y ago
You're offering hypothetical, worst-case whataboutisms. In the real world, any shop that isn't stupid will use defense-in-depth to protect the unupgradable bits.
- afavour 3y ago
  > You're offering hypothetical, worst-case whataboutisms Otherwise known as “security”, yes
  - mynameisnoone 3y ago
    Whatever. Imaginary paranoia strawman that is the wrong kind of paranoia: the unactionable, ego-based kind. You completely ignored defense-in-depth approaches like airgapped systems and adding additional layers and protections to mitigate your hypothetical non sequitur. If you fail at these then you don't actually understand security and are just arguing without a leg to stand on.
    - afavour 3y ago
      Your attitude here is confusingly hostile. But sure! If I have a server I currently use OpenSSH to connect then I certainly _could_ airgap the machine and require anyone using it to be in physical proximity to it. But don't you think that might be unrealistic in the vast majority of scenarios?
      - anonymousiam 3y ago
        But the airgap scenarios are very real, and they make it more difficult to just go online and grab an old ssh client that will do the job. It seems that the argument for removing support for the old algorithms involves the need to maintain them in the new releases. This only becomes a problem if/when the code and/or regression testing is refactored. So eventually the effort required to remove support becomes less than the effort needed to continually support the old algorithms. The OpenSSH maintainers can of course do anything they like, but removing support for legacy algorithms is basically passing the problem down to (probably less capable) users who are stuck without the ability to connect to their legacy systems.
        Piskvorrr 3y ago
        You do recall that the source control doesn't disappear, even after support is pulled? I've built ancient versions (specifically in case of SSH, to get arcfour for whatever convoluted system); this wasn't a simple operation, but feasible, even for someone with just a general knowledge of SSH and its build toolchain. Maintaining code also takes time and effort: smaller codebase, effort better spent. If it's too costly to just keep an ancient version of ssh around, and even too costly to pay someone to do that for you, how's it suddenly NOT too costly for the maintainers? If you're going to the lengths of having a special airgapped network of legacy systems, how do you NOT have the tools to use with those systems?
        anonymousiam 3y ago
        I think you missed my remark about the inability to pull an old version from within an airgapped environment. It's usually still possible, but the level of difficulty can vary depending upon security requirements. Imagine a security officer refusing to approve the introduction of an older and insecure program into a secure environment.
        Piskvorrr 3y ago
        I very much did not miss that: "how do you NOT have the tools to use with those systems?" The hypotetical airgapped secure environment, running an old version of SSH (which only supports DSA) has no requirements for a SSH client, just "eh, just bring whichever openssh that you happen to have, and let's assume it works"? That's a failure to plan: if your network is airgapped, you can't expect to have client software in compatible versions appear out of thin ether.
  - faeriechangling 3y ago
    Security is about risk profiling and making good tradeoffs between things like cost, convenience, timeliness, and confidentiality/integrity/availability. All computer security is basically futile because in the face of a sufficiently motivated attacker, so chasing perfection is wasting your time. If you're doing home security, you don't use armed guards and reinforced steel doors, with the defense of depth of an extra-secure bulletproof safe room, because the security would cost more than the value it provides. You might use a good deadbolt though. The same goes for computer security. In combination with certain security approaches like air gapping, a technically insecure out of band management network can quickly become a dramatically less plausible means of being exploited compared to say - unsexy things like email phishing attacks. So replacing all your servers with ones with supported out of band management systems can simply not be a reasonable priority to have.
127361 3y ago
Instead we'll have the company going bust for constantly having to replace critical machinery in the name of "security". Sometimes it is necessary to keep old equipment around and it can be secured using physical methods (an air-gap).

mynameisnoone 3y ago

Exactly. There are untold 10's to 100's of millions of critical infrastructure systems that cannot be upgraded containing insecure and horrible SSH implementations. Defense-in-depth by layers of other security measures and isolation permits them to be reasonably secure for their use prior to lifecycle replacement where possible. Furthermore, no one should place remote access servers on the internet and should instead place them on a private, internal network behind an infrastructure VPN-jumpbox such as OpenVPN or Wireguard. Only a few extremist developers in control of all of their own software and who don't have to interact with anything in the real world can maintain the idealistic purity to forever run only the latest version of everything.

afavour 3y ago
> idealistic purity to forever run only the latest version of everything But the OpenSSH devs are specifically saying “just use the old version if you need this”?
- mynameisnoone 3y ago
  You're sweeping several huge assumptions under the rug. While it might work for the moment incidentally but it isn't a long-term solution.
  - afavour 3y ago
    It seems only fair to me that if someone is insisting that they must connect to ancient systems that they should be expected to use only-slightly ancient software to do so. Or fork it, of course. If the team doesn’t want to be responsible for maintenance you’re welcome to take it on.
  - chlorion 3y ago
    I'm not sure that I understand this. The openssh developers supporting outdated systems and software forever also isn't a long term solution. Why should they pay this cost, but not you (or your company)? If you can keep unsupported hardware in operation, why can't you keep a containerized openssh image around, or maybe a VM image, or ideally a statically linked executable? Maybe your company can hire an expert in software archival to set this up and maintain it if needed, or an extra developer to maintain an openssh fork that supports your environment. Expecting other people (who you don't even pay) to support your outdated systems doesn't really make sense.

autoexec 3y ago

Old outdated versions of OpenSSH are are also fine to use in private protected environments where security isn't a concern so there's not much problem