OWASP AppSec Research 2013, 20.-23.08.2012, Hamburg : … · 2020. 1. 17. ·...

A Qualitative Comparison of SSLValidation Alternatives

OWASP AppSec Research 2013

August 22nd, 2013

Henning Perl, Sascha Fahl, Michael Brenner, and Matthew SmithLeibniz Universität Hannover

. . . . .Introduction Solutions Network Perspective Certificate Log DNS Pinning Evaluation

Outline Of This Talk

. What’s SSL again?

. Things broken in SSL

. So many solutions!

. The best solution

(or why there isn’t any yet)

. Our evaluation system

Perl, Fahl, Brenner, Smith | A Qualitative Comparison of SSL Validation Alternatives Slide 2


How SSL works

...Client .. Server

.

.

CAs.

.

CAs.

.

CAs.

.

CAs

.

trusts

.

signs cert

.Secure connection

.

authenticates to



How SSL works …and breaks

...Client .. Server

.

.

CAs.

.

CAs.

.

CAs.

.

CAs

.

trusts

.

signs cert

.. Man in the middle.

stolen

cert

.authenticates to

.insecure

.connection


..

http://

notary.ic

si.berke

ley.e

du/tru

st-tree/


SSL CA incidents. In 2010, VeriSign was compromised, allowing the attackers to issue

arbitrary certificates.

. In March 2011, an attacker from Iran was able to compromise theComodo CA and get certificates for www.google.com, login.yahoo.com,login.skype.com, addons.mozilla.org, and login.live.com. A MITMA attackwith at least one these certificate was observed.

. In August 2011, attackers used the DigiNotar CA to issue at least 200fraudulent certificates and used them to impersonate web servers. Thebreach eventually lead to the exclusion of the CA from most browsersand operating systems.

⇒ weakest link security



Things broken in SSL

For sake of completeness

. Users ignore warnings(c.f. Sunshine et al., “Crying Wolf: An Empirical Study of SSL WarningEffectiveness”)

. Attacks against the cryptosystem. BEAST (2011) / CRIME (2012) attacks. Padding oracle attack (“Lucky Thirteen”, S&P 2013). Attacks against RC4 (Usenix 2013)

. SSL stripping (Marlinspike, Black Hat 2009)

. SSL validation / Weakest link CA security



Types of solutions:

. Use of network perspectivePerspectives, Convergence

. Keep a log of certificatesSovereign Keys (SK), Certificate Transparency (CT), Accountable KeyInfrastructure (AKI)

. Serve certificates over DNSDANE

. Trust on first useTACK



Network Perspective (Perspectives, Convergence)

...Client .. Server

.

.

N1

.

N2

.

N3

.

N4

.

N5

.

. . .

.

Nk

.

globally distributed notaries

3No extra software on server7 Network delay 7 Privacy



Keep A Log Of Certificates SK, CT, AKI

...Client .. Server

.

.

CAs.

.

CAs.

.

CAs.

.

CAs

.

trusts

.

signs cert

.Secure connection

.

authenticates to

3No extra software on server 3no extra network delay7 needs new infrastructure



Keep A Log Of Certificates SK, CT, AKI

...Client .. Server

.

.

CAs.

.

CAs.

.

CAs.

.

CAs.

..

Certificate Log

.

trusts

.

signs cert

.Secure connection

.

authenticates to

.

submits certificate

.

Proof ofinclusion

3No extra software on server 3no extra network delay7 needs new infrastructure



Serve Certificates Over DNS DANE

...Client .. Server

.

.

CAs.

.

CAs.

.

CAs.

.

CAs

.

trusts

.

signs cert

.Secure connection

.

authenticates to

3No extra software on server 3reuses infrastructure7 DNSSEC



Serve Certificates Over DNS DANE

...Client .. Server

.

.

Domain admin

.

submits certificate

.

..

DNS Server

.

signs cert

.Secure connection

.

authenticates to

.

certificate andDNS response

3No extra software on server 3reuses infrastructure7 DNSSEC



Pinning TACKPinning on TACK public key; TACK secret key signs actual cert.

...Client.First

connection.. Server.

Secure connection?.

TACK public key

.

.

Client

.

Subsequentconnections

.

.

Server

.

Secure connection

.

TACK public key

3No extra software on server 3no CAs (just selfsign)7 No protection on first visit



What do we draw from this?



Our Evaluation SchemeGoals:

. Tool to compare solution

. Discussion about which properties are important

. Organize, formalize the debate

Structure:. One large table. 12 Deployability Benefits. 9 Security and Privacy Benefits. Adversary Capabilities

. Active MITMA required

. Trusted CA certificate required

. Compromising user chosen third parties required



Our Evaluation SchemeGoals:

. Tool to compare solution

. Discussion about which properties are important

. Organize, formalize the debate

Structure:

. One large table

. 12 Deployability Benefits

. 9 Security and Privacy Benefits

. Adversary Capabilities. Active MITMA required. Trusted CA certificate required. Compromising user chosen third parties required


5

Capabilities

..Scheme ..Ref.

..

Dep

loya

bilit

ybe

nefit

s

..

No-

Use

r-C

ost

..

No-

Serv

er-C

ost

..

Serv

er-C

ompa

tible

..

Bro

wse

r-C

ompa

tible

..

Incr

emen

tally

-Dep

loya

ble

..

Neg

ligib

le-C

omm

unic

atio

n-O

verh

ead

..

Neg

ligib

le-C

ompu

tatio

nal-O

verh

ead

..

No-

Add

ition

al-I

nfra

stru

ctur

e

..

Trus

ted-

Roo

t-CA

-sup

port

..

Cus

tom

-Roo

t-CA

-sup

port

..

Selfs

igne

d-C

ertifi

cate

-sup

port

..

No-

Out

-Of-

Ban

d-C

onne

ctio

n

..

X.5

09-C

ompa

tible

..

Secu

rity

bene

fits

..

Bui

lt-In

-Rev

ocat

ion

..

OC

SP-o

r-C

RL-

Com

patib

ility

..

Res

ilien

t-To-

DO

S-A

ttack

s

..

Use

r-Pr

ivac

y-Pr

eser

ving

..

Secu

re-K

ey-M

igra

tion

..

Secu

re-K

ey-M

igra

tion-

Afte

r-C

rede

ntia

l-The

ft

..

Secu

re-D

omai

n-M

igra

tion

..

Act

ive

MIT

MA

requ

ired ..

Trus

ted

CA

certi

ficat

ere

quire

d(w

eake

stlin

k)

..

Com

prom

isin

gus

erch

osen

third

parti

esre

quire

d(s

trong

estl

ink) ..

Firs

t-Con

tact

-Pro

tect

ion

..

Con

nect

ion-

Prot

ectio

n

SSL with CA-PKI — . . . . . . . . . . . . . . . . . . . . . . .(90’s) . . .

.. 0 . .Perspectives [13] . . . . . . . . . . . . . . . . . . . . . . .(2008) . . .

.. n . .DANE [5] . . . . . . . . . . . . . . . . . . . . . . .(2010) . . .

.. 1 . .Convergence [9] . . . . . . . . . . . . . . . . . . . . . . .(2011) . . .

.. n . .Sovereign Keys [3] . . . . . . . . . . . . . . . . . . . . . . .(2011) . . .

.. 1 . .Certificate Transparency [7] . . . . . . . . . . . . . . . . . . . . . . .(2012) . . .

.. 1 . .TACK [8] . . . . . . . . . . . . . . . . . . . . . . .(2012) . . .

.. 0 . .AKI [6] . . . . . . . . . . . . . . . . . . . . . . .(2013) . . .

.. 1 . .

. = offers the benefit; . = almost offers the benefit, . = does not offer the benefit.. = step required; . = step not required for MITMA.

TABLE IEVALUATION OF SSL VALIDATION SYSTEMS.

is User-Privacy-Preserving, since the IP address of the clientdoes not reach the notary during a query.

C. Certificate Transparency

Certificate Transparency [7] (CT) is currently being devel-oped by Ben Laurie, Adam Langley and Emilia Kasper atGoogle. When a certificate for a server has been signed bya CA, the server or the CA submits the certificate to a logserver. There need to be a small number of log servers thatperiodically check each other for consistency as well as queryupdates. The log servers insert the certificates into append-onlydata structures based on Merkle hash trees. The hash trees

ensure that tampering with the log is easily detectable andwould thus revoke trust in the log server. If a new certificateis added to the log, a new branch with a new root will beinserted into the tree, the old root eventually becoming a childof the new root. This means that the new tree can still proveconsistency for an older log.

The system has No-User-Costs as well as Quasi-No-Server-Cost-per-User, as a server need a signed X.509 certificates.

CT is not Browser-Compatible: The automated client-siderequest for appearance of a server’s certificate in the append-only logs has to be integrated into the Browser for CT to work.It is not Server-Compatible, since servers need to pass extra


Conclusion

. All proposals solve weakest link problem

. …but in very different ways

. No clear winner

. Do we want/need/have to have CAs?

. Deployment is challenging

. Question: When to fail hard?


IntroductionSolutionsNetwork PerspectiveCertificate LogDNSPinningEvaluation

OWASP AppSec Research 2013, 20.-23.08.2012, Hamburg : … · 2020. 1. 17. ·...

Documents

Transcript of OWASP AppSec Research 2013, 20.-23.08.2012, Hamburg : … · 2020. 1. 17. ·...