Worse, it's retroactively unfixable: Even doing all this [revoking certs, new secret keys, new certificates] will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption.
So it would be a good idea to change all your passwords to critical services like email and banks, once they have issued new certs and updated their openssl.
That's slightly misleading. Every private key disclosure leads to decryption of past traffic unless forward secrecy is used.
However, if you switch to a fixed version of OpenSSL now, then an attacker cannot retroactively exploit this bug even if they have recorded all your past traffic, because exploiting the bug requires a live connection.
(Of course, this only applies to attackers who did not know about the bug before it was publicly released, so some worry is still justified. I only wanted to point out that the "retroactively unfixable" is a misleading exaggeration.)
I think what was meant is that since exploiting this bug leaves no trace, you should automatically consider every master key ever loaded to a vulnerable OpenSSL application to be already compromised. As nothing says this is the first discovery of the bug, one should consider that the black hats have already been exploiting this for long before the first public disclosure.
Yes, but there are other ways to compromise TLS sessions. For example, if you're using session tickets, the ticket key could be in RAM. Or, the session master keys themselves could be leaked. Still, you're _much_ better off with Forward Secrecy -- in most cases keys ticket keys are rotated with server restarts; so are session master keys.
I was thinking of the scenario of old traffic being recorded by someone. Unless they also extracted the session key at that time, that traffic should be secure if PFC was enabled even if someone where to extract the server key now.
So it would be a good idea to change all your passwords to critical services like email and banks, once they have issued new certs and updated their openssl.