STARTTLS Everywhere

Yan Zhu and Jacob Hoffman-Andrews. PasswordsCon 2014.

Transcript

1. STARTTLS Everywhere Peter Eckersley, Jacob Hoffman-Andrews, Yan Zhu Electronic Frontier Foundation {pde, jsha,yan}@eff.org
2. SMTP email transmission is mostly insecure
3. ngrep -i password tcp port 25
6. Threat model 1. passive attackers 2. passive attacks w/ key compromise 3. active attackers 4. sophisticated active attacks
7. Threat model 1. passive attackers turn on STARTTLS 2. passive attacks w/ key compromise 3. active attackers 4. sophisticated active attacks
11. STARTTLS in/out of Gmail
12. It'd be nice to stretch that graph further back in time https://github.com/EFForg/smtp-tls-history. git Email pde@eff.org if you'd like to run that on a large set of historical headers
13. 2. passive attacks w/ sophisticated assistance (key theft)
14. What's the easiest way for eavesdroppers to read billions of encrypted email transfers?
15. Session key 1 Session key 2 Session key 3 Session key 4 Normal TLS: session keys linked to long-term private keys Sender's public key Receiver's public key
16. ...steal the private keys Image: betty le bon
17. Session key 1 Session key 2 Session key 3 Session key 4 “Perfect” Forward Secrecy: Extra crypto unbinds session keys from private keys Sender's public key Receiver's public key ECD H ECD H
18. How do we turn on Perfect Forward Secrecy correctly for SMTP?
19. Simple answer: - support TLS v1.2 - protect against downgrade attacks
20. Need a new policy mechanism to do that!
21. 3. active network attacks
22. Unfortunately, active attacks are really easy...
23. How does SMTP-TLS work?
24. One side say “STARTTLS”, the other replies “STARTTLS”
26. The sender will fall back to insecure SMTP
27. Attackers can also “man in the middle”, speaking TLS themselves
28. Source: Facebook, May 2014
29. Threat model 1. passive attackers turn on STARTTLS 2. passive attacks w/ key compromise 3. active attackers ??? 4. sophisticated active attacks
30. On the Web, we have the HSTS header for this
31. A quick pragmatic solution: STARTTLS Everywhere
32. git clone https://github.com/EFForg/starttls-everywhere.git
33. Main concepts: - Recipient security policy framework - Supports missing functionality - Start with a centralized database - Multi-channel distribution
34. Related work DANE: fully distributed, uses DNSSEC SPF: Applies to senders, not receivers
35. Scenario 1 (prototype, work in progress) git clone https://github.com/EFForg/starttls-everywhere.git # Run our script, which does: while sleep 1d ; do git pull git tag --verify $LATEST_VERSION || exit ./MTAConfigGenerator.py --edit /etc/postfix ./FailureNotificationDaemon.py & done
36. Scenario 2 (common unix MTAs) apt-get install starttls-everywhere
37. Scenario 3 (large scale production) wget https://eff.org/starttls-everywhere/latest-db.json wget https://eff.org/starttls-everywhere/latest-db.sig gpg --verify latest-db.sig latest-db.json || error-script MTAConfigGenerator.py latest-db.json -o mta-policy.cf your-deploy-script mta-policy.cf
38. Policy database is a set of JSON blobs:
39. // These match on the MX domain. "*.yahoodns.net": { "require-valid-certificate": true, } "*.eff.org": { "require-tls": true, "min-tls-version": "TLSv1.1", "enforce-mode": "enforce" "accept-spki-hashes": [ "sha1/5R0zeLx7EWRxqw6HRlgCRxNLHDo=", "sha1/YlrkMlC6C4SJRZSVyRvnvoJ+8eM=" ] } "*.google.com": { "require-valid-certificate": true, "min-tls-version": "TLSv1.1", "enforce-mode": "log-only", "error-notification": "https://google.com/post/reports/here" }, } // Since the MX lookup is not secure, we list valid responses for each // address domain, to protect against DNS spoofing. "acceptable-mxs": { "yahoo.com": { "accept-mx-domains": ["*.yahoodns.net"] } "gmail.com": { "accept-mx-domains": [”*.gmail.com”, "*.google.com", ”*.googlemail.com”] # hypothetical }
40. demo time! https://eff.org/starttls
41. https://eff.org/join https://eff.org/starttls EFF depends on your support!