2

*I'd like to ask about two scenarios where a vulnerable version of OpenSSL is installed on a server, but that server is not providing SSL services.

Scenario 1: I have an SSL certificate installed on a load balancer, behind which sits a farm of IIS servers. IIS is unaffected by Heartbleed and port 443 is switched off there. But we discover that the load balancer is vulnerable. What aspects of Heartbleed will impact us?

Scenario 2: In this scenario, the load balancer is NOT vulnerable. Again, the load balancer has the certificate installed. But, behind it sits a farm of servers running PHP, with a vulnerable version of OpenSSL installed and enabled -- possibly because another extension requires it or someone enabled it without thinking. Port 443 is switched off on these servers as well. What aspects of Heartbleed will impact us?

Based on my understanding, in Scenario 1 our keys and data going over the wire to/from the servers is at risk of being intercepted. However, the contents of the IIS application server memory would not be at risk for being exposed.

Again, based on my understanding, which could be wrong, in Scenario 2, there is no risk.

Can someone verify or correct my assumptions?

Brian Colavito
  • 123
  • 4
  • in scenario 2, what does "installed and enabled" mean, if not "listening on 443 with `SSLEngine on`"? –  Apr 10 '14 at 16:06
  • @WumpusQ.Wumbley meaning specifically php.ini has an uncommented line extension=php_openssl.dll or extension=php_openssl.so – Brian Colavito Apr 10 '14 at 16:22
  • OK, now that I know this was a php-specific meaning of "enabled"... a quick look at the [documentation for php_openssl](http://www.php.net/manual/en/book.openssl.php) it seems to provide mostly certificate-manipulating functions for use by php applications. I don't see any functions in the list that would actually make use of the SSL/TLS protocol. –  Apr 10 '14 at 16:45
  • Honestly I was struggling a bit to formulate that second scenario. The scenario/assumption I was going for was: some "thing", doesn't matter what, is behind the load balancer and, if accessed directly, would be vulnerable to heartbleed. However, sitting behind the immune load balancer would protect that "thing." Seems the AE confirms this assumption. – Brian Colavito Apr 10 '14 at 17:56

1 Answers1

6

Heartbleed allows memory to be exposed from the server on which [a vulnerable version of] OpenSSL is running, during a TLS connection. So, for heartbleed to be exploitable, a server must both be running a vulnerable version of OpenSSL AND accept TLS connections.

Therefore, in Scenario 1, you'd be at risk of having the memory of your load balancer being exposed, as it is the server running OpenSSL.

In scenario 2, assuming your scenario is set up such that a TLS connection cannot be made to these servers, nothing is vulnerable. A TLS connection cannot be established, so the vulnerable versions of OpenSSL are not exploitable.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • And the contents of the memory of the load balancer may include the private key of the SSL certificate, so the certificate should be reissued in Scenario 1. – Grant Apr 10 '14 at 16:07
  • @Grant that actually depends on a number of factors... it's been discovered that in some configurations, such as a Linux server behind an NGIX reverse proxy, the private key is never in memory that's accessible to non-root users, so it's not possible to expose. – HopelessN00b Apr 10 '14 at 16:09
  • 1
    This likely is why grant says "may be" ;) I wuold generally reissue all certificates. – TomTom Apr 10 '14 at 16:28
  • @HopelessN00b Really? Do you have a cite for that? We run nginx in that configuration in almost every case. – cjc Apr 10 '14 at 16:35
  • 1
    @cjc Comes from Cloudflare's security team, but I can't find where I read that originally, [but there's a Wired article alluding to it here](http://www.wired.com/2014/04/nsa-heartbleed/), and I'm not sure what NGINX configurations their findings are limited to. Like TomTom says, the safest course is to reissue all certificates, but if that's not an option, there may be some hope that your private keys aren't extractable... test, test, test and test s'more to be sure, of course. – HopelessN00b Apr 10 '14 at 16:43
  • @hopelessnoob that is indeed why I said may include. Getting a cert reissued and installed may take a few hours, but a comprimised key can make you vulnerable for years to come. – Grant Apr 10 '14 at 19:53