[c-nsp] ASR1000 IOS Version

[Lukas Tribus]

> On Wed, Feb 18, 2015 at 09:15:51PM +0000, Mack McBride wrote:
> This is probably the correct action.
> Disable the insecure protocol and force people to use command
> line until they upgrade.

Disabling all crypto protocols in the code without providing
alternatives and forcing people to do use HTTP instead of
HTTPS doesn't seem neither correct nor secure to me. Its not like
TLS support is in that branch, thats the point.

What they should have done is not wait until 15.4 to implement
TLS. Now still, in very recent code there is only TLSv1.0 support, no
TLSv1.1, no 1.2, missing all the recent cipher suites.

So how long till we have to deprecate TLSv1.0 for an urgent security
matter and we will have the very same issue all over again?

TLSv1.0 was defined in the late 90's and OpenSSL introduced support
for it shortly afterwards. So it took them 15 years to implement TLSv1.0,
thats not particularly impressive (from standard definition to a M or S
release).

*TLSv1.0 is already in deprecation phase in 2014* [1], so how long
will it last? Probably not until Cisco merges TLSv1.1/2 support (at it
makes its way into a usable release).

Clearly, there is no BU responsible for the SSL code, a part from PSIRT.



> (I could care less about https, nobody uses that anyway on IOS, right?)

I do, I use it to push the configs from the box (at every "write mem") to
a central HTTPS server that tracks those configs in a git repository.

I understand thats a pretty specific use case, but I had hoped that VPNSSL
would be a strong enough driver to not let the SSL stack rot in the code for
decades.



> force people to use command line until they upgrade.

This is not about the configuring the router through HTTPS instead of
SSH. Its about VPNSSL, its about the HTTPS filesystem and the features
relying on the internal SSL stack for operation that are now completely
broken, in a maintenance IOS branch without any notes or warning in the
release notes.

But no, this was clearly not intended. They just cherry-picked this CVE-fix and
applied it to the old branches without thinking (and without testing, of course).


-lukas


[1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf