FYI: SSH1 now disabled at compile-time by default

[Damien Miller]

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