...yes they are. You don't even need remote private key disclosure to MITM an http-only server. The way HTTP digest is written means you either store all passwords in a retrievable form or drop down to basic auth where anyone capable of base64 decoding can read all passwords.
This situation is by no means worse than if everyone had just used plain HTTP.
- With plain HTTP, the attacker would have to be in a MITM position to intercept traffic. With Heartblead, he can read traffic he wouldn't normally have access to from the server's memory.
- There may be secrets in memory that would never even be sent over the network that are now accessible. For example, if running a web app in the same process doing SSL termination, private keys such as Django's SECRET_KEY may be available. Under certain situations, knowledge of the SECRET_KEY can effect remote code execution.
In short, Heartbleed gives the entire world the ability to read memory from your server. This is much worse than an HTTP MITM.
I run an HTTP-only server that's read-only for the public. However, I have an admin interface that lets me log in and make changes to the site. For example, a WordPress blog.
Now, let's say that I run the server at home and I'm careful only to log in as an admin when on the home LAN. This is perfectly secure even though I'm only using plain HTTP.
If I decided to instead serve HTTPS, the heartbleed vulnerability means that anybody could potentially hijack my sessions, steal my passwords, and edit the site. Depending on how much password reuse is going on, they could own the entire box, or just put malicious code on the site for all my visitors to run into.