What can an attacker do with a stolen SSL private key? What should the web admin do?

Question

What can an attacker do with a stolen website certificate and key?

What should the website admin do upon learning this?

Answer 1

Attack Vectors

If an attacker uncovers your SSL private key, you are minimally vulnerable to the following attacks:

1) Traffic Eavesdropping

To the attacker, everything being sent over SSL can be decrypted and should consequently be thought of as cleartext. This means passwords, credit card numbers, and other Personal and Private Information is vulnerable to being either harvested or leveraged against you as the attack escalates.

2) Man-In-The-Middle

Part of the reason to use an SSL certificate is to uniquely authenticate yourself to the clients connecting to your server. If the private key is stolen, a hacker can create a Man-In-the-Middle attack where data flowing either from the server-to-client or client-to-server is modified in-transit. This could be done to ask a user to reauthenticate (and thereby surrender their password), ask for a credit card number, or implant malware into file downloads.

As you can see, if someone has compromised your SSL certificate, they can quickly escalate the attack to either gain unauthorized access to your system or attack you or your users.

How to Recover

If a private key compromise is suspected, one should add the SSL Certificate to the Certificate Revocation List (CRL). This will alert other participants in the Public Key Infrastructure (PKI) that the certificate in question can no longer be trusted. In order to do this, you will usually need to login to the account you created with the Certificate Authority (CA) who issued the SSL Certificate or otherwise notify them of the suspected breach. Godaddy provides instructions for this online, as does Network Solutions.

With the SSL certificate revoked, you will need to again go through the process of generating a new certificate and private key in order to re-enable SSL services for your web site or application.

If your site has been breached, I would recommend recovering in the following steps:

1. Shutdown the compromised service. It is generally not advisable or ethical to leave yourself or your users at risk while you fix things.
2. Revoke the SSL Certificate. By adding the certificate to the CRL, you're notifying the world that it can no longer be trusted. This should be done as soon as possible.
3. Determine the cause of the Breach and Patch the Problem. It will do you no good to revoke and reissue the certificate if you don't know how you were compromised in the first place. Try to figure this out so that before you put everything back online you aren't simply compromised again. Fix the issue.
4. Generate a New SSL Certificate. As mentioned above, you'll need to generate a new certificate in order to bring things back online securely.
5. Resume Services. After you've addressed the root cause of the security breach, revoked the certificate, and generated a new cert from scratch, you should be good to bring things back online.
6. Notify Users / Stakeholders. It is considered a best practice to provide full disclosure and notify those who may have been damaged by the breach of what happened. In some industries (such as healthcare) this may even be required by law. However, at this point you should defer to corporate/government policy for specifics.

Answer 2

What can an attacker do with a stolen website certificate and key?

Attackers in possession of the private key can:

• Impersonate the website, if they are also in a position to perform an active MITM attack (i.e. alter the traffic coming from the client, so as to redirect the request to their server).

• Look inside traffic they can eavesdrop (without necessarily having to alter the traffic), if a cipher suite that doesn't provide Perfect Forward Secrecy (Ephemeral Diffie-Hellman cipher suites aim to provide PFS) is used.

What should the website admin do upon learning this?

They should contact their Certification Authority to revoke the CA, and get a new one (with a new key part). Once revoked, clients checking for revocation (via CRL or OCSP) shouldn't accept the old certificate. (Clients that do not check this will still be vulnerable, until the expiry of the certificate.)

Telling users that this incident happened isn't a bad idea, at least to encourage them to check their browsers check for revocation (and perhaps take necessary action, should they suspect some of their communication have been vulnerable).

Note that, if the attackers have recorded past communications using that certificate and that a non-PFS cipher suite was used at the time, the attackers should be able to decipher those past communications with the private key.