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: $ head -n 20 ssh1_versions.txt 39148 SSH-1.5-Cisco-1.25 14477 SSH-1.5-HUAWEI-VRP3.1 10571 SSH-1.5-1.0.0 4634 SSH-1.5-HUAWEI-VRP-3.10 3284 SSH-1.5-1.2.33 2965 SSH-1.5-VRP-3.3 1836 SSH-1.5-VRP-3.4 1125 SSH-1.5-Server 1034 SSH-1.5-X 1022 SSH-1.5-1.2.22j4rad 753 SSH-1.5-1.2.26 538 SSH-1.5-OpenSSH_4.4 422 SSH-1.5-SSH 379 SSH-1.5-HUAWEI-VRP5.0 304 SSH-1.5-OpenSSH_2.3.0_Mikrotik_v2.9 270 SSH-1.5-SSHServer 269 SSH-1.5-1.2.27 223 SSH-1.5-OpenSSH_3.7.1p2 175 SSH-1.5-Huawei 136 SSH-1.5-LtSSH_3.6 Of course, this is out of a total of 15,124,618 SSH servers, granting a compat rate greater than 99.99%. 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. 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 790303 SSH-2.0-OpenSSH_6.6.1p1 771396 SSH-2.0-OpenSSH_5.9p1 465647 SSH-2.0-OpenSSH_5.5p1 430372 SSH-2.0-ROSSSH 338577 SSH-1.99-Cisco-1.25 337282 SSH-2.0-OpenSSH_6.2 325681 SSH-2.0-dropbear_0.52 315864 SSH-2.0-dropbear_2012.55 305623 SSH-2.0-dropbear_2013.58 178282 SSH-2.0-OpenSSH 169613 SSH-2.0-OpenSSH_4.7 162892 SSH-2.0-OpenSSH_5.1p1 160225 SSH-2.0-OpenSSH_5.3p1 150068 SSH-2.0-Cisco-1.25 141795 SSH-2.0-OpenSSH_5.1 130653 SSH-2.0-OpenSSH_6.7 122612 SSH-2.0-RomSShell_4.31 121542 SSH-2.0-homepl 116630 SSH-2.0-OpenSSH_5.8 112202 SSH-2.0-OpenSSH_6.4 98829 SSH-2.0-dropbear_2011.54 96457 SSH-2.0-OpenSSH_4.3-HipServ 88471 SSH-2.0-OpenSSH_5.2 88444 SSH-2.0-OpenSSH_5.9 86001 SSH-2.0-dropbear_0.48 69497 SSH-2.0-OpenSSH_5.4p1 67565 SSH-1.99-DOPRA-1.5 60749 SSH-2.0-OpenSSH_6.1 59323 SSH-2.0-ARRIS_0.50 59103 SSH-2.0-lancom 58497 SSH-2.0-Trendchip_0.1 57757 SSH-2.0-OpenSSH_5.6 55951 SSH-2.0-OpenSSH_6.2p2 54750 SSH-2.0-dropbear_0.50 52685 SSH-2.0-OpenSSH_6.6p2-hpn14v4 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, but let's not forget even SSHv1 is miles better than Telnet, and this just isn't the rapidly updating consumer browser ecosystem we're messing with here. --Dan On Tue, Mar 24, 2015 at 9:16 PM, Damien Miller <djm at mindrot.org> wrote:> On Tue, 24 Mar 2015, Nico Kadel-Garcia wrote: > > > If it's disabled by default in any major distributions, it's going > > to break a lot of git repositories, svn+ssh repositories, and rsync > > environments. > > The chronology doesn't support this. > > When Subversion 1.0 was released in 2004, OpenSSH had been defaulting to > protocol v.2 for almost three years. > > git was first released two years later, at which time v.2 had been the > default for over five years. > > Seriously, protocol 2 became the default in *2001* and the old protocol > has been disabled for new sshd installs for the last eight years. If > anything, we've moved way too slowly. > > > Can it wait until version 7, instead of being slipped into a minor > > update? > > Our version number has been a simple counter for years; the first digit > of the version has no significance beyond that. > > Distributions will make their own decisions about what to support and > they already ship far more intrusive changes than flipping a configure > switch. I hope they ship a "openssh-ssh1" package instead of just > setting it back through. > > -d >
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, absolutelyWe 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
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 >