This is answered in many places on ye olde interwebbe, but a lot of them are rubbish, or are hiding behind some very terrible web design / advertisements, or both. I aggregated the information from a few different videos (shoutout Computerphile!) and some articles as part of a homework assignment, so I thought I would reproduce it here. Full list of resources is copied at the bottom of the post.
This writeup assumes you know what a client and server is, and care, but if you do not then you can think of the client as anything that sends a request, and a server as anything that sends a response (or 'serves' a response). The confusing thing about the terms is that the roles in a transaction can change: clients can become servers, and servers can become clients. Confused yet? Cool. All you need to know is that one thing is calling another thing, and you don't want anyone to be able to listen in on their chat. The thing that makes the initial call? That's the client. The thing that responds? Server.
Enjoy(?).
Summary
Perfect Forward Secrecy enables you to support secure, encrypted communication between clients and servers in your environment, and reduce your risk in the event that any of your servers is compromised. Unlike typical RSA public/private key encryption, cipher suites that use PFS protect you if your server(s) are hacked and the server encryption keys are exposed.
Consider an Electronic Medical Record system that uses typical (TLS 1.2) RSA key exchange now in wide adoption. The EMR system servers encrypt all message traffic using a public and private key pair; the private key is unique to each server. The message traffic in the EMR system includes records and patient data for tens of thousands of patients, across years of medical history. If the private key for any server is compromised then a hacker may be able to use it to gain access to all of the data on that server: medical data, patient data, and the entire message history.
Now consider an EMR system that incorporates Perfect Forward Secrecy. In PFS there is no link between a server’s private key and the session key, so in the event a private key is compromised then a hacker cannot uncover the session key and decrypt the conversation. Also, if attackers are somehow able to compromise the session key they are only able to decrypt the conversation for that particular session; your conversation history is protected, because perfect forward secrecy forces a new session for each message.
In this example the result of a breach caused by a decrypted session key in a system that integrates PFS is the exposure of a single message. The result of a breach caused by the loss of a private key in a system protected by RSA key exchange is the contents of an entire server.
Benefits
You can use PFS to dramatically reduce the amount of information that is vulnerable in the event of a successful hack, and to deter attacks because the rewards in the event of a breach are minimal. Adopting cipher suites that integrate PFS enables you to stay compliant with the latest and most up-to-date traffic security requirements (for example, Google has enforced PFS by default in Gmail since 2011, and Apple has required PFS support for all new apps in the app store since January 2017).
Drawbacks
Perfect Forward Secrecy forces end to end encryption. If your monitoring solution requires that your messages be inspected then you must incorporate a true inline SSL proxy in order to read them. Passive SSL inspection devices that rely on certificate information, subject alternative name (SAN), or common name/hostname (CN), will not be able to decrypt or inspect any traffic protected by PFS.
Supporting PFS requires more computing overhead, because every transaction requires a unique security key. Also, legacy systems may not support the cipher suite keys required for PFS.
Why Should I Care?
PFS can be implemented today if you use a cipher suite key exchange that supports it (i.e. Diffie-Hellman Ephemeral - DHE, or Elliptic Curve Diffie-Hellman Ephemeral - ECDHE). These cyphers have been available since SSLv3, but it is best to implement the latest and most secure protocol supported by your environment, and to evaluate your security posture if your legacy systems do not support PFS.
The latest Transport Layer Security standard (1.3) mandates PFS for all sessions. In other words, if you want to use the most up to date security protocols for your internet traffic, you must use perfect forward secrecy.
For example, Zscaler supports TLS 1.3 and PFS because it is a true inline proxy: it terminates the SSL connection established by the client and establishes a new SSL connection to the server. You can inspect your traffic and ensure that your network exploits the latest, most robust security standards available.
///
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment