Decrypt SSL with Private Key

Question

If an attacker gets your SSL Private Key , what can he do with it ? can he decrypt the SSL traffic ? if yes , HOW ?
And what should the Admin do to prevent such an attack ?

Answer 1

If an adversary obtains your private key, they could:

• Execute a man-in-the-middle attack and read all traffic between client and server.
• Decrypt SSL/TLS sessions that were not established using a key exchange method that provides forward secrecy. This attack simply requires observing (or replaying previously observed) traffic on the wire. Wireshark provides an "SSL dissector" feature that, given a private key, decrypts current or recorded TLS sessions. This Stack Overflow question demonstrates how forward secrecy prevents this kind of analysis.
• Attempt to trick a certificate authority (one that is trusted by clients) into signing a certificate binding the public key to your domain name, and impersonate you directly using this certificate (provided they can cause clients to come to them using e.g. phishing, DNS poisoning, etc.)

To protect your private key:

• Always store the private key in encrypted form, using a strong cipher and strong passphrase.
• Ensure it can only be read by the processes that need to read it. Set appropriate file ownership and permissions, and consider additional Mandatory Access Control mechanisms such as SELinux to restrict which processes can access it.
• If your servers are long running, consider not storing your private key on the server host at all, as it is most likely needed only at server startup.
• If your service handles sensitive or high-value data, consider using a Hardware Security Module (HSM) for signing and decryption operations so that the private key cannot be exfiltrated.

You should also take measures to limit the impact of a key disclosure:

• Favour (or use exclsively) key agreement protocols that provide forward secrecy, so that captured sessions cannot be decrypted later if the private key is disclosed.
• Be prepared to revoke keys when you believe they may have been compromised, and deploy new certificates with new keys.
• DNSSEC can help protect against MitM and impersonation attacks (if clients use it).
• DNS-based Authentication of Named Entities (DANE), in conjunction with DNSSEC, allows you to specify the trust anchor for certificates which, if clients query and validate DANE TLSA records, protects clients from communicating with servers presenting certificates signed by other CAs.