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
--
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
