openssh unix dev - May 2016 - An update on SSH protocol 1

Hi,

At this stage, we're most of the way towards fully deprecating
SSH protocol 1 - this outlines our plans to complete this task.

We've had this old protocol in various stages of deprecation for almost
10 years and it has been compile-time disabled for about a year.
Downstream vendors, to their credit, have included this change in recent
OS releases by shipping OpenSSH packages that disable protocol 1 by
default and/or offering separate, non-default packages to enable it.

This seems to have proceeded far more smootly than even my most
optimisitic hopes, so this gives us greater confidence that we can
complete the removal of protocol 1 soon. We want to do this partly to
hasten the demise of this cryptographic trainwreck, but also because
doing so removes a lot of legacy code from OpenSSH that inflates our
attack surface. Having it gone will make our jobs quite a bit easier
as we maintain and refactor.

So here are our plans. Dates are estimates only.

* June 2016

Release OpenSSH 7.3. SSH protocol 1 is unchanged. We start mention
these plans in the release notes to give them wider publicity.

* August 2016

Release OpenSSH 7.4. Server-side support for SSHv1 is removed from
our codebase. Client support remains disabled by default.

* June 2017

OpenSSH removes all SSH protocol 1 support.

--

So this is just over a year of notice ahead of final deprecation. After
we release OpenSSH without SSHv1 support, users who absolutely need it
would have to use a prior version of OpenSSH or some other
implementation.

We recognise that this may leave some users without a supported client
for their protocol v1 hosts, but we feel that >10 years of transition
is time enough.

Feedback is welcome.

Cheers,
Damien Miller (on behalf of the team)

On Tue, May 03, 2016 at 10:33:29PM +1000, Damien Miller
wrote:
> We've had this old protocol in various stages of deprecation for almost
> 10 years and it has been compile-time disabled for about a year.
> Downstream vendors, to their credit, have included this change in recent
> OS releases by shipping OpenSSH packages that disable protocol 1 by
> default and/or offering separate, non-default packages to enable it.
Debian takes the latter approach.  Specifically, we have an
"openssh-client-ssh1" binary package that includes only scp1, ssh1,
and
ssh-keygen1 binaries; we do not ship any server-side SSHv1 support.  I
modelled this on Fedora's approach, which is basically the same aside
from a slightly different package name.

A number of our users are basically stuck needing to interoperate with
SSHv1-only servers that they can't update for one reason or another.
Obviously this is a pretty broken world, but maybe they're at least
behind a VPN or firewalled to the local network or something and at any
rate I'm rather glad that none of those things are directly my problem.

My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1
is entirely removed from OpenSSH, I will split out the
openssh-client-ssh1 binary package to be built from a separate source
package which will remain frozen at the last OpenSSH release that
supported SSHv1.  As before, this will ship only scp1, ssh1, and
ssh-keygen1 binaries.

If I notice any fixes for client-side vulnerabilities that might affect
SSHv1, then I'll backport them on a best-effort basis, but I expect this
to be rare.  The protocol is sufficiently broken anyway that I'm not
going to lose much sleep over it.  I've had it suggested to me that I
should try to strip it down further (e.g. removing X forwarding
capability), but on the whole I think the chances of accidentally
breaking something as a result in something I don't myself use outweigh
the expected benefits.

Any comments on this?  Feedback from the changes in 7.0 has convinced me
that Debian does need to keep shipping basic client-side support in some
form, but it can be very minimal and I'm happy to put whatever dire
warnings on it seem useful and appropriate.

Notwithstanding all this, the plan of removing all this obsolete code
from OpenSSH proper makes a lot of sense to me and I have no complaints
there.

-- 
Colin Watson                                       [cjwatson at debian.org]

On Tue, 3 May 2016, Colin Watson wrote:
> Debian takes the latter approach.  Specifically, we have an
> "openssh-client-ssh1" binary package that includes only scp1,
ssh1, and
> ssh-keygen1 binaries; we do not ship any server-side SSHv1 support.  I
> modelled this on Fedora's approach, which is basically the same aside
> from a slightly different package name.
> 
> A number of our users are basically stuck needing to interoperate with
> SSHv1-only servers that they can't update for one reason or another.
> Obviously this is a pretty broken world, but maybe they're at least
> behind a VPN or firewalled to the local network or something and at any
> rate I'm rather glad that none of those things are directly my problem.
> 
> My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1
> is entirely removed from OpenSSH, I will split out the
> openssh-client-ssh1 binary package to be built from a separate source
> package which will remain frozen at the last OpenSSH release that
> supported SSHv1.  As before, this will ship only scp1, ssh1, and
> ssh-keygen1 binaries.
> 
> If I notice any fixes for client-side vulnerabilities that might affect
> SSHv1, then I'll backport them on a best-effort basis, but I expect
this
> to be rare.  The protocol is sufficiently broken anyway that I'm not
> going to lose much sleep over it.  I've had it suggested to me that I
> should try to strip it down further (e.g. removing X forwarding
> capability), but on the whole I think the chances of accidentally
> breaking something as a result in something I don't myself use outweigh
> the expected benefits.
> 
> Any comments on this?  Feedback from the changes in 7.0 has convinced me
> that Debian does need to keep shipping basic client-side support in some
> form, but it can be very minimal and I'm happy to put whatever dire
> warnings on it seem useful and appropriate.
> 
> Notwithstanding all this, the plan of removing all this obsolete code
> from OpenSSH proper makes a lot of sense to me and I have no complaints
> there.
Your plan sounds emminently reasonable and I'll repeat my thanks
for your helping the transition by making separate -ssh1 packages.


-d