2

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.

|improve this question
  • 1
    The Solaris support package repo has newer releases of OpenSSL packages, but those are only available to customers with a current support contract. – alanc Aug 19 '12 at 1:43
  • 1 word: heartbleed. – William Edwards Sep 20 '14 at 13:56
7

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.

|improve this answer
1

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.

|improve this answer
  • Excellent suggestion, great find, but it is worth noting that according to their website, Pound uses OpenSSL. It can run in a chroot environment, but if I am not mistaken, then theoretically, with a vulnerability in OpenSSL, even a Pound implementation could be made to intercept all the HTTP activity that is generated from the HTTPS requests. – Bryan Field Jun 4 '12 at 18:48
  • Sure, but you've now segmented your services and also have a way to upgrade SSL without requiring you to upgrade your application. – Bradley Kreider Jun 4 '12 at 18:52
  • Great point, it can be a useful way to separate and simplify upgrades. – Bryan Field Jun 4 '12 at 18:53
  • Putting a threaded reerse proxy in front of en event based server is rather silly - ATS (trafficserver.apache.org) or Stud (vincent.bernat.im/en/blog/2011-ssl-benchmark.html) would make a lot more sense if you explicitly want to seperate the openSSL from the webserver (but running it in the webserver is more efficient) – symcbean Jan 6 '13 at 23:39
0

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.

|improve this answer
  • 1
    Not all security errors in SSL implementations are caused by buffer overflows: side-channel attacks on cryptographic functions (which might be a lot more difficult to avoid in pure Java code, especially timing attacks) and logical errors in the protocol implementation are more likely to cause security issues than the fact that the library is not implemented in a memory-safe language. – AardvarkSoup Jan 6 '13 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.