FYI: SSH1 now disabled at compile-time by default

[Dan Kaminsky]

There's a world of difference between changing defaults and killing
functionality.  SSH in general and OpenSSH in particular is part of what
we'll eventually get around to identifying as (I know everyone hates this
word) critical infrastructure.  That means it doesn't break, particularly
not intentionally, and even more particularly not without time, warning,
and probably public input.

There's a universe of assumptions going on here, like that most people
managing these clients are network administrators *or even human beings* as
opposed to automated update processes.  Or that others have the same
ridiculous superpowers for figuring things out like port forwarding chains
as opposed to just SSH'ing over and over.  Gateway bastions are often
chained, and if any of those gets updated, suddenly routers can't be
configured.  Not all boxes are of equal importance.

The risk here is that people suppress updating OpenSSH even more than they
have.  Don't give them a good reason.  Aggressively breaking changes don't
belong in minor versions in code of this criticality.

Now threatening the breaking change, even possibly attaching a date to it,
that creates the sort of pressure that actually does get servers upgraded.

Two questions:

1) What is the worst known SSHv1 attack right now?
2) What is the oldest build of OpenSSH you believe is safe to operate, as a
client, and as a server?  Imagine there was a compliance bar -- where would
you put it?

I'm no fan of SSHv1, to be clear.  This is exclusively process pushback.


On Tue, Mar 24, 2015 at 11:10 PM, Damien Miller <djm at mindrot.org> wrote:

>
>
> On Tue, 24 Mar 2015, Dan Kaminsky wrote:
>
> > Alright, so I pulled the data from scans.io,  There's actually 82,650
> > devices on the open Internet claiming support for <=SSH-1.5, generally
> > routers.  Top 20 on that is:
> [snip]
>
> > Of course, this is out of a total of 15,124,618 SSH servers, granting a
> > compat rate greater than 99.99%.
>
> OK, so most of the <0.01% of users are network administrators - a
> fairly technical audience and one that I doubt would have trouble
> procuring a v.1 capable ssh client. I bet the majority of admins
> wouldn't even be using OpenSSH as the client.
>
> > However, distinctly and painfully unlike
> > SSL/TLS, SSH is successfully deployed and used on internal networks that
> > cannot be scanned from the open Internet.  It's also a protocol of fairly
> > critical importance, uniquely used in a "hop by hop" manner in which each
> > hop actually has to work.
>
> Not really, people can port-forward. Besides, the most common hop-by-hop
> configuration is the gateway bastion, which also happens to be the 1)
> the most important to keep up to date and 2) the easiest to fix (since
> you only need to fix the bastion).
>
> > 7.3% of Cisco routers on the open Internet only support SSHv1.  The
> numbers
> > inside private networks are likely to be higher.
> >
> > I can see the argument for pushing people to upgrade, but not by
> surprise in
> > a minor version.  If SSH is going to block old insecure versions it has a
> > much bigger problem, because upgrade rates on SSH on the Internet are
> > actually not fantastic.  Here's the top 40 across all versions of SSH:
> >
> > $ head -n 40 sshall_versions.txt
> > 2412684 SSH-2.0-OpenSSH_5.3
> >  984056 SSH-2.0-OpenSSH_4.3
> >  936855 SSH-2.0-dropbear_0.51
> >  854624 SSH-2.0-dropbear_0.46
> >  798414 SSH-2.0-OpenSSH_6.0p1
> [snip]
>
> This brings to light another point: we can turn off v.1 by default at
> our end, but it won't filter through to what the majority of users see
> for several years.
>
> > This is specifically a scenario where OpenSSH should measure twice and
> cut
> > once.  The worst case scenario is that people update even less than they
> > already do, because who knows what servers are no longer important
> enough to
> > require connectivity to next.
>
> > Start the discussion, absolutely
>
> We started the discussion _14 years ago_ by making protocol 2 the default.
>
> We prodded people _8 years ago_ by making protocol 2 the only thing
> supported on the server for new installs.
>
> We prodded people again _6 years ago_ by requiring explicit configuration
> at both client and server to enable v.1 at all.
>
> At this point, I don't think any further discussion is going to make any
> difference. Do you think another two years would make an appreciable
> change to the numbers you posted above, beyond old hardware literally
> dying of old age?
>
> -d
>