FYI: SSH1 now disabled at compile-time by default

[Michael Felt]

My two-cents

removing v1 from the server - excellent.

removing it from the client - admirable, but there are many potential
operational concerns as mentioned above. I'll chat a bit about personal
experience with removal of something as being "more secure" when it's
effect is actually lessen "security"

Possible solution - even for beyond ?

Create a new client that only supports v1 protocol, and gives a 'nasty'
banner (depreciated, provided only for support of devices that do not
support v2, etc..) - This way, people are made consciously aware of the
weakness in their (old) device ssl support and/or of a poor configuration
(v2 disabled or not configured). Obviously, this client would/can not
communicate with the new servers that only support v2.

IMHO: part of security is making the user conscious of weaknesses and
motivating them to make change.

Experience: I have some hardware, on an internal network - that only
supports 40-bit ssl. I am forced to continue to use FF v17 because that was
the last browser to provide SSL40-bit support. My security is weakened
because I cannot update that browser, and I continue to lose plugins
because they do not support FF17 anymore. All other browsers stopped
support earlier as well.

So, complete removal, with no alternative means I cannot update to newer -
safer - technology. But security is three pronged:
Confidential, Integrity, and Availability. Removal of something such that
there is no alternative is equal to a security breach - I am an authorized
user, but no *availability *to access. -- Security broken - imho.

Michael

On Thu, Mar 26, 2015 at 7:30 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Wed, Mar 25, 2015 at 11:45 AM, Christoph Anton Mitterer
> <calestyo at scientia.net> wrote:
> > On Wed, 2015-03-25 at 18:48 +1100, Damien Miller wrote:
> >> Our ability to influence people who run truly obsolete software is
> >> extremely limited.
> > +1, mostly because those who still use something that outdated in their
> > products are either dead, or simply don't care about their customer's
> > security (which is typical in the embedded devices area).
> > Just by us (or anyone else) saying anything, that won't change.
> >
> >> The best we can do is deprecate as noisily as
> >> possible after extremely generous grace period. This is what we are
> >> doing
> > I think just deprecating is what has been done years ago - everyone can
> > by now truly know that SSH1 should not have been used since a long time.
> >
> > I'd even support if you really remove the v1 related code from the
> > codebase. Just deactivating it per default and affected people will
> > simply enable it again, without bothering to do their homework.
> > And even if 6.9 would really lack v1 support, people could still just
> > use anything <6.9  for v1 - they won't be less secure.
>
> Yanking it out wholesale should be part of a 7.0 build, not an
> incremental release. That's a major incompatibility with one heck of a
> lot of existing code, much of which is on extended support.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>