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 >
On Tue, 24 Mar 2015, Dan Kaminsky wrote:> 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.There are no minor releases, there are no major releases - there is only a decimal version number that increments by 0.1 per release.> Now threatening the breaking change, even possibly attaching a date to it, > that creates the sort of pressure that actually does get servers upgraded.That's effectively what we're doing. Approximately 0% of the administrators of ancient Cisco devices will compile OpenSSH themselves and even fewer read our release notes, so us turning off v.1 support is the best way to publicise a change that is long overdue. So please, go and tell the world how terrible we are and make as much noise as possible :) The source releases we make sit at the beginning of a very slow upgrade pipe - your own numbers demonstrate that clearly. Ubuntu don't have an LTS scheduled this year and Redhat (probably the worst offender at keeping ancient OpenSSH on the Internet) haven't even announced their next RHEL.> Two questions: > > 1) What is the worst known SSHv1 attack right now?It's hard to say, is the use of CRC32 as a MAC worse than the baked in use of MD5 for signatures? Both seem a bit worse than the lack of proper PFS and the terribly weak private key format, and much worse than the lousy cipher choice. Basically, I wouldn't be surprised if the "some capability" against SSH mentioned in the Bullrun documents was an ability to break v.1, at least via active MITM.> 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?Personally, I wouldn't choose to run anything at the server that isn't pre-auth sandboxed so >=5.9 (released 2011/09), but I'm pretty paranoid. At the other extreme, someone (not me) could make the case that anything with AES-CTR and DH-GEX can be configured for reasonably safe crypto if you're willing to aggressively patch out the security bugs like the really-long term support OS distributions do. So that's basically anything back to 2005. Basically, anything that I think is remotely sensible to run is capable of protocol v.2 and uses it by default. -d
On Tue, 24 Mar 2015, Dan Kaminsky wrote: BTW you didn't respond to this. IMO it is the essence of the problem:> > 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?Our ability to influence people who run truly obsolete software is extremely limited. The best we can do is deprecate as noisily as possible after extremely generous grace period. This is what we are doing -d
Protocols and ciphers are sunsetted all the time, this is a regular thing, but there are announcements before breaking changes are inserted. You assume people are slow to update anyway; some are, some aren't, what you're doing is wildly rewarding the slow updaters and punishing the fast ones. That has negative effects elsewhere. What would it hurt to announce the release in 3-6 months will drop SSHv1 to a compile time option, and that people should be running (for example) at least OpenSSH 5.9x? You've got vendor class authority here, tell people what you want and give them some time to implement your directive. The alternative is they eventually trace back why some random critical system failed to this very thread and are like, yeah, never blindly push *that* guy's code... On Wed, Mar 25, 2015 at 12:48 AM, Damien Miller <djm at mindrot.org> wrote:> On Tue, 24 Mar 2015, Dan Kaminsky wrote: > > BTW you didn't respond to this. IMO it is the essence of the problem: > > > > 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? > > Our ability to influence people who run truly obsolete software is > extremely limited. The best we can do is deprecate as noisily as > possible after extremely generous grace period. This is what we are > doing > > -d >
On 03/25/2015 08:23 AM, Damien Miller wrote:> The source releases we make sit at the beginning of a very slow upgrade > pipe - your own numbers demonstrate that clearly. Ubuntu don't have > an LTS scheduled this year and Redhat (probably the worst offender at > keeping ancient OpenSSH on the Internet) haven't even announced their > next RHEL. >The Red Hat Enterprise Linux 7.1 with openssh-6.6.1p1 was released March 5, 2015. Petr -- Petr Lautrbach -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150325/a574582d/attachment.bin>
Christoph Anton Mitterer
2015-Mar-25 15:45 UTC
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 > doingI 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>