Prior to Heartbleed you were protected. Now (unless the service used perfect forward) security the agencies can decrypt all your communications done under the old key (which usually means in the past 2 years).
If you aren't using perfect forward secrecy, then presumably you don't care about that. If you do care about that, then you must use perfect forward secrecy.
I doubt that PFS will protect against the aforementioned parties, though.
If you aren't using perfect forward secrecy, then presumably you don't care about that. If you do care about that, then you must use perfect forward secrecy.
Unfortunately, I think "you" that is affected by this and the "you" that needs to care enough to deploy PFS are two different people. And I suspect that in 99.999% cases the you that cares doesn't know about PFS or how to check if their service uses it.
I had to Google it, and knowing to look for "ECDHE" or "DHE" in the certificate information isn't something many would know.
I ordered something online yesterday, and checked the cipher settings. Turns out my bank doesn't have PFS, and a well-known French payment provider (Paybox) even uses the insecure RC4 cipher.
If the browsers let users who click on the padlock know that it's insecure, the providers would have an incentive to upgrade.
PFS is nothing new, IPsec introduced it in RFC 2412 (November 1998). Benefits of using PFS have been clear since that. Also SSLv3 supports PFS cipher suites. But just as usual, even if something is available, it doesn't mean it's generally adpoted for extended use.
If you aren't using perfect forward secrecy, then presumably you don't care about that. If you do care about that, then you must use perfect forward secrecy.
I doubt that PFS will protect against the aforementioned parties, though.