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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
