End users should just wait until their sysadmins contact them with further instructions. At some point, after your sysadmins have patched to OpenSSL 1.0.1g, expect to have to:

• Change all passwords
• Login again to all services (because all session keys and cookies need to be invalidated)
• Help senior management evaluate the actual content handled by the vulnerable servers that could have been leaked, and react accordingly.

I expect that the massive key/certificate changes about to occur will go un-noticed by most users, as those take place server-side. As to the client-side root CA trusted certs, I expect that the private key counterparts will reside on air-gapped systems, and so won't have been vulnerable to this exploit. Any updates to certificate stores that are necessary will probably just occur transparently in background updates.

I summarized the bullet points above from heartbleed.com (emphasis mine):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

End users should just wait until their sysadmins contact them with further instructions. At some point, after your sysadmins have patched vulnerable systems, you may have to:

• Change passwords
• Login again (because all session keys and cookies need to be invalidated)
• Help senior management evaluate the actual content handled by the vulnerable servers that could have been leaked, and react accordingly.

I expect that the massive key/certificate changes about to occur will go un-noticed by most users, as those take place server-side. As to the client-side root CA trusted certs, I expect that the private key counterparts will reside on air-gapped systems, and so won't have been vulnerable to this exploit. Any updates to certificate stores that are necessary will probably just occur transparently in background updates.

I summarized the bullet points above from heartbleed.com (emphasis mine):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

End users should just wait until their sysadmins contact them with further instructions. At some point, after your sysadmins have patched to OpenSSL 1.0.1g, expect to have to:

• Change all passwords
• Login again to all services (because all session keys and cookies need to be invalidated)
• Help senior management evaluate the actual content handled by the vulnerable servers that could have been leaked, and react accordingly.

I expect that the massive key/certificate changes about to occur will go un-noticed by most users, as those take place server-side. As to the client-side root CA trusted certs, I expect that the private key counterparts will reside on air-gapped systems, and so won't have been vulnerable to this exploit. Any updates to certificate stores that are necessary will probably just occur transparently in background updates.

Summarized from heartbleed.com (emphasis mine):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

End users should just wait until their sysadmins contact them with further instructions. At some point, after your sysadmins have patched to OpenSSL 1.0.1g, expect to have to:

• Change all passwords
• Login again to all services (because all session keys and cookies need to be invalidated)
• Help senior management evaluate the actual content handled by the vulnerable servers that could have been leaked, and react accordingly.

I expect that the massive key/certificate changes about to occur will go un-noticed by most users, as those take place server-side. As to the client-side root CA trusted certs, I expect that the private key counterparts will reside on air-gapped systems, and so won't have been vulnerable to this exploit. Any updates to certificate stores that are necessary will probably just occur transparently in background updates.

I summarized the bullet points above from heartbleed.com (emphasis mine):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.