PROVING WHO YOU ARE TLS & THE PKI · TLS & THE PKI CMSC 414 MAR 29 2018. RECALL OUR PROBLEM WITH...

PROVING WHO YOU ARETLS & THE PKI

CMSC 414MAR 29 2018

RECALL OUR PROBLEM WITH DIFFIE-HELLMAN

The two communicating parties thought, but did not confirm, that they were talking to one another.

Therefore, they were vulnerable to MITM attacks.

Certificates allow us to verify with whom we are communicating.

We will solve this by incorporating public key cryptography

Back to authenticationHow can we know it was really who posted PK?

Back to authenticationGenerate public/private key pair (PK,SK); publicize PK

How can we know it was really who posted PK?

Back to authentication

Alice Bob

KAT KBT

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

Generate public/private key pair (PK,SK); publicize PK

Back to authentication

Alice Bob

KAT KBT

E(KAT, msg || to:Bob) E(KBT, msg || from:Alice)

Generate public/private key pair (PK,SK); publicize PK

Can we achieve authenticationwithout Trent in the middle of every message?

Authentication with public keys

1. Trent’s public key is widely disseminated (pre-installed in browsers/operating systems)

(PKT, SKT)Trent

2. Alice generates a public/private key pair and asks Trent to bind her

PKA to her identity

(PKT, SKT)

(PKA, SKA)

PKA to her identity

(PKT, SKT)

(PKA, SKA)

Trent vets Alice

PKA to her identity

(PKT, SKT)

(PKA, SKA)

Trent vets Alice

3. Trent signs a message (with SKT):

“The owner of the secret key corresponding to PKA is Alice”

PKA to her identity

(PKT, SKT)

(PKA, SKA)

Trent vets Alice

This message + sig = Certificate

PKA to her identity

(PKT, SKT)

(PKA, SKA)

Trent vets Alice

Alice = PKA

4. Alice makes her certificate publicly available

(or Bob simply asks for it)(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

(or Bob simply asks for it)(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

(or Bob simply asks for it)

5. Bob verifies the certificate using PKT

(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

If Bob trusts Trent, then Bob trusts that he properly

vetted Alice, and thus that her public key is PKA

(PKT, SKT)

(PKA, SKA)PKT

6. Bob (via hybrid encryption) sends a message to Alice using her public key PKA

Alice = PKA

If Bob trusts Trent, then Bob trusts that he properly

vetted Alice, and thus that her public key is PKA

(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

Trent vets Alice

Properties

(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

Trent vets AliceTrent need be online only

when giving out certificates, not any time users want to

communicate with one another

Properties

(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

Trent vets AliceTrent need be online only

when giving out certificates, not any time users want to

communicate with one another

Alice and Bob can communicate in an authenticated manner

without having to go through Trent

Properties

(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

1. Do not read messages2. Do not alter messages3. Do not forge messages

4. Do not go offline

Trust assumptions from our symmetric key protocol:

Trent vets Alice

(PKT, SKT)

(PKA, SKA)PKT

Alice = PKA

1. Do not read messages2. Do not alter messages3. Do not forge messages

4. Do not go offline

Trust assumptions from our symmetric key protocol:

Trent vets Alice

1. Correctly vet users

Trust assumptions in this public key protocol:

(Some more in practice…)

TLS/SSL• TLS (Transport Layer Security)

• A suite of protocols to provide secure communication - Confidentiality by applying block & stream ciphers - Integrity with MACs - Authenticity with certificates

• Predecessor: SSL (secure sockets layer) - TLS was proposed as an upgrade - All versions of SSL are considered insecure (recently, the

POODLE—padding oracle—attack)

Host A Host BTCP/IP

TLS or SSL

TCP/IP: Host A and B can send packets to one another

TLS/SSL: operate “over” TCP/IP toensure security/authenticity

TLS/SSL protocol (high level)Browser

(initiates connection)Server

(authenticates itself)

~~~~~~~Switch to negotiated cipher~~~~~~~Data transmission

Version, crypto options, nonceClient hello

Version, crypto options, nonce, Signed certificate containing the server’s public key PKs

Server hello + server cert (PKs)

Server key exchange (when using DH)

PreMaster secret encrypted with server’s PKsClient key exchangeCompute

K basedon nonces &PreMaster

Compute K based

on nonces &PreMaster

(Credit: CloudFlare)

Only the server with the private key should be able to decrypt

(Credit: CloudFlare)

Only the server with the private key should be able to sign

AUTHENTICATED DIFFIE-HELLMAN

Both of these serve as a “challenge/response” protocol:

The client is “challenging” the server to prove that it knows the secret key corresponding to the public key in the certificate

The server is providing a “zero-knowledge proof”:

The server proves that it knows the secret key without having to reveal the secret key itself

The key property that makes this work: The only person who knows the secret key is the entity in the certificate

Certificate revocation3. Trent signs a message (with SKT):

Put another way: “The only person who knows SKA is Alice”

What happens if Alice’s key gets compromised?(Stolen, accidentally revealed, …)

Certificate revocation

(PKT, SKT)Trent

Please revoke my certificate (ID #3912…)

(PKT, SKT)Trent

Trent signs a message (with SKT):

“Certificate ID #3912… is no longer valid, as of April 5, …”

(PKT, SKT)Trent

This message + sig = revocation

(PKT, SKT)Trent

This message + sig = revocation

BobBob obtains revocation information

Obtaining revocation data

Certificate Revocation Lists (CRLs)

A (often large) signed list of revocations

Browsers and OSesoccasionally download CRLs

Disincentive: CRLs can be large, so it takes time & bandwidth

Result: delayed days/weeks/forever

Online Certificate Status Protocol (OCSP)

Browsers and OSes perform OCSP checks on-demand (when verifying the certificate)

Is certificate ID #3912… still valid?

“Certificate ID #3912… is still longer valid, as of April 5, …” SKT

Disincentive: Still delays the initial validation of the certificate (can increase

webpage load time)

“Certificate ID #3912… is still longer valid, as of April 5, …” SKT

OCSP Stapling

“Certificate ID #3912… is still longer valid, as of April 5, …”

Websites issue OCSP requests, include responses in initial handshake

Is certificate ID #3912… still valid?Alice

Alice forwards this to Bob along withthe certificate when they first

start to communicate

Certificate revocation responsibilities

Trent’s responsibility: Make revocations publicly available

Alice’s responsibility: Request revocations

Bob’s responsibility: Check for revocations

Certificates in the wildThe lock icon indicates that the browser was able to authenticate the other end, i.e., validate its certificate

Certificate chain

Subject (who owns thepublic key)

Issuer (who verified the identity and signed this certificate)

Common name: the URL of the subject

Browser

Verifying certificates

Certificate“I’m because says so”

Browser

“I’m because I say so!”Certificate

Browser

Root key storeEvery device has one

Must not contain

malicious certificates

Browser

“I’m because I say so!”Certificate✓

Browser

Serial number: Uniquely identifies this cert with respect to the issuer

(look for this in CRLs)

Not valid before/after: When tostart and stop believing this cert

(start & expiration dates)

The public key: And the issuer’ssignature of the public key

Signature algorithm: How theissuer will sign parts of the cert

Subject Alternate Names:Other URLs for which this cert should be considered valid.

(wellsfargo.com is not the sameas www.wellsfargo.com)

Can include wildcards, e.g.,

*.google.com

Subject Alternate Names:The spirit is that it representsdifferent domain names of the

same entity (google.com, google.co.uk, youtube.com, …)

The letter of the rule doesn’t say that they need to be the same

company—or really haveanything in common

Subject Alternate Names:The spirit is that it representsdifferent domain names of the

same entity (google.com, google.co.uk, youtube.com, …)

The letter of the rule doesn’t say that they need to be the same

company—or really haveanything in common

Subject Alternate Names:Other URLs for which this cert should be considered valid.

(wellsfargo.com is not the sameas www.wellsfargo.com)

Can include wildcards, e.g.,

*.google.com

CRL & OCSP:Where to go to check if this

certificate has been revoked

Non-cryptographic checksums

Certificate typesCertificates can be classified in two broad ways

What the certificate can be used for

The type of vetting process used

Signing (root and intermediate certs)

DV (Domain validation) Prove administrative access to the domain, e.g., by uploading a fileOV (Organization validation) Prove ownership of the organization that owns the domain

Encrypting (leaf certs)

EV (Extended validation) More extensive validation ($$)

Certificate typesWhy are these different?

This is an EV (extended validation) certificate; browsers show the

full name for these kinds of certs

Proper reaction to Heartbleed

1. Patch the software

2. “Reissue” a new key (get a new one and load it onto your servers)

3. Revoke the old key

Proper reaction to Heartbleed

1. Patch the software

2. “Reissue” a new key (get a new one and load it onto your servers)

3. Revoke the old key

If we reissued and then patched, then our new key would be compromised, too.

Order matters!

If we revoked first, we’d be offline.

Heartbleed

OpenSSL

Heartbleed

OpenSSL“hi” 2

Heartbleed

OpenSSL“hi” 2

“hi”

Heartbleed

OpenSSL

Heartbleed

OpenSSL“hi” 22

Heartbleed

OpenSSL“hi” 22

“hi”+20B from memory

Heartbleed

OpenSSL“hi” 22

“hi”+20B from memory

Potentially reveals user data and private keys

Heartbleed exploits were undetectable

Why study Heartbleed?

03/21 04/02 04/07

DiscoveredAkamaipatched Publicly announced

03/21 04/02 04/07

1 Patched 2 Revoked 3 Reissued

Every vulnerable website should have:

03/21 04/02 04/07

1 Patched 2 Revoked 3 Reissued

Every vulnerable website should have:

Heartbleed is a natural experiment: How quickly and thoroughly do administrators act?

Dataset

Rapid7data

22M certs(~1/wk for 6mos)

Dataset

Rapid7data

AlexaTop-1M

2.8M certs

9k certs

filter

validate Leaf Set

628k certs165k domains

Dataset

Rapid7data

AlexaTop-1M

2.8M certs

9k certs

filter

validate Leaf Set

Dataset

Rapid7data

AlexaTop-1M

2.8M certs

9k certs

filter

• Download CRLs• Detect vulnerability• Identify Heartbleed-induced

reissues & revocations

validate Leaf Set

Dataset

Rapid7data

AlexaTop-1M

2.8M certs

9k certs

filter

• Download CRLs• Detect vulnerability• Identify Heartbleed-induced

reissues & revocations

Prevalence and patch rates

0 200000 400000 600000 800000 1e+06

Alexa Site Rank (bins of 1000)

Was ever vulnerableStill vulnerable

Was ever vulnerableStill vulnerable after 3 weeks

0 200000 400000 600000 800000 1e+06

Patching rates are mostly positiveOnly ~7% had not patched within 3 weeks

Certificate update rates

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

3 wksIdeal

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

3 wksIdeal

After 3 weeks: 13% Revoked

Similar pattern to patches: Exponential drop-off, then levels out

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Certificate update ratesIdeal

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not reissued

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not reissued

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

After 3 weeks: 13% Revoked 27% Reissued

Not reissued

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Optimistic

Not reissued

Not revoked

How quickly were certs revoked?

03/01 03/08 03/15 03/22 03/29 04/05 04/12 04/19 04/26

Reaction ramps up quickly

03/01 03/08 03/15 03/22 03/29 04/05 04/12 04/19 04/26

Security takes the weekends off

Weekends

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

0.6 0.65

0.7 0.75

0.8 0.85

0.9 0.95

04/07 04/21 05/05 05/19 06/02 06/16 06/30 07/14 07/28

. of V

Not reissued

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not reissued

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not reissued

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Not reissued

Not revoked

0.65 0.7

0.75 0.8

0.85 0.9

0.95 1

04/07 04/11 04/15 04/19 04/23 04/27

. of V

Optimistic

Not reissued

Not revoked

11/2013 12/2013 01/2014 02/2014 03/2014 04/2014 05/2014

Date of Birth

All reissuesHeartbleed-induced reissues

Reissue ⇒ New key?

11/2013 12/2013 01/2014 02/2014 03/2014 04/2014 05/2014

Date of Birth

11/2013 12/2013 01/2014 02/2014 03/2014 04/2014 05/2014

Date of Birth

Reissuing the same key is common practice

4.1% Heartbleed-induced

The ugly truth of revocations

13% Revoked 27% Reissued93% Patched

• Administrators trade off security for ease of maintenance/cost• Certificate authorities trade off security for profit

Security is supposed to be a fundamental design goal, but

0 1 2 3 4 5 6

Years of Remaining Validity

Can we wait for expiration?

0 1 2 3 4 5 6

Vulnerable but not revoked

0 1 2 3 4 5 6

~40% of vulnerable certswill not expire for over 1 year

0 1 2 3 4 5 6

We may be dealing with Heartbleed for years

~40% of vulnerable certswill not expire for over 1 year

Testing browser behavior

Revocationprotocols

• Browsers should support all major protocols• CRLs, OCSP, OCSP stapling

Availability of revocation info

• Browsers should reject certs they cannot check• E.g., because the OCSP server is down

Chain lengths

• Browsers should reject a cert if any on the chain fail• Leaf, intermediate(s), root

Revocationprotocols

Chain lengths

Intermediate Intermediate…

Revocationprotocols

Chain lengths

Revocationprotocols

Chain lengths

Revocationprotocols

Chain lengths

Results across all browsers

✔ Passes test ✗ Fails test

ev Passes for EV certsi Ignores OCSP Staple

a Pops up alert to userl/w Passes on Linux/Win.

Chrome

Generally, only checks for EV certs~3% of all certs

Allows if revocation info unavailable

Supports OCSP stapling

Firefox

Never checks CRLsOnly checks intermediates for EV certs

Allows if revocation info unavailable

Safari

Checks CRLs and OCSP

Allows if revocation info unavailableExcept for first intermediate, for CRLs

Does not support OCSP stapling

Internet Explorer

Checks CRLs and OCSP

Often rejects if revocation info unavailablePops up alert for leaf in IE 10+

Mobile Browsers

Uniformly never check

Android browsers request Staple

…and promptly ignore it

PKI CONCLUSION

The PKI’s job is to bind human-understandable identities (domain names) to cryptographic keys (public keys)

The central mechanism for this is certificates: digital signatures from trusted entities that tie domain names and public keys together

TLS along with Diffie-Hellman leverages public key crypto to arrive at ephemeral session keys (symmetric keys)

There is significant mismanagement in today’s PKI: • Websites don’t revoke or get new certs (“reissue”) when they should • Browsers don’t check for revocations when they should • Websites share their private keys with their hosting providers

The PKI is how we know with whom we are communicating online

Improving the web’s PKI is an active area of research (securepki.org)

PROVING WHO YOU ARE TLS & THE PKI · TLS & THE PKI CMSC 414 MAR 29 2018. RECALL OUR PROBLEM WITH...

Documents

Transcript of PROVING WHO YOU ARE TLS & THE PKI · TLS & THE PKI CMSC 414 MAR 29 2018. RECALL OUR PROBLEM WITH...

Diffie hellman

Rennes, 23/10/2014 Cristina Onete maria-cristina.onete@irisa.fr Key-Exchange Protocols. Diffie-Hellman, Active Attacks, and TLS/SSL.

Curs 10 - Demo PKI & TLSelf.cs.pub.ro/gsr/res/cursuri/curs-10.pdf · CSE Dep, RLUG Curs 10, Demo PKI & TLS 1/15. Cuprins PKI TLS Resurse utile CSE Dep, RLUG Curs 10, Demo PKI & TLS

BÀI TẬP DIFFIE-HELLMAN & RSA

CriptoSimetrica Algoritmos Diffie Hellman RSA Gamal

IMiS /iDMS Priročnik · šifriranjem (PKI/TLS). Vse parametre komunikacije s storitvijo določa storitev. Za dodatno zaščito in upravljanje aplikacije lahko uporabniki izberejo

Duke Energy Emerging Technology Office · Public Key Infrastructure (PKI) with a pre-configured shared Certificate Authority (CA) •Digital Signature Algorithm (DSA) with Diffie-Hellman

Web Security: PKIdigicert.com +1 (801) 877-2100 SSL/TLS: Friend or Foe? Scott Rea : Sr. PKI Architect Public Key Infrastructure (PKI) underpins the security and trust infrastructure

Diffie Hellman Presentacion

Certificates, Trust & PKI - courses.cs.washington.edu...February 21, 2006 Practical Aspects of Modern Cryptography 4 SSL/TLS You (client) Merchant (server) Let s talk securely. Here

Curs 9 - PKI & TLSelf.cs.pub.ro/gsr/res/cursuri/curs-09.pdf · Curs 9 PKI & TLS Gestiunea serviciilor de ret, ea (GSR) 8 decembrie 2016 Departamentul de Calculatoare, Comunitatea

Effective Security: Defending against Encrypted threats€¦ · TLS ServerHello Server’s Diffie-Hellman key { Certificate for } { Session key (encrypted with private key) } Partial

O-Saft Richtig verschlüsseln mit SSL/TLS€¢ Starker Diffie-Hellman-Parameter (≥ 2048 Bit) OWASP Day Germany 2014, Hamburg: Richtig verschlüsseln mit SSL/TLS 9. Dezember 2014

PKI - Fonctionnement d'Une PKI

PKI-Contacts - PKI für Fraunhofer Kontakte · Fraunhofer Competence Center PKI PKI-Contacts - PKI für Fraunhofer Kontakte Anleitung für Kommunikationspartner der Fraunhofer-Gesellschaft

Key Management and Diffie-Hellman

Cisco IOS PKI Overview Understanding and Planning a PKI · Cisco IOS PKI Overview Understanding and Planning a PKI CiscoIOSpublickeyinfrastructure(PKI)providescertificatemanagementtosupportsecurityprotocols

Intercambio de Llaves Diffie Hellman

PKI Mecanisme d Authentification Fort PKI

Implementasi Protokol Diffie-Hellman Dan Algoritma RC4 ...dalam makalah Diffie dan Hellman yang didefinisikan sebagai kriptografi kunci publik dan biasanya disebut sebagai Diffie-Hellman