Legacy option for key length?

[Dan Mahoney (Gushi)]

On Mon, 1 Jan 2018, David Newall wrote:

> On 01/01/18 04:58, Emmanuel Deloget wrote:
>> 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.
>
> This doesn't make the Internet more secure because people aren't about to 
> throw away expensive equipment just because the latest openssh throws a hissy 
> fit.  They'll use an alternative.  Perhaps the alternative will be an older, 
> less secure version of openssh. Perhaps it will be even less secure telnet.  
> They will continue to use their still-good equipment, and so they should.
>
> If people choose to use old versions of openssh, which is likely, they may 
> also choose to make that the only version they use.  It makes a lot of sense: 
> it saves having to think about two different versions of the same software, 
> one which works properly and one which seems broken.  Force people to make 
> this choice and you weaken the whole ecosystem.
>
> Is there a way to stop people using weak ciphers without weakening the 
> ecosystem?  There is a way which is close: make openssh not use weak ciphers 
> unless the user says "I really, really need to use this weak cipher."  That's 
> all this is about. That doesn't weaken the ecosystem; it makes it stronger.
>
> Removing a weak cipher weakens the ecosystem by pushing people into using old 
> tools that have real bugs.  It's also arrogant.  it sounds too much like, 
> "you're too ignorant/lazy/cheap to decide what's right for you so we'll make 
> you do what we want, and we don't care how expensive and disruptive it is for 
> you."
>
> Removing a weak cipher breaks things that it didn't need to break.  That's 
> outrageous.
>
> It does not hurt to make the weaker cipher an option.  It's not hard, no 
> harder than the effort to remove it.

Not quite true.

I have some real options for people who come across this feed later.  I 
think the discussion is important, and I really wish that there was a 
patchset available (similar to the HPN patches) that was well known and 
maintained so that OS packagers had the option of using these options if 
they never made it into core openssh.

In this particular case, it was not a removed cipher, per-se, it was 
a weaker key-type.  Changing the minimum key lengh is a define, in 
sshkey.h I think.  That was a one-line commit.

Adding support to make that an invoke-time tunable is more work, but I 
think it's worth doing.  If there's a developer who wants to do it in a 
way that is reasonable, I'd ask what it would cost to sponsor that 
feature.

Whatever the outcome, I'd suggest putting a note about this on the SSH 
legacy options page, which is where I looked and where others might. 
I.e. a list of things for which the openssh devs have decided NOT to be 
backwards compatible with.

I might also suggest that since the support for ssh version 1 has been 
removed from openssh, and since ssh v1 is an artifact, frozen in time, 
which will never get any newer ciphers, that if I had to admin any systems 
which only supported ssh v1, that I might compile a separate "ssh1" binary 
which basically *forced* the -1 flag.  (Think for those of us that use 
tools like rancid to log into lots of equipment).  To be clear, that's not 
work I'd ask for from the ssh devs, but it would still make sense to 
audit it as a separate project and borrow some clue.

===

For the record, for anyone else reading this thread who hit my exact 
issue, there IS a way to get a 1024-bit cert onto the APC PDUs, but you 
have to generate it from off-device using a windows-only utility, and then 
scp it onto the device.  It's a giant pain in the butt, but it does work.

If I had gotten a warning like "HEY THIS USES 768-BIT KEYS WHICH WILL BE 
DEPRECATED IN A FUTURE VERSION OF SSH (within a year of $RELEASE DATE), I 
may have done the annoying process sooner.

However, I found myself with an ssh instead that required installing a 
whole other OS, because the removal of the feature left me with no way to 
get into my kit and upgrade.

I could have also fallen back to serial as a long-term solution.  Not 
every device will have this option.  Some of us have things like air 
conditioning controllers, or temperature sensors, or UPSes or things with 
tiny embedded controllers that really don't have this kind of a "patch 
every tuesday" upgrade path.

Best wishes for 2018,

-Dan

--