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@xxxxxxxxx> wrote: > On Wed, Mar 25, 2015 at 11:45 AM, Christoph Anton Mitterer > <calestyo@xxxxxxxxxxxx> 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@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
