All, I occasionally manage some APC PDU devices. I manage them via a VPN, which enforces super-heavy crypto, and their access is restricted to only jumphosts and the VPN. Basically, the only time you need to log into these is when you go to reboot something that's down. Their web UI with SSL doesn't work with modern browsers. Their CPU is...tiny, and their SSHd implementation is...old (and, I believe, proprietary). I think it defaults to RSA768, and even then, takes a good 15 seconds to let you log in. When trying to SSH to them most recently from a recent copy of MacOS, I got the "Invalid Key Length" error. I googled around for the release note and the source code commit that had produced this, and then tried looking for workarounds here: https://www.openssh.com/legacy.html After all, since the OpenSSH devs think carefully enough to have a page that documents legacy options, for sure they thought of one for this case too, right? It doesn't seem so. My workaround was, insanely, to fire up a VM with an older version of an OS with an older openSSH client. So... Why not make minimum key length a tunable, just as the other options are? In this way, sites with a more strict policy could actually specify it (i.e. RSA2048 or better) Perhaps if you're dead-set on this being so dangerous, you could make it so that you could specify a command-line option to accept a lower value one time, but you're perhaps not able to override it via the config. Thanks, -Dan --
On 2017-12-29, Dan Mahoney (Gushi) <danm at prime.gushi.org> wrote:> I occasionally manage some APC PDU devices. I manage them via a VPN, > which enforces super-heavy crypto, and their access is restricted to only > jumphosts and the VPN. Basically, the only time you need to log into > these is when you go to reboot something that's down. > > Their web UI with SSL doesn't work with modern browsers. > Their CPU is...tiny, and their SSHd implementation is...old (and, I > believe, proprietary). > > I think it defaults to RSA768, and even then, takes a good 15 seconds to > let you log in.I have some of these too. I used an old browser to connect to the web interface, turned off SSH and switched to using telnet from the jumphost instead. Given how crappy SSH is on these even when short keys were allowed, this was overall a big improvement.> I googled around for the release note and the source code commit that had > produced this, and then tried looking for workarounds here: > https://www.openssh.com/legacy.htmlThe only workarounds are to recompile or use different software to connect.
On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote:> Why not make minimum key length a tunable, just as the other options are?Because the goal of building secure software is to make it easy to answer the question "are you using it securely?" you note that modern browsers (which do try to take security seriously, despite their vast attack surface) have the same "problem" as the modern OpenSSH ssh client does. If you're responsible for those ADC devices, you should probably take one of these avenues: a) ask the vendor to release an upgrade to their firmware so that you're not tied to their ancient (likely buggy) version. b) ask the vendor to open their specs and upgrade channels so that someone else could update their firmware c) configure the devices to offer a non-secure protocol (e.g. telnet), that never claims to be secure, if you're confident in the rest of your network perimeter security d) remove the devices and replace them with something that is actually well-supported.> Perhaps if you're dead-set on this being so dangerous,It's not the developers who are dead-set on weak-keyed RSA being insecure, it's the cryptanalysts who have shown that to be the case :)> you could make it so that you could specify a command-line option to > accept a lower value one time, but you're perhaps not able to override > it via the config.For your own purposes, you can of course always compile old versions of code to do terrible things, and you can recompile free software with patches to make it do terrible things. But please don't ask to make it easier for free software to do terrible things to *other* people. That way lies things like the TLS "Export" cipher suites, which are mistakes we are *still* paying for, decades after their introduction. If OpenSSH introduces this option, i'm sure we'll soon see it on stack exchange as "how do i get ssh to work in condition $X?", at which point the option or command-line argument will be copy/pasted into far more places than it should be. Please, don't make it easy to weaken this already-too-weak baseline. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20171229/4374b796/attachment.asc>
On 30/12/17 09:46, Daniel Kahn Gillmor wrote> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: >> Why not make minimum key length a tunable, just as the other options >> are? > Because the goal of building secure software is to make it easy to > answer the question "are you using it securely?" >That answer is wrong.? The suggestion, which allowed that security was important, allowed for an option which could only be used by explicitly setting it at SSH invocation, so, that means, if you don't use the option then you are (maybe) using it securely, and if you do use the option, then you are using it in the most secure way possible (because you'd only use it when forced to.) By making it impossible for people to use SSH you are forcing people to use less secure software; telnet because they can't use ssh; old, buggy versions of ssh because that's what they had to install so that they could connect to their industrial equipment. The answer is also boneheaded:> remove the devices and replace them with something that is actually > well-supportedWe'd be better removing arrogance from essential development teams, people who think that replacing a world full of expensive and functioning equipment is an option.? It's not, and nor should it be.? That's a disgraceful suggestion and you should be ashamed of yourself. Browser developers got it badly wrong; let's not join them. The suggestion was good because there's a wide-spread need for shorter keys and the suggested solution doesn't allow shorter keys unless explicitly set per invocation.
Hello, On Sat, Dec 30, 2017 at 12:16 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: > > > > Perhaps if you're dead-set on this being so dangerous, > > It's not the developers who are dead-set on weak-keyed RSA being > insecure, it's the cryptanalysts who have shown that to be the case :) >?To further supplement this point, here is the paper that explain how RSA-768 was factorized. In 2010, the authors estimated that it would take around 1500 years to a single-core machine of this generation to ?do the same thing. We're 7 years after their first results, and we now have access to massive cloud-based behemoths for a discount. How much time would it resist? The idea of removing weak ciphers from a widely used piece of software is a good one - that way, you strengthen the whole ecosystem. Going the reverse path would simply make less informed people be the weak link of the Internet, putting possibly many more at risk. Best regards, -- Emmanuel Deloget
On Fri, 29 Dec 2017, Daniel Kahn Gillmor wrote:> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: > > Why not make minimum key length a tunable, just as the other options are? > > Because the goal of building secure software is to make it easy to > answer the question "are you using it securely?"This is a nice summation of our approach. It's the same reason we've never implemented the null cipher and also one of the reasons we removed SSHv1. We try to balance compatibility with avoiding danger. This is why it's still possible to explicitly enable (weak, but AFAIK not broken) DSA keys if you need them, but RSA768 has actually been demonstrated to be broken with an academic team factoring a key back in 2009 at a work factor that is easily reachable by a medium botnet or cloud service. Adding a switch to turn these back on would be IMO irresponsible. If you think this is overly parentalistic and that an experienced admin is the one best equipped to assess risk, then I'd direct said experienced admin to the the SSH_RSA_MINIMUM_MODULUS_SIZE definition in sshkey.h that they can adjust themselves. -d