Crypto meets Web Security: Certificates and SSL/TLS Spring 2017 - - PowerPoint PPT Presentation

▶
crypto meets web security certificates and ssl tls
SMART_READER_LITE
LIVE PREVIEW

Crypto meets Web Security: Certificates and SSL/TLS Spring 2017 - - PowerPoint PPT Presentation

Aug 02, 2023 156 likes •537 views

CSE 484 / CSE M 584: Computer Security and Privacy Crypto meets Web Security: Certificates and SSL/TLS Spring 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, Yoshi Kohno, John

slide-1
SLIDE 1

CSE 484 / CSE M 584: Computer Security and Privacy

Crypto meets Web Security: Certificates and SSL/TLS

Spring 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu

Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, Yoshi Kohno, John Manferdelli, John Mitchell, Vitaly Shmatikov, Bennet Yee, and many others for sample slides and materials ...

slide-2
SLIDE 2

Announcements

  • Homework #2 (crypto) due Friday

– Individual assignment – Please send your encrypted email early!

  • Next part of course: web security
  • Section this week: physical security

5/1/17 CSE 484 / CSE M 584 - Spring 2017 2

slide-3
SLIDE 3

Public Key Crypto: Basic Problem

5/1/17 CSE 484 / CSE M 584 - Spring 2017 3

?

Given: Everybody knows Bob’s public key Only Bob knows the corresponding private key

private key

Goals: 1. Alice wants to send a secret message to Bob

  • 2. Bob wants to authenticate himself

public key public key

Alice Bob

slide-4
SLIDE 4

Last Week

  • Public key crypto protocols

– Based on underlying assumptions about hard problems – Diffie Hellman and RSA – Not in this course: elliptic curves

  • Last time: confidentiality (no integrity or

authentication)

5/1/17 CSE 484 / CSE M 584 - Spring 2017 4

slide-5
SLIDE 5

Digital Signatures: Basic Idea

5/1/17 CSE 484 / CSE M 584 - Spring 2017 5

?

Given: Everybody knows Bob’s public key Only Bob knows the corresponding private key

private key

Goal: Bob sends a “digitally signed” message

1. To compute a signature, must know the private key 2. To verify a signature, only the public key is needed

public key public key

Alice Bob

slide-6
SLIDE 6

RSA Signatures

  • Public key is (n,e), private key is (n,d)
  • To sign message m: s = md mod n

– Signing & decryption are same underlying operation in RSA – It’s infeasible to compute s on m if you don’t know d

  • To verify signature s on message m:

verify that se mod n = (md)e mod n = m

– Just like encryption (for RSA primitive) – Anyone who knows n and e (public key) can verify signatures produced with d (private key)

  • In practice, also need padding & hashing

– Standard padding/hashing schemes exist for RSA signatures

5/1/17 CSE 484 / CSE M 584 - Spring 2017 6

slide-7
SLIDE 7

DSS Signatures

  • Digital Signature Standard (DSS)

– U.S. government standard (1991, most recent rev. 2013)

  • Public key: (p, q, g, y=gx mod p), private key: x
  • Security of DSS requires hardness of discrete log

– If could solve discrete logarithm problem, would extract x (private key) from gx mod p (public key)

5/1/17 CSE 484 / CSE M 584 - Spring 2017 7

slide-8
SLIDE 8

Cryptography Summary

  • Goal: Privacy

– Symmetric keys:

  • One-time pad, Stream ciphers
  • Block ciphers (e.g., DES, AES) à modes: EBC, CBC, CTR

– Public key crypto (e.g., Diffie-Hellman, RSA)

  • Goal: Integrity

– MACs, often using hash functions (e.g, MD5, SHA-256)

  • Goal: Privacy and Integrity

– Encrypt-then-MAC

  • Goal: Authenticity (and Integrity)

– Digital signatures (e.g., RSA, DSS)

5/1/17 CSE 484 / CSE M 584 - Spring 2017 8

slide-9
SLIDE 9

Authenticity of Public Keys

5/1/17 CSE 484 / CSE M 584 - Spring 2017 9

?

Problem: How does Alice know that the public key she received is really Bob’s public key?

private key

Alice Bob

public key

slide-10
SLIDE 10

Threat: Man-In-The-Middle (MITM)

5/1/17 CSE 484 / CSE M 584 - Spring 2017 10

Google.com

slide-11
SLIDE 11

Distribution of Public Keys

  • Public announcement or public directory

– Risks: forgery and tampering

  • Public-key certificate

– Signed statement specifying the key and identity

  • sigCA(“Bob”, PKB)
  • Common approach: certificate authority (CA)

– Single agency responsible for certifying public keys – After generating a private/public key pair, user proves his identity and knowledge of the private key to obtain CA’s certificate for the public key (offline) – Every computer is pre-configured with CA’s public key

5/1/17 CSE 484 / CSE M 584 - Spring 2017 11

slide-12
SLIDE 12

Trusted Certificate Authorities

5/1/17 CSE 484 / CSE M 584 - Spring 2017 12

slide-13
SLIDE 13

Hierarchical Approach

  • Single CA certifying every public key is impractical
  • Instead, use a trusted root authority

– For example, Verisign – Everybody must know the public key for verifying root authority’s signatures

  • Root authority signs certificates for lower-level

authorities, lower-level authorities sign certificates for individual networks, and so on

– Instead of a single certificate, use a certificate chain

  • sigVerisign(“AnotherCA”, PKAnotherCA), sigAnotherCA(“Alice”, PKA)

– What happens if root authority is ever compromised?

5/1/17 CSE 484 / CSE M 584 - Spring 2017 13

slide-14
SLIDE 14

You encounter this every day…

5/1/17 CSE 484 / CSE M 584 - Spring 2017 14

SSL/TLS: Encryption & authentication for connections

slide-15
SLIDE 15

Example of a Certificate

5/1/17 CSE 484 / CSE M 584 - Spring 2017 15

slide-16
SLIDE 16

X.509 Certificate

5/1/17 CSE 484 / CSE M 584 - Spring 2017 16

slide-17
SLIDE 17

Many Challenges…

  • Hash collisions
  • Weak security at CAs

– Allows attackers to issue rogue certificates

  • Users don’t notice when attacks happen

– We’ll talk more about this later

  • Etc…

5/1/17 CSE 484 / CSE M 584 - Spring 2017 17

slide-18
SLIDE 18

Colliding Certificates

5/1/17 CSE 484 / CSE M 584 - Spring 2017 18

serial number validity period real cert domain name real cert RSA key X.509 extensions signature

identical bytes (copied from real cert) collision bits (computed) chosen prefix (difference)

serial number validity period rogue cert domain name ??? X.509 extensions signature

set by the CA

Hash to the same MD5 value! Valid for both certificates!

[Sotirov et al. “Rogue Certificates”]

slide-19
SLIDE 19

5/1/17 CSE 484 / CSE M 584 - Spring 2017 19

Attacking CAs

Security of DigiNotar servers:

  • All core certificate

servers controlled by a single admin password (Pr0d@dm1n)

  • Software on public-

facing servers out of date, unpatched

  • No anti-virus (could

have detected attack)

slide-20
SLIDE 20

Consequences

  • Attacker needs to first divert users to an attacker-

controlled site instead of Google, Yahoo, Skype, but then…

– For example, use DNS to poison the mapping of mail.yahoo.com to an IP address

  • … “authenticate” as the real site
  • … decrypt all data sent by users

– Email, phone conversations, Web browsing

5/1/17 CSE 484 / CSE M 584 - Spring 2017 20

slide-21
SLIDE 21

More Rogue Certs

  • In Jan 2013, a rogue *.google.com certificate

was issued by an intermediate CA that gained its authority from the Turkish root CA TurkTrust

– TurkTrust accidentally issued intermediate CA certs to customers who requested regular certificates – Ankara transit authority used its certificate to issue a fake *.google.com certificate in order to filter SSL traffic from its network

  • This rogue *.google.com certificate was trusted by

every browser in the world

5/1/17 CSE 484 / CSE M 584 - Spring 2017 21

slide-22
SLIDE 22

Certificate Revocation

  • Revocation is very important
  • Many valid reasons to revoke a certificate

– Private key corresponding to the certified public key has been compromised – User stopped paying his certification fee to this CA and CA no longer wishes to certify him – CA’s private key has been compromised!

  • Expiration is a form of revocation, too

– Many deployed systems don’t bother with revocation – Re-issuance of certificates is a big revenue source for certificate authorities

5/1/17 CSE 484 / CSE M 584 - Spring 2017 22

slide-23
SLIDE 23

Certificate Revocation Mechanisms

  • Certificate revocation list (CRL)

– CA periodically issues a signed list of revoked certificates

  • Credit card companies used to issue thick books of

canceled credit card numbers

– Can issue a “delta CRL” containing only updates

  • Online revocation service

– When a certificate is presented, recipient goes to a special online service to verify whether it is still valid

  • Like a merchant dialing up the credit card processor

5/1/17 CSE 484 / CSE M 584 - Spring 2017 23

slide-24
SLIDE 24

Attempt to Fix CA Problems: Convergence

  • Background observation:

– Attacker will have a hard time mounting man-in-the- middle attacks against all clients around the world

  • Basic idea:

– Lots of nodes around the world obtaining SSL/TLS certificates from servers – Check responses across servers, and also observe unexpected changes from existing certificates

http://convergence.io/

5/1/17 CSE 484 / CSE M 584 - Spring 2017 24

slide-25
SLIDE 25

Keybase

  • Basic idea:

– Rely on existing trust of a person’s ownership of other accounts (e.g., Twitter, GitHub, website) – Each user publishes signed proofs to their linked account

https://keybase.io/

5/1/17 CSE 484 / CSE M 584 - Spring 2017 25

slide-26
SLIDE 26

SSL/TLS

  • Secure Sockets Layer and Transport Layer Security

protocols

– Same protocol design, different crypto algorithms

  • De facto standard for Internet security

– “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications”

  • Deployed in every Web browser; also VoIP,

payment systems, distributed systems, etc.

5/1/17 CSE 484 / CSE M 584 - Spring 2017 26

slide-27
SLIDE 27

TLS Basics

  • TLS consists of two protocols

– Familiar pattern for key exchange protocols

  • Handshake protocol

– Use public-key cryptography to establish a shared secret key between the client and the server

  • Record protocol

– Use the secret symmetric key established in the handshake protocol to protect communication between the client and the server

5/1/17 CSE 484 / CSE M 584 - Spring 2017 27

slide-28
SLIDE 28

Basic Handshake Protocol

5/1/17 CSE 484 / CSE M 584 - Spring 2017 28

C

ClientHello

S

Client announces (in plaintext):

  • Protocol version it is running
  • Cryptographic algorithms it supports
  • Fresh, random number
slide-29
SLIDE 29

Basic Handshake Protocol

5/1/17 CSE 484 / CSE M 584 - Spring 2017 29

C

C, versionc, suitesc, Nc ServerHello

S

Server responds (in plaintext) with:

  • Highest protocol version supported by

both the client and the server

  • Strongest cryptographic suite selected

from those offered by the client

  • Fresh, random number
slide-30
SLIDE 30

Basic Handshake Protocol

5/1/17 CSE 484 / CSE M 584 - Spring 2017 30

C

versions, suites, Ns, ServerKeyExchange

S

Server sends his public-key certificate containing either his RSA, or his Diffie-Hellman public key (depending on chosen crypto suite)

C, versionc, suitesc, Nc

slide-31
SLIDE 31

Basic Handshake Protocol

5/1/17 CSE 484 / CSE M 584 - Spring 2017 31

C

versions, suites, Ns, certificate, “ServerHelloDone”

S

C, versionc, suitesc, Nc ClientKeyExchange

The client generates secret key material and sends it to the server encrypted with the server’s public key (if using RSA)

slide-32
SLIDE 32

Basic Handshake Protocol

5/1/17 CSE 484 / CSE M 584 - Spring 2017 32

C

versions, suites, Ns, certificate, “ServerHelloDone”

S

C, versionc, suitesc, Nc {Secretc}PKs if using RSA switch to keys derived from secretc , Nc , Ns

C and S share secret key material (secretc) at this point

switch to keys derived from secretc, Nc, Ns

Finished Finished

Record of all sent and received handshake messages

slide-33
SLIDE 33

“Core” SSL 3.0 Handshake (Not TLS)

5/1/17 CSE 484 / CSE M 584 - Spring 2017 33

C

versions=3.0, suites, Ns, certificate, “ServerHelloDone”

S

C, versionc=3.0, suitesc, Nc {Secretc}PKs if using RSA switch to keys derived from secretc , Nc , Ns

C and S share secret key material (secretc) at this point

switch to keys derived from secretc, Nc, Ns

Finished Finished

slide-34
SLIDE 34

Version Rollback Attack

5/1/17 CSE 484 / CSE M 584 - Spring 2017 34

C

Versions=2.0, suites, Ns, certificate, “ServerHelloDone”

S

C, versionc=2.0, suitesc, Nc {Secretc}PKs if using RSA

C and S end up communicating using SSL 2.0 (weaker earlier version of the protocol that does not include “Finished” messages)

Server is fooled into thinking he is communicating with a client who supports only SSL 2.0

slide-35
SLIDE 35

“Chosen-Protocol” Attacks

  • Why do people release new versions of security protocols?

Because the old version got broken!

  • New version must be backward-compatible

– Not everybody upgrades right away

  • Attacker can fool someone into using the old, broken version

and exploit known vulnerability

– Similar: fool victim into using weak crypto algorithms

  • Defense is hard: must authenticate version in early designs
  • Many protocols had “version rollback” attacks

– SSL, SSH, GSM (cell phones)

5/1/17 CSE 484 / CSE M 584 - Spring 2017 35

slide-36
SLIDE 36

Version Check in SSL 3.0

5/1/17 CSE 484 / CSE M 584 - Spring 2017 36

C

versions=3.0, suites, Ns, certificate for PKs, “ServerHelloDone”

S

C, versionc=3.0, suitesc, Nc {versionc, secretc}PKs C and S share secret key material secretc at this point “Embed” version number into secret Check that received version is equal to the version in ClientHello

switch to key derived from secretc, Nc, Ns switch to key derived from secretc, Nc, Ns