1. Presented by Phani Krishna P
10/20/2016
Neither Snow Nor Rain Nor MITM An Empirical Analysis of 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

2. Simple Mail Transfer Protocol
Presented by Phani Krishna P
10/20/2016
Simple Mail Transfer Protocol
Internet standard for sending and relaying
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

3. 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  -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  authentication method that checks an 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.

4. 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

5. Presented by Phani Krishna P
10/20/2016
Authenticating
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   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 should be routed with the Simple Mail Transfer Protocol (SMTP).

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

7. 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.
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.

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

9. 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

10. 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.

11. 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

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

13. 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

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

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

16. 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.

17. 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

18. 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

19. 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

20. 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

21. 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

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

23. 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)

24. 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,  be modified to  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]

25. 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

26. 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