*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?
Answer
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.
No comments:
Post a Comment