Essentially, no, there is no one way to tell the good scenarios from the bad, because your users don't have full visibility of the systems they're using.
The extent of the damage caused by the bug is still largely unknown, most of the damage was potentially done in the past and will continue to impact the internet for a long time. We just don't know what secrets were stolen, when, or by whom.
Google's OpenSSL heart bleeds for about a year. Unknown adversaries harvest the servers and look for interesting secrets - again, there is no way for us to know whether they did this or not - until they find an account belonging to someone with authorized access to another system, say Twitter.com or AnyBank.co.uk or dev.redhat.com. With access to such accounts, they could potentially keep digging, gaining access to other systems, doing other damage (visible or not), further compromising other accounts - without anyone suspecting the origin of the breach. At this stage you're already far away from the bleeding OpenSSL servers, and this is one of the nastier consequences of Heartbleed. Added to that is the risk of servers' private keys being compromised.
Trust takes a long time to build up, and can quickly be lost. I'm not saying that we didn't have trust issues on the internet before, but Heartbleed definitely didn't help. Repairing the damage will take a long time, and understanding this is part of understanding how you can protect yourself and your employees/clients/bosses etc - and how you cannot. There are some things you can control, to limit your exposure to the vulnerability, and there are things you cannot control - but they will still affect you. For example, you cannot control how everyone else decides to respond to this vulnerability - the NSA reportedly discovered the bug but kept quiet. That was pretty bad for the rest of us, but we had no way of protecting us against it.
As an internet user you can and should:
Here we come back to trust: When you lose someone's trust, that's a bad thing. Especially if that someone is your user/customer/boss. To regain their trust, you have to start building again, and open up for a dialog.
Here's what a web admin can publish to get that started:
- Previous OpenSSL version(s) (vulnerable/not vulnerable)
- Current version and when it was updated
And if the previous version of OpenSSL was vulnerable:
- When the current SSL certificate was generated
- Detailed description of how the old certificate has been revoked
- Assurance that a new secret was used for the new certificate
- Suggestions for users based on the above information
If you're a user, you have every right to ask for this kind of information, and you should, for the sake of all users of the service. This would increase the visibility for the security community, and make it easier for users to minimize their exposure to compromised servers.