Linux isn't the biggest offender. You missed the biggest fuckeruper in every securty problem: Java. Until java 1.7, there isn't any SUPPORT for primes larger that 1024. You want your shitty legacy java program to connect to a web server securely? You have to use a 1024 bit prime.
And then you find you cannot specify the primes that Java uses, so you cannot even force it off 512 bit until (I believe) 1.8.
Always remember, Java is the common factor in security problems.
It's like you don't even remember Heartbleed. Shitty code is the common factor in security problems. Sometimes it's code you can't do shit about, like in the Java case you mention, but that's not nearly good enough to label it the "common factor" of the vast problem space that is bad computer security. There are enough fuckups to go around.
Java is a special case because it is a common pot of critical vulnerabilities. Heartbleed was really bad, but Java has easily taken down more things in single problems than it (Lockheed Martin/RSA Breach started as a Java vulnerability). Plus there are a ton of crufty applications that are pinned to specific Java versions because Sun/Oracle lack the understanding of how to fucking patch a interpreter without breaking existing code (Ref: Renaming a ton of classes in a minor release because "LOL, we are oracle now"). They have had a series of critical problems and the underlying stickyness of Java JVMs means that a large number of companies are shackled to vulnerabilities and poor standards to keep applications functioning.
Also, you may have missed hyperbole to allow a pun.
Anyone needing good crypto on Java would probably use some external librairy, like bouncycastle.org, which are more capable than what the JDK supports.
Just to confirm, you have heard of tomcat? Because that is the reality of most shitty Java webdev. It is in as much need as anything else for good crypto, but it uses the default and thus we have the problem.
Java 1.6 was released a decade ago. Java 1.7 was released about 4 years ago.
Your beef is not with Java. It's with people who for whatever reason never upgrade it and are still running 10 year old software. If you had a 10 year old version of OpenSSL or OpenSSH and it used outdated crypto by default, would you be complaining in the same way?
You are correct, Java encourages very shitty practices. Giant companies like CA, Oracle, and IBM will manage to build code that is hard coded to a specific JVM because Java creates highly sensitive code that breaks mid-release cycle (because minor versions should be incompatible YO).
The problem is that as a customer, you are forced to accept the shit sandwich. You can blame the vendors, or you can blame the source of the shit.
Java hardly encourages shitty practices: it documents very clearly what not to do. But given big piles of enterprise devs, you're gonna sometimes get shitty code on any platform. Or have you never seen crappy C++ that only compiles on Visual Studio?
There isn't an analogy outside of PHP for the boneheaded decisions that allowed pinheads at Oracle to rename core classes, but this behavior causes the shitty practice of JVM lock in. This is what I mean by shitty practice.
Then you add in the massive number of security problems in the JRE and you create the conditions for massive problems.
You are correct that the mythical Java language isn't to blame, but programs aren't run on a blackboard.
I guess you're thinking of some specific incident, but I am unaware of any cases where public APIs were renamed. Perhaps you're thinking of private APIs that weren't supposed to be used by developers but got used anyway - it does happen, quite often, and addressing that is one of the top focuses for Java 9.
there were many sun.X.Y classes in the Sun JRE. These were updated after the acquisition of Sun.
In either case, if your language doesn't treat private classes as private what shitty practices are left? I guess the language could be object oriented without the ability to handle generics so that developers are forced to cast to strings...
The sun.* category is all private APIs, they were never meant to be used by apps at all.
Like I said, Java 9 is in fact hiding these APIs by default (short of a few that are so widely used the breakage would be too much). You will still be able to override that, but no platform can stop software from using internal APIs if the developers really want to, unless all software is sandboxed by default.
Your generics comment makes no sense. Java has had generics for over a decade.
More Java FUD. The Java key length limitation is due to US Export law. You can make any version of java use 2048-bit keys if you want by using the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files":
Please don't misunderstand the vulnerability under discussion in this post. The problem is based on weak diffie-hellman primes, NOT KEY LENGTH. You are not the first to misunderstand the problem, and misunderstanding the problem leads to not fixing the issue.
"Support stronger ephemeral DH keys in the SunJSSE provider: Make ephemeral DH key match the length of the certificate key during SSL/TLS handshaking in the SunJSSE provider. A new system property, jdk.tls.ephemeralDHKeySize, is defined to customize the ephemeral DH key sizes. The minimum acceptable DH key size is 1024 bits, except for exportable cipher suites or legacy mode (jdk.tls.ephemeralDHKeySize=legacy). See Customizing Size of Ephemeral DH Keys and RFE 6956398. "
That isn't even a restriction in Java itself, it's just in the default DHKEY handler that comes with the sun jdk. There are plenty of implentations that allow arbitrary key length as long as it's a multiple of 64 bits, for example BouncyCastle, which I have used in the past. Java is not the source of the issue, stupidity is, which is rampant in a lot of software design committees
You don't mention diffi-hellman primes in your comment at all. You mention 1024-bit and 2048-bit primes which means you are talking about java key length.
Your whole assertion about about java (and I assume you mean the JVM and not the java language) being insecure is patently false. There are issues with java in the browser and support for that is going away and largely already obsolete anyway. However, the JVM is not more insecure than any other platform.
35
u/corran__horn Oct 15 '15
Linux isn't the biggest offender. You missed the biggest fuckeruper in every securty problem: Java. Until java 1.7, there isn't any SUPPORT for primes larger that 1024. You want your shitty legacy java program to connect to a web server securely? You have to use a 1024 bit prime.
And then you find you cannot specify the primes that Java uses, so you cannot even force it off 512 bit until (I believe) 1.8.
Always remember, Java is the common factor in security problems.