Presented by Phani Krishna P 10/20/2016 Neither Snow Nor Rain Nor MITM . . . An Empirical Analysis of Email Delivery Security By Zakir Durumeric† David Adrian† Ariana Mirian† James Kasten† Elie Bursztein‡ Nicolas Lidzborski‡ Kurt Thomas‡ Vijay Eranti‡ Michael Bailey§ J. Alex Halderman† † University of Michigan ‡ Google, Inc. § University of Illinois, Urbana Champaign

Simple Mail Transfer Protocol Presented by Phani Krishna P 10/20/2016 Simple Mail Transfer Protocol Internet standard for sending and relaying email Originally conceived in 1981 Does not provide Confidentiality of messages or authenticating messages Protocol extensions such as STARTTLS, DKIM, DMARC, and SPF encrypt message content and authenticate senders This paper: measures global adoption of SMTP security extensions

Smtp protocol Extensions Presented by Phani Krishna P 10/20/2016 Smtp protocol Extensions Opportunistic TLS is an opportunistic encryption mechanism, TCP uses SSL ports. Man in Middle can create: STRIPTLS attack Sender Policy Framework (SPF) is a simple email-validation system designed that allow receiving mail exchangers to check that incoming mail comes from a domain from a host authorized by that domain's administrators. DomainKeys Identified Mail (DKIM) is an email authentication method that checks an email claimed to come from a specific domain was indeed authorized by the owner of that domain. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a proposed standard: designed to protect against direct domain spoofing.

starttls Aims to protect individual hops between SMTP server Presented by Phani Krishna P 10/20/2016 starttls Aims to protect individual hops between SMTP server Not compulsory at EVERY SMTP server Every relay will have access to plain text messages RFC does not define how to validate presented certificates

Presented by Phani Krishna P 10/20/2016 Authenticating email DKIM) lets SMTP servers detect whether a received message has been spoofed or modified during transit Sender appends DKIM-Signature field to the message header Receiver verifies the message’s signature Allows an organization to publish a range of hosts that are authorized to send mail for its domain Organization publishes a DNS record that specifies which hosts or CIDR blocks belong to the organization. Every relay will have access to plain text messages DMARC allows senders to suggest a policy for authenticating received mail Sender publishes a DNS TXT record Receiver action for authentication response is defined in DNSTXT SPF Allows organizations to delegate a portion or the entirety of their SPF policy to another organization A mail exchanger record (MX record) is a type of resource record in the Domain Name System that specifies a mail server responsible for accepting email messages on behalf of a recipient's domain, and a preference value used to prioritize mail delivery if multiple mail servers are available. The set of MX records of a domain name specifies how email should be routed with the Simple Mail Transfer Protocol (SMTP).

Presented by Phani Krishna P 10/20/2016 SMTP: Authentication

Dataset Logs of SMTP handshakes of Gmail Presented by Phani Krishna P 10/20/2016 Dataset Logs of SMTP handshakes of Gmail Google Transparency Report excludes spam messages. https://www.google.com/transparencyreport/ Data set obtained in collaboration with Google: Set of all ciphers negotiated with external SMTP servers Snapshots of SMTP server configurations SMTP security features enabled by mail servers belonging to the Alexa Top Million ranked websites By performing MX record lookups for the Alexa Top Million domains. Performed DNS query to identify supported SMTP security extensions and attempted an SMTP and STARTTLS handshake using ZMap Previous papers provide details about their scanning methodology and ethical considerations etc.

Presented by Phani Krishna P 10/20/2016 Dataset Previous papers provide details about their scanning methodology and ethical considerations etc.

GMAIl starttls support Presented by Phani Krishna P 10/20/2016 GMAIl starttls support Usage increased by 54% and 82% In May: Yahoo/Outlook In October: public disclosure of poodle vulnerability Only 58% of most common domains accepted 100% of messages over TLS Weekends observe 7.2% increase in secure messages

Cipher suite Gmail inbound traffic Presented by Phani Krishna P 10/20/2016 Cipher suite Gmail inbound traffic 84% of the traffic is encrypted by TLS 45.2% use RC4 (Rivest Cipher: Stream cipher) No known-broken ciphers exists in data-set as Google does not support them.

Starttls: gmail vs facebook Presented by Phani Krishna P 10/20/2016 Starttls: gmail vs facebook May 2014 August 2014 Gmail  47% :: 100% 74% :: 100% Facebook 58% :: 76% 95% :: 100% Facebook connects with major providers while Gmail does not have that flexibility

Organizaional deployment Presented by Phani Krishna P 10/20/2016 Organizaional deployment 25% of domains outsource to 5 email providers

Certificate validity Mail server presents X.509 certificate Presented by Phani Krishna P 10/20/2016 Certificate validity Mail server presents X.509 certificate In practice, DNSSEC is NOT widely deployed 0.6% of .com and .net domains deployed DNSSEC Several mail hosting servers incorrectly deployed wildcard certificates Maximum 35% of mail servers with STARTTLS can be authenticated in any form

Software implementations Presented by Phani Krishna P 10/20/2016 Software implementations

Encryption behavior of Mail providers Presented by Phani Krishna P 10/20/2016 Encryption behavior of Mail providers

STARTTLS Significant growth in STARTTLS adoption Presented by Phani Krishna P 10/20/2016 STARTTLS Significant growth in STARTTLS adoption Large providers dominate the usage Until organizations deploy valid certificates, relays can not authenticate destination servers.

confidentiality Two types of network attacks Presented by Phani Krishna P 10/20/2016 confidentiality Two types of network attacks downgrading STARTTLS sessions to insecure channels falsifying MX records to re-route message STARTTLS corruption: SMTP servers fall back to clear text for errors during hand-shake

Presented by Phani Krishna P 10/20/2016 Starttls stripping In 423 Ases, 100% of SMTP servers observe STARTTLS stripping AS owners include: governments, ISPs, financial, health-care institutions, etc. Including airports and airlines Possible only for outgoing messages, but the practice is widespread

DNS hijacking DNS servers that provide false MX records Presented by Phani Krishna P 10/20/2016 DNS hijacking DNS servers that provide false MX records 178,439 out of 8,860,639 (2.01%) publicly accessible DNS servers provided invalid IPs or MX records 521 ASes provide fraudulent responses 83.6% of the hosts were located in 5 Ases

Authentication in practice: SPF Presented by Phani Krishna P 10/20/2016 Authentication in practice: SPF 92% of inbound messages use SPF Among Alexa’s Top million domains, ONLY 47% publish SPF policy

Authentication in practice: SPF Presented by Phani Krishna P 10/20/2016 Authentication in practice: SPF 10,432 domains redirect SPF policy to another provider 213,464 domains contain policies of other domain’s SPF policies Domains include records from well- known cloud mail providers

Authentication in practice: dkim Presented by Phani Krishna P 10/20/2016 Authentication in practice: dkim

Authentication in practice: spF, Dmarc Presented by Phani Krishna P 10/20/2016 Authentication in practice: spF, Dmarc While 90% of messages can validate SPF/DKIM: only 26% published a DMARC policy RFC is fairly new (march 2013 & updated on March 2015)

Challenges for confidentiality Presented by Phani Krishna P 10/20/2016 Challenges for confidentiality NO mechanism for servers to indicate that a mail SHOULD be protected by TLS NO mechanism like HSTS for SMTP: messages are relayed in clearText Even with TLS, there is no robust way for a sender to verify authenticity of the recipient mail server End-to-end mail encryption, provided by PGP and S/MIME, does not address all of the challenges When a web application[13] issues HSTS Policy to user agents, conformant user agents behave as follows:[14] Automatically turn any insecure links referencing the web application into secure links. (For instance, http://example.com/some/page/ will be modified to https://example.com/some/page/ before accessing the server.) If the security of the connection cannot be ensured (e.g. the server's TLS certificate is not trusted), show an error message and do not allow the user to access the web application.[15]

Challenges for integrity Presented by Phani Krishna P 10/20/2016 Challenges for integrity Authenticate mail sent through mailing lists (which modify messages in transit)? Yahoo deployed a reject policy, which resulted in heavy number of compliants Organizations move to public cloud providers: SPF has become less relevant DKIM is threatened by massive key compromises Third party providers may need to have certificates containing their clients’ domains for strict certificate verification

conclusion SMTP by itself is NOT secure Presented by Phani Krishna P 10/20/2016 conclusion SMTP by itself is NOT secure This paper empirically shows that SMPT Extensions like STARTTLS, SPF, DKIM, DMARC are NOT utilized by ALL organizations While large SMTP service providers provide such features, smaller organizations continue to lag in both deployment and proper configuration Backward compatibility is being supported, which is major blockage to prevent attacks 20% of Gmail inbound messages can be prone for man-in-the-middle type of attacks