38
The Future of SSL in an Appified World From Developers to NSA, the Nation State Adversaries Matthew Smith Usable Security and Privacy Lab, Universität Bonn Human Factors Group, Fraunhofer FKIE

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

Embed Size (px)

DESCRIPTION

The Future of SSL in an Appified World From Developers to NSA, the Nation State Adversaries. Matthew Smith Usable Security and Privacy Lab, Universität Bonn Human Factors Group, Fraunhofer FKIE. Secure Socket Layer. - PowerPoint PPT Presentation

Citation preview

PowerPoint-Prsentation

The Future of SSL in an Appified World From Developers to NSA, the Nation State Adversaries

Matthew Smith

Usable Security and Privacy Lab, Universitt BonnHuman Factors Group, Fraunhofer FKIENr.

1Secure Socket Layer

SSL is a cryptographic protocol and the mainstay of our Internet securityIt is mainly used in combination with Certificate Authorities to validate the public keys of entities

Nr.

Problems with CAs (whom do we trust?) Prof. Dr. Matthew SmithApproximately 100-200 trusted root CAs inFirefox, Chrome, IE Explorer, Windows, Mac OS, LinuxExtended to ~650 via CA hierarchies EFF Map of these organizations SSL / HTTPS only as strong as the weakest linkWeak (email-based) authentication with many CAsTargeted attacks against CAs - a real world threatAs Comodo and Diginotar have shownhttps://www.eff.org/observatoryNr.

CAs in the newsProf. Dr. Matthew Smith

Nr.

SSL Warnings

Usable Security and Privacy Lab Universitt BonnNr.

What users actually see

Usable Security and Privacy Lab Universitt BonnNr.

HeartbleedUsable Security and Privacy Lab Universitt Bonn

Nr.

SSL CCS Injection Vulnerability Usable Security and Privacy Lab Universitt Bonn

Masashi Kikuchi of LepidumCVE-2014-0224

OpenSSLs ChangeCipherSpec processing has a serious vulnerabilityOpenSSL 1.0.1 through 1.0.1gOpenSSL 1.0.0 through 1.0.0lall versions before OpenSSL 0.9.8yAttackers can eavesdrop and modify communication Attackers can hijack a authenticated session

Not as bad as heartbleed but still pretty bad

Nr.

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 secureWe just dont have the people to do it properly

We have two options:Create more secure humansCreate more usable technology

Usable Security and Privacy Lab Universitt BonnNr.

Usable security & privacy researchUsable Security and Privacy Lab Universitt Bonn

End-userEvaluationAutomationCommunicationAdministrators/ExpertsSoftware and process optimisationDevelopersAPI and Library analysisNew paradigms

Nr.

SSL on Android

The end userUsable Security and Privacy Lab Universitt BonnNr.

Android Browser Warning Messages

Mobile browsers validate SSL certificates correctly...and warn the user if something goes wrong

display security indicators

Usable Security and Privacy Lab Universitt BonnNr.

12Online Survey and warn the user if something goes wrong.

To see if users know when they are surfing on an SSL protected websitehalf of the participants got the survey via HTTPthe other half via HTTPSexit survey asked whether their connection was protected or not

To find out if users understood the Browsers warning messagespresented an SSL warning messageUsable Security and Privacy Lab Universitt BonnNr.

13

~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 5Many participants stated they did not care about warning messages at all.Online Survey - Results745 participants47.5% of non-IT experts believed they were using a secure Internet connectionalthough it was plain HTTPeven 34.7% of participants with prior IT education thought thisUsable Security and Privacy Lab Universitt BonnNr.

14AppificationTheres an App for Everything

Sascha Fahl, 16.10.2012Nr.

15DevelopersUsable Security and Privacy Lab Universitt BonnNr.

Trust me Im an Engineer

Nr.

so they fix it!but not always in the most secure way17SSL Static Code Analysis2011 Analysis of 13,500 popular, free apps from Googles Play Market92.8 % of the apps use the Internet permission91.7 % of networking API calls are HTTP(S) related0.8 % exclusively HTTPS URLs46.2 % mix HTTP and HTTPS17.28 % of all apps that use HTTPS include code that fails in SSL certificate validation1070 include critical code790 accept all certificates284 accept all hostnames

Prof. Dr. Matthew Smith

Nr.

18TrustManager Implementations22 different TrustManager implementations

TrustManagerDummyTrustManagerAcceptAllTrustManagerOpenTrustManagerSimpleTrustManagerNonValidatingTrustManagerFakeTrustManagerEasyX509TrustManagerNaiveTrustManagerand all turn effective certificate validation offProf. Dr. Matthew Smith

Nr.

19Manual App Testing Results

Cherry-picked 100 apps21 apps trust all certificates20 apps accept all hostnamesCaptured 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 Universitt BonnNr.

20Manual App Testing Results

These 41 apps had an install-base of 39 185 million!Prof. Dr. Matthew Smith

Nr.

21Anti-Virus ExampleProf. Dr. Matthew Smith

Nr.

For more on this seeSascha Fahl, Marian Harbach, Thomas Muders, Lars Baumgrtner, 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

Nr.

Nation State AdversariesUsable Security and Privacy Lab Universitt BonnNr.

SSL DevelopmentUsable Security for UsersUsable Security and Privacy Lab Universitt BonnNr.

What users actually see

Usable Security and Privacy Lab Universitt BonnNr.

SSL DevelopmentUsable Security for DevelopersUsable Security and Privacy Lab Universitt BonnNr.

Dumb Developers?Usable Security and Privacy Lab Universitt Bonn

Nr.

Talking To DevelopersFinding broken SSL in Android apps is goodknowing what the root causes are is even better

We contacted 80 developers of broken appsinformed themoffered further assistanceasked them for an interview

?15 developers agreedUsable Security and Privacy Lab Universitt BonnNr.

30Developer Survey SummarySelf-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 Universitt BonnNr.

31Solutions?So what should we do to help the developers?Usable Security and Privacy Lab Universitt BonnNr.

A new approach to SSL on AndroidProf. Dr. Matthew Smith

Central SSL service for AndroidForce SSLstart with https-everywhere listForce SSL Validation cannot be overridden Self-Signed Certificatesfor developer devices SSL Pinningvia simple config file Standardised User Interaction actually show user what is happeningshow meaningful warnings Alternate SSL Validation StrategiesPerspectives, Certificate Transparency, etc. hot-pluggable

Nr.

For more on this seeSascha Fahl, Marian Harbach, Henning Perl, Markus Koetter, Matthew Smith(2013): Rethinking SSL Development in an Appified World,Proceedings of the 20th ACM Conference on Computer and Communications Security (ACM CCS 2013)

Prof. Dr. Matthew Smith

Nr.

SSL InfrastructureCertificate TransparencyUsable Security and Privacy Lab Universitt BonnNr.

Problems with CAs (whom do we trust?) Prof. Dr. Matthew SmithApproximately 100-200 trusted root CAs inFirefox, Chrome, IE Explorer, Windows, Mac OS, LinuxExtended to ~650 via CA hierarchies EFF Map of these organizations SSL / HTTPS only as strong as the weakest linkWeak (email-based) authentication with many CAsTargeted attacks against CAs - a real world threatAs Comodo and Diginotar have shownhttps://www.eff.org/observatoryNr.

Certificate Transparency (Google11)Adds additional layer to CA infrastructure Certificate Transparency (CT) server operates append-only data structure (Merkle tree)Procedure:Submit Cert to CT logReceive Signed Certificate TimestampTLS present the SCT to a TLS client along with the SSL certificateCT log only adds Certs if:They are signed by trusted CACT log is append only

Client only accepts connections with SCTCan detect attacks after the factHopefully deters respectable attackers

Idea: Make all CA action visible and non-repudiable Nr.

Adam Langley, Ben Laurie37Usable security & privacy researchUsable Security and Privacy Lab Universitt Bonn

End-userDo not see mobile security indicatorsShould not have toAdministrators/ExpertsMisconfigure serversShould have better toolsDevelopersMake many honest mistakesNew development paradigm can protect in specific domainsUsable development of crypto libraries has not been researched properly to dateInfrastructure Transparency is keyNr.