STARTTLS Everywhere Peter Eckersley, Jacob Hoffman-Andrews, Yan Zhu Electronic Frontier Foundation {pde, jsha,yan}@eff.org 

SMTP email transmission is mostly insecure 

ngrep -i password tcp port 25 

No content

No content

Threat model 1. passive attackers 2. passive attacks w/ key compromise 3. active attackers 4. sophisticated active attacks 

Threat model 1. passive attackers turn on STARTTLS 2. passive attacks w/ key compromise 3. active attackers 4. sophisticated active attacks 

No content

No content

No content

STARTTLS in/out of Gmail 

It'd be nice to stretch that graph further back in time https://github.com/EFForg/smtp-tls-history. git Email [email protected] if you'd like to run that on a large set of historical headers 

2. passive attacks w/ sophisticated assistance (key theft) 

What's the easiest way for eavesdroppers to read billions of encrypted email transfers? 

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 

...steal the private keys Image: betty le bon 

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 

How do we turn on Perfect Forward Secrecy correctly for SMTP? 

Simple answer: - support TLS v1.2 - protect against downgrade attacks 

Need a new policy mechanism to do that! 

3. active network attacks 

Unfortunately, active attacks are really easy... 

How does SMTP-TLS work? 

One side say “STARTTLS”, the other replies “STARTTLS” 

No content

The sender will fall back to insecure SMTP 

Attackers can also “man in the middle”, speaking TLS themselves 

Source: Facebook, May 2014 

Threat model 1. passive attackers turn on STARTTLS 2. passive attacks w/ key compromise 3. active attackers ??? 4. sophisticated active attacks 

On the Web, we have the HSTS header for this 

A quick pragmatic solution: STARTTLS Everywhere 

git clone https://github.com/EFForg/starttls-everywhere.git 

Main concepts: - Recipient security policy framework - Supports missing functionality - Start with a centralized database - Multi-channel distribution 

Related work DANE: fully distributed, uses DNSSEC SPF: Applies to senders, not receivers 

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 

Scenario 2 (common unix MTAs) apt-get install starttls-everywhere 

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 

Policy database is a set of JSON blobs: 

// 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 } 

demo time! https://eff.org/starttls 

https://eff.org/join https://eff.org/starttls EFF depends on your support! 

No content