[Cryptography] Oracle discovers the 1990s in crypto

[Jerry Leichter]

> In case anyone missed it, Oracle will soon deprecate MD5 and use of keys under
> 1024 bits, and allow keys larger than 1024 bits to be used:
> 
> https://www.bleepingcomputer.com/news/security/oracle-to-block-jar-files-signed-with-md5-starting-with-april-2017/
> https://www.java.com/en/jre-jdk-cryptoroadmap.html
> 
> In other news, I expect them to announce porting Oracle to that newfangled
> Windows XP thing, and the upcoming release of a Windows 98 client for it.
To be slightly fairer to Oracle:  You would not believe the environments in which software that tries to be secure is forced to fit.  (Well ... you of all people would.)

A couple of releases back, Oracle dropped support for older versions of SSL from the JDK, leaving only TLS.  (There's a documented option to turn the support back on, but it's never worked.)  TLS is by now almost 10 years old (depending on exactly what you want to count), so this won't break anything ... right?  Hah.  The software I work on has to communicate with various elements of enterprise hardware - minor things like disk arrays.  With the new JDK, we could no longer connect to one vendor's hardware.  Not legacy stuff, mind you - stuff currently being sold.  It turns out that secure connections to that particular hardware support only older versions of SSL.

To be more accurate:  They support only older versions of SSL *by default*.  There's a command-line option to turn on TLS support; it's off as the system and its most recent updates are delivered.  Mind you, this isn't an option to *replace* SSL with TLS - it simply enables TLS *in addition to* SSL.  But for some reason ... it's off by default.

So customers will just turn it on, right?  Oh, you make good joke.  Managing the settings on the disk arrays is owned by a completely separate group.  You have to get it on their list of to-do's.  They may resist any "non-standard" settings.  They may insist on multiple layers of sign-offs.  They may insist on getting approval from the vendor.

Removing support for protocols and cryptographic primitives is very, very difficult.  The systems we build are simply not designed to adjust appropriately.

Anyone want to bet on how many pre-build jar files, signed years ago with MD5 or short RSA keys, are out there in Maven repositories, waiting to cause build and run-time failures all over the planet?  How many of them will turn out to have long-lost source trees, or will have source trees that can no longer be built because the tooling around them has deteriorated?

Actually, I suspect that things won't be as bad as they might have simply because so many of these widely-shared artifacts aren't signed anyway....

                                                        -- Jerry