The document discusses forward secrecy in encrypted communications. It explains that forward secrecy uses ephemeral keys for each session so that compromising a server's private key at a later date would not allow decryption of past encrypted sessions. It provides examples of Google, Twitter, and Apple implementing forward secrecy by using protocols like elliptic curve Diffie-Hellman key exchange that provide forward secrecy and help protect encrypted data even if server keys are lost or stolen in the future.

1. Forward Secrecy
Kevin O’Brien
Washtenaw Linux Users Group

2. Encrypted Communication
● Most examples involve Alice and Bob trying to
communicate securely
● This is not the actual most common use case
● Most of the time, we as individuals want to exchange
messages with servers on the Internet
● This generally involves both Diffie-Hellman and a public
key method such as RSA

3. Example
● I want a secure connection to my bank, and my messages
are traveling over the public Internet
● I cannot rule out someone eavesdropping on my
messages
● If my connection is not secure, they could get my
password to the bank site and steal all of my money

4. Secure Connections
● Ideally, my bank offers a secure connection by default (if
not, get a better bank!)
● This is usually seen as a URL the begins https, instead of
the old standby http
● This should denote at the very least an ssl connection,
though TLS is preferred these days
● I also have https everywhere installed, which I can get
from the Electronic Frontier Foundation
● https://www.eff.org/https-everywhere

5. Negotiation
● Whether the site offers a secure connection by default, or
offers it because my browser plug-in asked for one, this is
the beginning of a negotiation
● Which security protocols does the server have available?
● Which one does my browser have?
● What is the strongest protocol we have in common?

6. The opening bid
● This is the start
● I initiate the connection
● Amazon has not, AFAIK, ever just logged me in and then
asked if I need anything today (though if they figure out
how to do that…)
● I do it with what is called the ClientHello Message

7. The ClientHello Message
● This will look something like this:
● TLS_DHE_RSA_WITH_AES_256_CBC_SHA
● Every piece means something
● Again, this is something I am sending to the server

8. Interpretation 1
● TLS = establish a TLS (i.e. Transport Layer Security)
connection
● DHE = using Diffie-Hellman Ephemeral (for the shared
secret used for the session)
● RSA = combined with RSA (the public key protocol used to
create the secure initial connection
● WITH_AES_256 = using Advanced Encryption Standard
(AES) with 256 bits

9. Interpretation 2
● CBC = using Cipher Block Chaining (CBC)
● SHA = and using the Secure Hashing Algorithm (SHA)

10. Negotiation
● This should represent the highest level of security my
browser is capable of handling
● There have been security attacks that worked by forcing a
connection at a very low level of security, such as the
POODLE attack
● https://en.wikipedia.org/wiki/POODLE
● This is one reason why SSL has been deprecated in favor
of TLS, which won’t allow downgrade attacks

11. The ServerHello Message
● The server then responds with its own message, which will
either accept my proposal, or fail and propose something
different
● Once there is an agreed protocol, the server will send two
things
– A certificate containing the public key of the server,
which serves to authenticate it
– A random 32 byte number which will be used for the
Diffie-Hellman Key Exchange
– Note that these are sent publicly

12. Key Exchange
● Now the client (me) creates its own random number,
encrypts it using the public key of the server, and sends it
to the server
● The server decrypts the message using its private key, and
reads the number
● Each side now has a random secret number from the other
side, and a Diffie-Hellman Key Exchange is done

13. Negotiations Completed
● Now that there is a shared secret key, there is a Change
Cipher Spec message that switches from the Public Key to
the shared Diffie-Hellman key
● This is used for the rest of the communication

14. How Secure?
● Diffie-Hellman is known to be secure against
eavesdropping, particularly if a strong Elliptic Curve
algorithm is employed
● The use of a certificate with a Public Key (perhaps using
RSA) makes it more difficult to execute a man-in-the-
middle attack
● That can happen, though, if someone can get in the middle
at the right moment and set up communications with both
sides using its own keys

15. Man-in-the-middle
● I send a ClientHello message to my bank, but just my darn
luck, Mallory intercepts my ClientHello
● She in turn sends a ClientHello to my bank, and get back the
certificate
● She then creates her own certificate, and send it to me (I am
expecting a certificate, after all)
● She can sit in the middle passing messages back and forth
while decrypting and reading them
● In the US, companies have the right to do this on their
networks (though we hope not to clean out your account)

16. Securing this
● Number one, pay attention to the certificates. At least that
way you’ll know if someone is getting in the middle.
● Measures like OCSP Stapling make this type of attack
much harder to do
● TLS also provides improved authentication
● HTTP Public Key Pinning
● DNSSEC

17. End Points?
● Man-in-the-middle attacks are aimed at data in transit
● What about the end points?
● I have some control over my own computer
● But what about the server?

18. Server Control
● Servers can fall to malicious cracking
● Servers can be seized by law enforcement
● Possible keys can be taken from the server and used to
decrypt communications
● There is a reason governments are starting to insist that
companies keep e-mail servers for their citizens within the
country, and it is not for your protection

19. Lost Control
● I might not care if it is only my order of specialty teas from
Amazon
● But it might be confidential e-mails
● And if messages are kept for future decryption…
● NSA has a facility that appears to be for that exact purpose
● So even if the data is secure for now, will it be secure in
the future?

20. Forward Secrecy
● Some call it Perfect Forward Secrecy, but it is not perfect
● Remember, this is an arms race
● And in security perfection is very hard to find
● Any encrypted message can be brute force decrypted
given enough time and resources
● And with improvements in decryption (e.g. quantum
computing) it will take less time and fewer resources

21. What can you do?
● Forward Secrecy is essentially key protection
● This is done by using new keys for every session
● So even if someone cracked your e-mail written on
January 9, it would not help with your e-mail written
January 10
● Nor would it help with your web browsing on January 9

22. How It Can Fail
● This requires that keys are not stored, but discarded after
use
● How can you be sure?
● Incompetence happens a lot with servers
● Remember those governments and the e-mail servers?

23. O’Brien’s First Law
Every government, by its
very nature, regards the
security and privacy of its
citizens as a flaw which it
seeks to remedy by all
possible means.

24. Still, A Step Forward
● Being used by more companies
● Google
● Twitter
● Apple
● And others

25. Google
Adam Langley from the Security Team posted a
notice on their Security Blog on November 22, 2011
called Protecting data for the long term with forward
secrecy. In this short blog post he mentions that
Google “support(s) forward secrecy using elliptic
curve Diffie-Hellman”.
https://security.googleblog.com/2011/11/prot
ecting-data-for-long-term-with.html

26. Twitter
On November 22, 2013, Twitter announced in its blog under the heading
Forward Secrecy at Twitter that they would also be using forward secrecy, and
similarly said the following:
There are two main categories of Diffie-Hellman key exchange. Traditional Diffie-
Hellman (DHE) depends on the hardness of the Discrete Logarithm Problem and
uses significantly more CPU than RSA, the most common key exchange used in
SSL. Elliptic Curve Diffie-Hellman (ECDHE) is only a little more expensive than
RSA for an equivalent security level. Vincent Bernat (@vince2_) benchmarked
ECDHE at a 15% overhead relative to RSA over 2048-bit keys. DHE, by
comparison, used 310% more CPU than RSA.
https://blog.twitter.com/engineering/en_us/a/
2013/forward-secrecy-at-twitter.html

27. Apple
Apple published a specification called App Transport Security that is now
mandatory for all apps. It has several provisions, but one of them involves
forward security. In an article from the SSL store there is a good description
of this provision:
ATS also requires the use of TLS 1.2 and a cipher suite that provides
forward secrecy. Developers will need to ensure their server is configured
properly. TLS 1.2 is the most recent version of the SSL/TLS protocol, and
most modern servers have it turned on by default. Forward secrecy refers
to the way that connections are encrypted. An encryption cipher which
supports forward secrecy, like ECDHE, is able to offer security to past
sessions even if the private key is compromised.
https://www.thesslstore.com/blog/apple-will-require-use-ats-2017/