Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email - - PowerPoint PPT Presentation

▶
neither snow nor rain nor mitm an empirical analysis of
SMART_READER_LITE
LIVE PREVIEW

Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email - - PowerPoint PPT Presentation

Sep 02, 2022 190 likes •528 views

Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery Security Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, Kurt Thomas, Vijay Eranti, Nicholas Lidzborski, Elie Bursztein, Michael Bailey, J. Alex

slide-1
SLIDE 1

Neither Snow Nor Rain Nor MITM... 
 An Empirical Analysis of Email Delivery Security

Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, 
 Kurt Thomas, Vijay Eranti, Nicholas Lidzborski, 
 Elie Bursztein, Michael Bailey, J. Alex Halderman University of Michigan, University of Illinois 
 Urbana-Champaign, Google

slide-2
SLIDE 2

Who am I?

I am a Ph.D. Candidate at University of Michigan. My research focuses on measurement-driven security. Developing tools for
 researchers to better
 measure the Internet Using this perspective
 to understand how
 systems are deployed
 in practice

slide-3
SLIDE 3

E-mail Security in Practice

Alice smtp.umich.edu SMTP Submission
 (TCP/587)

slide-4
SLIDE 4

E-mail Security in Practice

Alice smtp.umich.edu SMTP Submission
 (TCP/587) DNS Server 1.2.3.4 MX?

slide-5
SLIDE 5

E-mail Security in Practice

Alice smtp.umich.edu smtp.gmail.com SMTP Submission
 (TCP/587) DNS Server 1.2.3.4 MX? S M T P D e l i v e r y ( T C P / 2 5 )

slide-6
SLIDE 6

E-mail Security in Practice

Alice smtp.umich.edu Bob smtp.gmail.com SMTP Submission
 (TCP/587) DNS Server 1.2.3.4 MX? pop3.gmail.com S M T P D e l i v e r y ( T C P / 2 5 ) POP3/IMAP

slide-7
SLIDE 7

E-mail Security in Practice

Alice smtp.umich.edu Bob smtp.gmail.com SMTP Submission
 (TCP/587) DNS Server 1.2.3.4 MX? pop3.gmail.com S M T P D e l i v e r y ( T C P / 2 5 ) POP3/IMAP

slide-8
SLIDE 8

E-mail Security in Practice

Alice smtp.umich.edu Bob smtp.gmail.com SMTP Submission
 (TCP/587) DNS Server 1.2.3.4 MX? pop3.gmail.com S M T P D e l i v e r y ( T C P / 2 5 ) POP3/IMAP

Email Delivery (SMTP) has no built-in security We’ve added SMTP extensions to:


  • 1. Encrypt email in transit

  • 2. Authenticate email on

receipt Deployment is voluntary and invisible to end users

slide-9
SLIDE 9

Recipient (Bob) Mail server

(smtp.destination.com)

Passive Eavesdropper Sender (Alice) Mail server (smtp.source.com)

STARTTLS: TLS for SMTP

Allow TLS session to be started during an SMTP connection Mail is transferred over the encrypted session

slide-10
SLIDE 10

STARTTLS Protocol

TCP handshake 220 Ready EHLO 250 STARTTLS STARTTLS 220 GO HEAD TLS negotiation Encrypted email Sender Recipient

slide-11
SLIDE 11

Opportunistic Encryption Only

“A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure.” (RFC3207)

Unlike HTTPS, STARTTLS is 
 used opportunistically





Senders do not validate
 destination servers — the 
 alternative is cleartext Many servers do not support 
 STARTTLS

slide-12
SLIDE 12

What name to validate?

Unlike HTTPS, unclear what name should go on the certificate MX Server (e.g., smtp.gmail.com)

  • No real security added
  • MITM returns bad MX record


 Domain (e.g., gmail.com)

  • No clear solution for large


cloud providers


smtp.umich.edu DNS Server (1)

MX?

mx.gmail.com

DNS Server (2)

A mx.gmail.com 1.2.3.4

slide-13
SLIDE 13

STARTTLS Usage as seen by Gmail

slide-14
SLIDE 14

STARTTLS Usage as seen by Gmail

Yahoo and Hotmail
 deploy STARTTLS

slide-15
SLIDE 15

20 40 60 80 100 01/2014 03/2014 05/2014 07/2014 09/2014 11/2014 01/2015 03/2015 Percent of Gmail Connections Inbound Outbound

Poodle
 Vulnerability

slide-16
SLIDE 16

Long Tail of Mail Operators

These numbers are dominated by a few large providers. Of the Alexa Top 1M with Mail Servers:

  • 81.8% support STARTTLS

  • 34% have certificates that match MX server
  • 0.6% have certificates that match domain


(which would allow true authentication) Not currently feasible to require STARTTLS

slide-17
SLIDE 17

Common Implementations on Ubuntu

Software Top Million Market Share Public IPv4 
 Market Share Default Incoming Default Outgoing Exim 34% 24% ❌ ✔ Postfix 18% 21% ✔ ❌ qmail 6% 1% ❌ ❌ Sendmail 5% 4% ❌ ✔ MS Exchange 4% 12% ✔ ✔ Other/Unknown 33% 38% ❔ ❔

slide-18
SLIDE 18

What’s the simplest way to eavesdrop

  • n servers that use STARTTLS?
slide-19
SLIDE 19

Attack 1: STARTTLS Stripping

TCP handshake 220 Ready EHLO Sender Recipient

250 STARTTLS 250 XXXXXXXX

Cleartext Email

slide-20
SLIDE 20

STARTTLS Stripping in the Wild

Country Tunisia 96.1% Iraq 25.6% Papua New Guinea 25.0% Nepal 24.3% Kenya 24.1% Uganda 23.3% Lesotho 20.3% Sierra Leone 13.4% New Caledonia 10.1% Zambia 10.0%

slide-21
SLIDE 21

STARTTLS Stripping in the Wild

Country Tunisia 96.1% Iraq 25.6% Papua New Guinea 25.0% Nepal 24.3% Kenya 24.1% Uganda 23.3% Lesotho 20.3% Sierra Leone 13.4% New Caledonia 10.1% Zambia 10.0% Country Reunion 9.3% Belize 7.7% Uzbekistan 6.9% Bosnia and Herzegovina 6.5% Togo 5.5% Barbados 5.3% Swaziland 4.6% Denmark 3.7% Nigeria 3.6% Serbia 3.1%

slide-22
SLIDE 22

Not Necessarily Malicious

Organization Type Corporation 43% ISP 18% Financial Institution 14% Academic Institution 8% Healthcare Provider 3% Unknown 3% Airport 2% Hosting Provider 2% NGO 1%

Cisco advertises this feature to prevent attacks and catch spam It’s unclear if operators know they’re inadvertently putting users at risk Signal as to how vulnerable protocols currently are

slide-23
SLIDE 23

Attack 2: Lying DNS Servers

MX? IP: 6.6.6.6 Sender (Alice) Source Mail server DNS server Rogue Mail server Recipient (Bob) Forward Destination Mail Server

slide-24
SLIDE 24

Attack 2: Lying DNS Servers

Country Slovakia 0.08% Romania 0.04% Bulgaria 0.02% India 0.01% Israel 0.01% Poland 0.01% Switzerland 0.01% Ukraine 0.01% Others 10.1%

slide-25
SLIDE 25

Authenticating Email

slide-26
SLIDE 26

Authenticating Email

DomainKeys Identified Mail (DKIM)

Sender signs messages with cryptographic key

Sender Policy Framework (SPF)

Sender publishes list of IPs authorized to send mail

Domain Message Authentication, Reporting and Conformance (DMARC)

Sender publishes policy in DNS that specifies 
 what to do if DKIM or SPF validation fails

slide-27
SLIDE 27

E-mail Authentication in Practice

DKIM 2% SPF 11% No Auth 6% SPF & DKIM 81%

Gmail Authentication

slide-28
SLIDE 28

E-mail Authentication in Practice

DKIM 2% SPF 11% No Auth 6% SPF & DKIM 81%

Gmail Authentication

Technology Top 1M SFP Enabled 47% DMARC Policy 1%

Top Million Domains

DMARC Policy Top 1M Reject 20% Quarantine 8% Empty 72%

slide-29
SLIDE 29

Moving Forward

Two IETF proposals to solve real world issues:

SMTP Strict Transport Security

Similar to HTTPS HSTS (key pinning)

Authenticated Received Chain (ARC)

DKIM replacement that handles mailing lists

slide-30
SLIDE 30

Gmail STARTTLS Indication

Insecure Received Insecure Sending

slide-31
SLIDE 31

Inbound Gmail Protected by STARTTLS

Google Deploys 
 STARTTLS Indicator

slide-32
SLIDE 32

Current State of Affairs

Providers are continuing to roll out transport security and authentication protocols, but many organizations lag in deployment STARTTLS currently provides no protection against active adversaries Several proposals in discussion for bridging these gaps Mail is used to communicate sensitive data and despite being hidden from view, its security is equally important

slide-33
SLIDE 33

Neither Snow Nor Rain Nor MITM... 
 An Empirical Analysis of Email Delivery Security

Zakir Durumeric University of Michigan zakir@umich.edu