Are there decent implementations of OpenSSL in more secure languages like Rust?
Your best middleground is LibreSSL, which is still C but is at least written by developers with huge amounts of experience writing secure C.
But it's not in a more secure language.
Also, it might be vulnerable to side-channel timing attacks: https://www.imperialviolet.org/2013/02/04/luckythirteen.html
Please stop perpetuating the myth that security is produced by a programming language. People make security happen just like they make it not happen. Obligatory Schneier: https://www.schneier.com/blog/archives/2008/03/the_security_...
All those big security issues aren't in the Java language, they are in the JVM running untrusted Java byte code. Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea.
That aside, memory safety is great for security. Of course there are 1000 other things that are important, too, and so I'd trust a C program written by a security expert much more then the same program written by someone who thinks his program is secure because he used Java. But I'd feel even better if the security expert used a memory-safe language because I am certain that all C programs above a certain size are vulnerable to memory attacks.
Yes, security issues are found in Java and every other language, but when these are patched all programs that use that language are patched against the issue. The attack surface is much smaller.
Security happens by taking care of what you're doing; if a language can eliminate a whole class of bugs then you might as well use it. That's why people keep arguing that some languages can eliminate some kind of bugs, but that absolutely doesn't make programs implemented in these languages bug-free.
Said differently: more secure (relatively) doesn't mean secure (in absolute).
> We only have to look at all the patches for java to see that it hasn't been secure.
We only have to look at all the patches for java to see how much it is analyzed; it doesn't mean java is relatively more or less secure than any other language.
I've seen no patches for this nim interpreter for brainfuck [0], does that mean it's more secure than java ? Absolutely not.
You can draw some parallel with crypto schemes: anybody can come up with some cipher, nobody will analyze it unless there is something to gain (that includes fun). When you've reached the state where you're under scrutiny of every crypto analyst and their student, and potential vulnerabilities are found, does that make it a weak scheme ? We don't know. Only a real analysis of the vulnerabilities can tell us.
Not that I know about security, but all you're doing right now is to fend off the claim of "more secure" by stating that java is not secure in an absolute sense - no one has claimed absolute security, only relatively more.
EDIT: What is the status of LibreSSL?
Last LibreSSL release was 2.1.4 last week, although a minor update should be coming soon. http://marc.info/?l=openbsd-announce&m=142543818707898&w=2
LibreSSL is going to track OpenBSD versions, so now that OpenBSD 5.7 is done, the LibreSSL 2.1.x series is done (except to receive patches). At some point a 2.2 release will be made, corresponding to new developments.
OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog vs LibreSSL: https://github.com/libressl-portable/portable/commits/master
Seems LibreSSL is a mainly a one-man band?
This is closer, and a bit busier: https://github.com/libressl-portable/openbsd
This is an exciting development.
On a side note - a lot of libs start to implement their own crypto because "OpenSSL code sux its terrible and buggy!" impression. This scares me. These won't get much exposure and will most likely be full of implementation bugs that nobody will ever review - except bad guys and the NSA.
What OpenSSL is, is a magic wand that can set up encrypted tunnels between peers that don't have pre-existing mutual key pairing, by making use of well-known X.509 certificates and the CA infrastructure. Don't try to make that kind of wand yourself; 99.999% of such wands are really misidentified Wands of +5 Foot Shooting.
[1] I rolled my own CA bundle this week, turns out I need to include 4 1024-bit certs because the endpoints I hit are chaining to them for legacy clients, and OpenSSL didn't understand to stop when it got to a cert it knew until 1.0.2 which was released in January. Given what happened the last time I upgraded OpenSSL versions, I'm not inclined to upgrade right away. Seriously, the week after we upgraded to OpenSSL 1.0.1, heartbleed came out; serves us right for wanting to support TLS 1.1 and 1.2 and PFS.
I don't think they'd do that - it's be far easier to grab libressl or boringssl. If you're aware that openssl is buggy, you're probably aware that writing your own crypto when you're not a cryptographer is worse.
http://veridicalsystems.com/blog/of-money-responsibility-and...
> OSF typically receives about US$2000 a year in outright donations and sells commercial software support contracts and does both hourly rate and fixed price “work-for-hire” consulting as shown on the OSF web site. The media have noted that in the five years since it was created OSF has never taken in over $1 million in gross revenues annually.
They were only getting about $2,000 a year and had one active developer.
[1] http://arstechnica.com/information-technology/2014/04/tech-g...
Regarding SSL, I just generally consider it borked and try not to trust it if possible. SSH/VPN are just about the only thing I do trust (and even then with trepidation).
Once again, I think the many eyes theory only works when the code is sufficiently simple/terse. I bet if you did a study on lines of code in proportion to security vulnerabilities you would find a correlation (obviously not necessarily a causation).
