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?

Improve this question
4
  • in scenario 2, what does "installed and enabled" mean, if not "listening on 443 with SSLEngine on"?
    – user193597
    Apr 10, 2014 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, 2014 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 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.
    – user193597
    Apr 10, 2014 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, 2014 at 17:56

1 Answer 1

Reset to default
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.

Improve this answer
6
  • 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, 2014 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, 2014 at 16:09
  • 1
    This likely is why grant says "may be" ;) I wuold generally reissue all certificates.
    – TomTom
    Apr 10, 2014 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, 2014 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, 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, 2014 at 16:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .