Is OpenSSL secure enough?

Question

We plan in distribute Node.JS webservers, for their advantage of async I/O. The Node.JS https servers use OpenSSL libraries.

It appears that OpenSSL has vulnerabilities resolved on a regular basis. This makes me wonder if I should move the SSL layer to a separate Java process / something more proven, that will not have buffer overflow, and other vulnerabilities.

The Oracle Solaris package repo publishes only an out of date release, so compilation from source would be necessary for prompt install.

There would of course be a delay between discovery->release->compilation->distribution to the servers running. And additional administration cost/delay in the event there is a problem with the build.

• How effective will prompt updates be against attackers? What kind of work would be necessary for the attacker, once a vulnerability is identified?
• Do you recommend an alternative, more secure approach to installing the https layer?
• Is there an older, more stable version of OpenSSL that is still maintained, and had a longer time to be proven secure?

Any input would be appreciated, including help with getting this question right.

Edit: A couple clarifications on how a separate library would be introduced, if that was to happen: The separate library would just be an implementation of a proxy https server, in a separate process. This is a brand-new implementation, so we wouldn't be switching, we would instead just 'not use' the Node.JS https server library.

Answer 1

The fact that they are constantly making changes to improve security is a good thing. It means they are keeping up with exploits and patching accordingly. This is the kind of thing you want to see in a security library. Just because a library isn't patched often, doesn't mean that they don't have any problems. It might just mean that they aren't fixing them quickly or often enough.

As for the library itself, it seems fairly widely used, so I think you will be safe using the most recent version of it. Using different libraries seems like it will introduce a lot of complications to your build and upgrade process (which itself can cause security problems), and you probably aren't going to be gaining a lot of security by switching.

Answer 2

Another option is off-loading the SSL computation to a reverse-proxy like Pound. I've used Pound in the past and found it very easy to use. I've only used it for traditional web sites, so I don't know if it will work for you.

A nice thing about Pound is you can roughly load balance by configuring multiple back-ends.

Answer 3

It is conceptually feasible to have a SSL implementation which is free of buffer overflows: it suffices to use a programming language which forcibly prevents buffer overflows. For instance, an SSL implementation entirely in Java. The Java virtual machine systematically checks array bounds before performing an array access; therefore, no buffers will truly overflow. Instead, an exception is thrown, interrupting the offending thread. The net effect is that, in case of a bug where a buffer would have been overflown, the attacker does not gain a remote shell (but the server thread still crashes).

A pure Java cryptographic library exists called bouncycastle. Other Stackexchange answers refer to it including, perhaps usefully, one on TLS connections.

Google also finds this, but, unfortunately, it seems to be an old, stalled project which relies on some external libraries for certificate handling, and these external libraries are not in pure Java; and OpenSSL bugs tend to be in that part anyway.