On Tue, Jul 06, 2021 at 08:05:11PM +0200, to...@tuxteam.de wrote:
On Tue, Jul 06, 2021 at 01:43:07PM -0400, Michael Stone wrote:
On Tue, Jul 06, 2021 at 01:02:49PM -0400, Stefan Monnier wrote:
>>>I think the first reaction should be to report it as a bug, so that the
>>>old cipher is re-added. I think the same argument in favor of including
>>>the "none" cipher should apply to including old deprecated ciphers.
>>The old ciphers are generally removed for a reason: because they are hugely
>>insecure.
>
>If they have buffer overflow-style holes, those should be fixed.
>Other than that I can't see how they can be less secure than the "none" cipher.
I guess since the "none" cipher isn't supported in debian's ssh you
will just drop this questionable line of argument?
FWIW, I fully agree with Stefan on this. We've seen a pretty valid
reason for keeping old ciphers. Move them out of the way, so that
people don't use them by accident. Refuse to downgrade to an insecure
cipher at the other side's request. Heck, have one option named
i-really-want-to-have-an-insecure-cipher-honestly or something.
It's entirely too common for obsolete encryption options that are kept
for "compatibility" end up being a vector for compromise, and entirely
reasonable to remove such options in order to provide the most secure
and maintainable tool for the vast majority of users.
If you want ancient crypto options, just run an ancient binary. They're
very easy to find in archive.debian.org.
Of course, the real answer is to not purchase products with "secure"
management that can't be upgraded when it becomes "insecure" management.
