Matthew Smith Usable Security and Privacy Lab, Universität Bonn

1. The Future of SSL in an AppifiedWorldFromDevelopers to NSA, the Nation State Adversaries Matthew SmithUsable Security and Privacy Lab, Universität Bonn Human Factors Group, Fraunhofer FKIE

2. Secure Socket Layer SSL is a cryptographic protocol and the mainstay of our Internet security It is mainly used in combination with Certificate Authorities to validate the public keys of entities

3. Problems with CAs (whom do we trust?) • Approximately 100-200 trusted root CAs in • Firefox, Chrome, IE Explorer, Windows, Mac OS, Linux • Extended to ~650 via CA hierarchies • EFF Map of these organizations • SSL / HTTPS only as strong as the weakest link • Weak (email-based) authentication with many CAs • Targeted attacks against CAs - a real world threat • As Comodo and Diginotar have shown • https://www.eff.org/observatory Prof. Dr. Matthew Smith

4. CAs in the news Prof. Dr. Matthew Smith

5. SSL Warnings Usable Security and Privacy Lab –Universität Bonn

6. What users actually see Usable Security and Privacy Lab –Universität Bonn

7. Heartbleed Usable Security and Privacy Lab –Universität Bonn

8. SSL CCS Injection Vulnerability Usable Security and Privacy Lab –Universität Bonn Masashi Kikuchi of Lepidum • CVE-2014-0224 OpenSSL’sChangeCipherSpec processing has a serious vulnerability • OpenSSL1.0.1 through 1.0.1g • OpenSSL 1.0.0 through 1.0.0l • all versions before OpenSSL0.9.8y • Attackers can eavesdrop and modify communication • Attackers can hijack a authenticated session Not as bad as heartbleed but still pretty bad

9. Usable Security: An Emerging Research Field Complexity is the worst enemy of security • Systems are getting ever more complex We have the technology to make – almost – everything secure • We just don‘t have the people to do it properly We have two options: • Create more secure humans • Create more usable technology Usable Security and Privacy Lab –Universität Bonn

10. Usable security & privacy research • End-user • Evaluation • Automation • Communication • Administrators/Experts • Software and process optimisation • Developers • API and Library analysis • New paradigms Usable Security and Privacy Lab –Universität Bonn

11. SSL on Android The end user Usable Security and Privacy Lab –Universität Bonn

12. Android Browser Warning Messages Mobile browsers validate SSL certificates correctly… • …display security indicators… ...and warn the user if something goes wrong Usable Security and Privacy Lab –Universität Bonn

13. Online Survey • To see if users know when they are surfing on an SSL protected website • half of the participants got the survey via HTTP • the other half via HTTPS • exit survey asked whether their connection was protected or not • To find out if users understood the Browser’s warning messages • presented an SSL warning message … and warn the user if something goes wrong…. Usable Security and Privacy Lab –Universität Bonn

14. Online Survey - Results • 745 participants • 47.5% of non-IT experts believed they were using a secure Internet connection • although it was plain HTTP • even 34.7% of participants with prior IT education thought this • ~50% had not seen an SSL warning message on their phone before. • The risk users were warned against was rated with 2.86 (sd=.94) on a scale between 1 and 5 • Many participants stated they did not care about warning messages at all. Usable Security and Privacy Lab –Universität Bonn

15. Appification Sascha Fahl, 16.10.2012 There’s an App for Everything

16. Developers Usable Security and Privacy Lab –Universität Bonn

17. Trust meI‘m an Engineer

18. SSL Static Code Analysis • 2011 Analysis of 13,500 popular, free apps from Google’s Play Market • 92.8 % of the apps use the Internet permission • 91.7 % of networking API calls are HTTP(S) related • 0.8 % exclusively HTTPS URLs • 46.2 % mix HTTP and HTTPS • 17.28 % of all apps that use HTTPS include code that fails in SSL certificate validation • 1070 include critical code • 790 accept all certificates • 284 accept all hostnames Prof. Dr. Matthew Smith

19. TrustManager Implementations NonValidatingTrustManager FakeTrustManager EasyX509TrustManager NaiveTrustManager TrustManager DummyTrustManager SimpleTrustManager • and all turn effective certificate validation off AcceptAllTrustManager OpenTrustManager 22 different TrustManager implementations Prof. Dr. Matthew Smith

20. Manual App Testing Results • Cherry-picked 100 apps • 21 apps trust all certificates • 20 apps accept all hostnames • Captured credentials for: • American Express, Diners Club, Paypal, bank accounts, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, remote control servers, arbitrary email accounts, and IBM Sametime, among others. Usable Security and Privacy Lab –Universität Bonn

21. Manual App Testing Results These 41 appshad an install-base of 39 – 185 million! Prof. Dr. Matthew Smith

22. Anti-Virus Example Prof. Dr. Matthew Smith

23. For more on this see SaschaFahl, Marian Harbach, Thomas Muders, Lars Baumgärtner, Bernd Freisleben and Matthew Smith: Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security,Proceedings of the 19th ACM Conference on Computer and Communications Security (ACM CCS 2012) Prof. Dr. Matthew Smith

24. Nation State Adversaries Usable Security and Privacy Lab –Universität Bonn

25. SSL Development Usable Security for Users Usable Security and Privacy Lab –Universität Bonn

26. What users actually see Usable Security and Privacy Lab –Universität Bonn

28. SSL Development Usable Security for Developers Usable Security and Privacy Lab –Universität Bonn

29. Dumb Developers? Usable Security and Privacy Lab –Universität Bonn

30. Talking To Developers ✓ ✓ ? ✓ • 15 developers agreed • Finding broken SSL in Android apps is good… …knowing what the root causes are is even better • We contacted 80 developers of broken apps • informed them • offered further assistance • asked them for an interview Usable Security and Privacy Lab –Universität Bonn

31. Developer Survey Summary • Self-Signed Certificates – Development. • Developers commonly wish to use self-signed certificates for testing purposes and hence want to turn off certificate validation during testing. • Self-Signed Certificates – Production. • A few developers wanted to use self-signed certificates in their production app for cost and effort reasons. • Code Complexity. • Developers described the code-level customization features of SSL as too complex and requiring too much effort. • Certificate Pinning / Trusted Roots. • Developers liked the idea of having an easy way to limit the number of trusted certificates and/or certificate authorities. • Global Warning Message. • Developers requested global SSL warning messages since they described building their own warning messages as too challenging. Usable Security and Privacy Lab –Universität Bonn

32. Solutions? So what should we do to help the developers? Usable Security and Privacy Lab –Universität Bonn

33. A new approach to SSL on Android Prof. Dr. Matthew Smith Central SSL service for Android • Force SSL • start with https-everywhere list • Force SSL Validation • cannot be overridden • Self-Signed Certificates • for developer devices • SSL Pinning • via simple configfile • Standardised User Interaction • actually show user what is happening • show meaningful warnings • Alternate SSL Validation Strategies • Perspectives, Certificate Transparency, etc. • hot-pluggable

34. For more on this see SaschaFahl, Marian Harbach, Henning Perl, Markus Koetter, Matthew Smith(2013): Rethinking SSL Development in an AppifiedWorld,Proceedings of the 20th ACM Conference on Computer and Communications Security (ACM CCS 2013) Prof. Dr. Matthew Smith

35. SSL Infrastructure Certificate Transparency Usable Security and Privacy Lab –Universität Bonn

36. Problems with CAs (whom do we trust?) • Approximately 100-200 trusted root CAs in • Firefox, Chrome, IE Explorer, Windows, Mac OS, Linux • Extended to ~650 via CA hierarchies • EFF Map of these organizations • SSL / HTTPS only as strong as the weakest link • Weak (email-based) authentication with many CAs • Targeted attacks against CAs - a real world threat • As Comodo and Diginotar have shown • https://www.eff.org/observatory Prof. Dr. Matthew Smith

37. CertificateTransparency (Google‘11) Idea: Make all CA action visible and non-repudiable • Adds additional layer to CA infrastructure • Certificate Transparency (CT) server operates append-only data structure (Merkle tree) • Procedure: • Submit Cert to CT log • Receive Signed Certificate Timestamp • TLS present the SCT to a TLS client • along with the SSL certificate • CT log only adds Certs if: • They are signed by trusted CA • CT log is append only • Client only accepts connections with SCT • Can detect attacks after the fact • Hopefully deters “respectable” attackers

38. Usable security & privacy research • End-user • Do not see mobile security indicators • Should not have to • Administrators/Experts • Misconfigure servers • Should have better tools • Developers • Make many honest mistakes • New development paradigm can protect in specific domains • Usable development of crypto libraries has not been researched properly to date • Infrastructure • Transparency is key Usable Security and Privacy Lab –Universität Bonn