openssh unix dev - Mar 2015 - FYI: SSH1 now disabled at compile-time by default

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.


:)

Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150325/e2d5b610/attachment.bin>

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.

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
>

On 26/03, Nico Kadel-Garcia wrote:
>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.
>
And it?s been said multiple times in this thread that the OpenSSH 
version number is just a incrementing decimal number, it doesn?t have 
any major or minor releases.

-- 
Sincerely,
  Johannes L?thberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  https://theos.kyriasis.com/~kyrias/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1495 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150326/abc34619/attachment.bin>