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
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
2
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
3
Prof. Dr. Matthew Smith
CAs in the news
4
Prof. Dr. Matthew Smith
SSL Warnings
5
Usable Security and Privacy Lab –Universität Bonn
users actually see
FF2 What
Warning
Adapted from Jonathan Nightingale
CyLab Usable Privacy and Security Laboratory
6
Usable Security and Privacy Lab –Universität Bonn
http://cups.cs.cmu.edu/
4
Heartbleed
7
Usable Security and Privacy Lab –Universität Bonn
SSL CCS Injection Vulnerability
Masashi Kikuchi of Lepidum
 CVE-2014-0224
OpenSSL’s ChangeCipherSpec processing
has a serious vulnerability
 OpenSSL 1.0.1 through 1.0.1g
 OpenSSL 1.0.0 through 1.0.0l
 all versions before OpenSSL 0.9.8y
 Attackers can eavesdrop and modify
communication
 Attackers can hijack a authenticated
session
Not as bad as heartbleed but still pretty bad
8
Usable Security and Privacy Lab –Universität Bonn
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
9
Usable Security and Privacy Lab –Universität Bonn
Usable security & privacy research
 End-user
 Evaluation
 Automation
 Communication
 Administrators/Experts
 Software and process
optimisation
 Developers
 API and Library analysis
 New paradigms
10
Usable Security and Privacy Lab –Universität Bonn
SSL on Android
The end user
11
Usable Security and Privacy Lab –Universität Bonn
Android Browser Warning Messages
Mobile browsers validate SSL certificates
correctly…
…display security indicators…
...and warn the user if something
goes wrong
12
Usable Security and Privacy Lab –Universität Bonn
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
… and warn the user if something
wrong….
goes
presented
an SSL warning message
13
Usable Security and Privacy Lab –Universität Bonn
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.
14
Usable Security and Privacy Lab –Universität Bonn
Appification
 There’s an App for Everything
15
Sascha Fahl, 16.10.2012
Developers
16
Usable Security and Privacy Lab –Universität Bonn
Trust me I‘m an Engineer
17
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
18
Prof. Dr. Matthew Smith
TrustManager Implementations
 22 different TrustManager implementations
NonValidatingTrustManager
FakeTrustManager
EasyX509TrustManager
NaiveTrustManager
TrustManager
DummyTrustManager
AcceptAllTrustManager
SimpleTrustManager
OpenTrustManager
 and all turn effective certificate validation off
19
Prof. Dr. Matthew Smith
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.
20
Usable Security and Privacy Lab –Universität Bonn
Manual App Testing Results
These 41 apps had an
install-base of 39 – 185 million!
21
Prof. Dr. Matthew Smith
Anti-Virus Example
22
Prof. Dr. Matthew Smith
For more on this see
 Sascha Fahl, 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)
23
Prof. Dr. Matthew Smith
Nation
State
Adversaries
24
Usable Security and Privacy Lab –Universität Bonn
SSL Development
Usable Security for
Users
25
Usable Security and Privacy Lab –Universität Bonn
users actually see
FF2 What
Warning
Adapted from Jonathan Nightingale
CyLab Usable Privacy and Security Laboratory
26
Usable Security and Privacy Lab –Universität Bonn
http://cups.cs.cmu.edu/
4
SSL Development
Usable Security for
Developers
28
Usable Security and Privacy Lab –Universität Bonn
Dumb Developers?
29
Usable Security and Privacy Lab –Universität Bonn
Talking To Developers
 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 ?
 15 developers agreed
30
✓
Usable Security and Privacy Lab –Universität Bonn
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.
31
Usable Security and Privacy Lab –Universität Bonn
Solutions?
 So what should we do to help the developers?
32
Usable Security and Privacy Lab –Universität Bonn
A new approach to SSL on Android
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 config file
 Standardised User Interaction
 actually show user what is happening
 show meaningful warnings
 Alternate SSL Validation Strategies
 Perspectives, Certificate
Transparency, etc.
 hot-pluggable
33
Prof. Dr. Matthew Smith
For more on this see
 Sascha 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)
34
Prof. Dr. Matthew Smith
SSL Infrastructure
Certificate Transparency
35
Usable Security and Privacy Lab –Universität Bonn
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
36
Prof. Dr. Matthew Smith
Certificate Transparency (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
37
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
38
Usable Security and Privacy Lab –Universität Bonn