2

I run a server whose only public open port is 80, serving non-encrypted data over HTTP, not HTTPS. Is it affected by Heartbleed?

Lekensteyn
  • 5,898
  • 5
  • 37
  • 62
jl6
  • 625
  • 4
  • 9

2 Answers2

3

Teun Vink is right, it's not vulnerable if you are certain that https is turned off, for example by turning mod_ssl off.

Even if you don't actively use https, it may still be enabled. Many servers have https enabled by default with some automatically generated certificate. This will not be valid and throw an error or warning in browsers, but it will still be exploitable.

If you can modify the apache configuration, disable mod_ssl with a2dismod ssl. On Windows I'm not sure this works; for example in a xampp installation you should edit the httpd.conf file in the xampp/apache/conf folder. Put a pound sign (#) in front of the line that says
LoadModule <something_with_ssl> so it becomes #LoadModule <something_with_ssl>

If disabling mod_ssl causes problems in other parts of the configuration, you can also simply make sure that the only Listen option is for port 80. You should search in all configuration files for those Listen options, for example with grep or on Windows you could use Notepad++' search in files feature.

In any case, it's advisable to update OpenSSL if possible. Other stuff may be using it, or someone may turn https on in the future without realizing that it's vulnerable.

TL;DR: Update OpenSSL if at all possible, even if you are not vulnerable. If not possible, make absolutely certain you're not using https.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • I think it's worth a bit more detail about why the question itself is flawed. The whole purpose of OpenSSL is to encrypt traffic. The heartbleed bug defeats that encryption. So, if you are knowingly running traffic unencrypted to port 80, you have already made the choice that the security of that data isn't important. Even with this bug, OpenSSL requires an attacker to be savvy enough to craft malicious heartbeat packets, and make sense of the memory dump that comes back. With plain HTTP, all you need is wireshark or some other traffic sniffer. – David Apr 11 '14 at 15:37
  • 1
    @David, Actually, I think your comment is flawed :P. What you're saying is: "even with this bug, an attacker needs to be savvy enough to exploit it, whereas http can always be read in plaintext". There is a huge distinction here: with this bug you can read *anyone's* data from the RAM if you get a bit lucky, even the server's (i.e. its private key). With http you can only read the data from whomever's network traffic you can see. If http was equal to the heartbleed bug, we'd have banned plain http a long, long time ago (though, for different reasons, we should, and are in http v2.0). – Luc Apr 11 '14 at 15:41
  • Hah, agreed. That second part was poorly worded. Although, conceivably if you are sniffing plain text creds, you can access the app with those, and then it becomes much easier to find other exploits within the app that may lead to root access. Taking those few extra steps in my contrived example, then I'm back to arguing that you're worse off using http than if you're running https with the heartbleed bug. In truth, either scenario is awful if you're a sysadmin / app owner / business owner :P – David Apr 11 '14 at 21:24
  • @David Hmm, I'm not sure heartbleed+ssl/tls is better than no ssl/tls at all... I have first hand experience exploiting both and you're right that they're both awful, but the impact of http is usually much lower. Of course in different situations things might be different, but generally I think you're much better off disabling https altogether if the alternative is to leave it vulnerable. – Luc Apr 11 '14 at 22:56
  • Agreed. I admit defeat :) – David Apr 22 '14 at 19:10
2

No it's not. Heartbleed is an OpenSSL vulnerability, no OpenSSL is used for HTTP.

Teun Vink
  • 6,788
  • 2
  • 27
  • 35