Certificate Authorities and SSL/TLS/HTTPS Fall 2016 Ada (Adam) - - PowerPoint PPT Presentation

▶
certificate authorities and
SMART_READER_LITE
LIVE PREVIEW

Certificate Authorities and SSL/TLS/HTTPS Fall 2016 Ada (Adam) - - PowerPoint PPT Presentation

Sep 15, 2022 166 likes •625 views

CSE 484 / CSE M 584: Computer Security and Privacy Certificate Authorities and SSL/TLS/HTTPS Fall 2016 Ada (Adam) Lerner lerner@cs.washington.edu Thanks to Franzi Roesner, Dan Boneh, Dieter Gollmann, Dan Halperin, Yoshi Kohno, John

slide-1
SLIDE 1

CSE 484 / CSE M 584: Computer Security and Privacy

Certificate Authorities and SSL/TLS/HTTPS

Fall 2016 Ada (Adam) Lerner lerner@cs.washington.edu

Thanks to Franzi Roesner, 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

Authenticity of Public Keys

11/2/16 CSE 484 / CSE M 584 - Fall 2016 2

?

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

private key

Alice Bob

public key

slide-3
SLIDE 3

Announcements

  • Lab 2 (web security) will be

coming out next Tuesday

11/2/16 CSE 484 / CSE M 584 - Fall 2016 3

slide-4
SLIDE 4

RSA decryption

  • Based on feedback and interest, not in

lecture

  • I’ve added a slide to lecture 12’s slides which

explains it (it’s slide 18)

11/2/16 CSE 484 / CSE M 584 - Fall 2016 4

slide-5
SLIDE 5

RSA decryption

  • On the interest scale of 1-5…

– ... someone answered 0 – ... someone answered 6 – …someone answered π – …someone answered 25

11/2/16 CSE 484 / CSE M 584 - Fall 2016 5

slide-6
SLIDE 6

Security mindset anecdote – Mining Your Ps and Qs

  • A 2012 study titled

“Mining your Ps and Qs: Detection of Widespread Weak Keys in Network Devices” Scanned the entire internet to look for weak public keys

11/2/16 CSE 484 / CSE M 584 - Fall 2016 6

slide-7
SLIDE 7

Mining Your Ps and Qs

  • They were able to determine the RSA

private key for 0.5% of HTTPS servers and 0.03% of SSH servers

  • How? Insufficient randomness. 0.5% of keys

shared a p or q with at least one other key (but not both).

11/2/16 CSE 484 / CSE M 584 - Fall 2016 7

slide-8
SLIDE 8

RSA Cryptosystem [Rivest, Shamir, Adleman 1977]

  • Key generation:

– Generate random large primes p, q

  • Say, 1024 bits each

– Compute n=pq and ϕ(n)=(p-1)(q-1) – Choose small e, relatively prime to ϕ(n)

  • Typically, e=216+1=65537

– Compute unique d such that ed = 1 mod ϕ(n)

  • Modular inverse: d = e-1 mod ϕ(n)

– Public key = (e,n); private key = (d,n)

  • Encryption of m: c = me mod n
  • Decryption of c: cd mod n = (me)d mod n = m

11/2/16 CSE 484 / CSE M 584 - Fall 2016 8

slide-9
SLIDE 9

Certificates

  • Public-key certificate

– Signed statement specifying the key and identity

  • sigCA(“Bob”, PKB)

11/2/16 CSE 484 / CSE M 584 - Fall 2016 9

slide-10
SLIDE 10

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

11/2/16 CSE 484 / CSE M 584 - Fall 2016 10

Google.com

slide-11
SLIDE 11

You encounter this every day…

11/2/16 CSE 484 / CSE M 584 - Fall 2016 11

SSL/TLS: Encryption & authentication for connections (More on this later!)

slide-12
SLIDE 12

Certificate Authority

  • Trusted organization that verifies who owns

what keys out of band and tells everyone else whose keys are whose

11/2/16 CSE 484 / CSE M 584 - Fall 2016 12

slide-13
SLIDE 13

Strawman CA design

  • 1. You browse to www.cs.washington.edu
  • 2. www.cs.washington.edu sends its key K
  • 3. Your browser asks a trusted CA: “hey, key K

the right key for UW CSE?”

  • 4. CA replies “yes” or “no”

Why is this a bad idea? (Q1)

11/2/16 CSE 484 / CSE M 584 - Fall 2016 13

slide-14
SLIDE 14

Real CA design

  • Think of a certificate as

a cryptographically hard-to-forge piece of ID

11/2/16 CSE 484 / CSE M 584 - Fall 2016 14

Certificate authority (e.g., Verisign

  • r Let’s

Encrypt) www.cs.washington.edu

<proof that I’m UWCSE and PKUWCSE is my key>

sigCA(“UWCSE”, PKUWCSE)

slide-15
SLIDE 15

Example Certificate

11/2/16 CSE 484 / CSE M 584 - Fall 2016 15

slide-16
SLIDE 16

Example Certificate

11/2/16 CSE 484 / CSE M 584 - Fall 2016 16

slide-17
SLIDE 17

X.509 Certificate

11/2/16 CSE 484 / CSE M 584 - Fall 2016 17

slide-18
SLIDE 18

Hierarchical Approach

  • Single CA certifying every public key is

impractical

  • Instead, one or more trusted root authorities

– Everybody must know the public key for verifying root authority’s signatures

  • CAs delegate to other authorities

– What happens if root authority is ever compromised?

11/2/16 CSE 484 / CSE M 584 - Fall 2016 18

slide-19
SLIDE 19

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?

11/2/16 CSE 484 / CSE M 584 - Fall 2016 19

slide-20
SLIDE 20

Many Challenges…

  • CAs make serious mistakes

– Bad security practices, bad operational practices

  • Revocation is hard…
  • Users don’t notice when attacks happen

– We’ll talk more about this later

11/2/16 CSE 484 / CSE M 584 - Fall 2016 20

slide-21
SLIDE 21

Mining Your Ps and Qs

  • Apache ships with a “snake-oil” certificate --

an example certificate for demonstrating how to set up HTTPS

  • A study found >85k hosts on the internet

(0.66% of all TLS hosts on the internet) actively using these keys!

  • 22 hosts had certificates using these keys

THAT WERE SIGNED BY A CA!

11/2/16 CSE 484 / CSE M 584 - Fall 2016 21

slide-22
SLIDE 22

11/2/16 CSE 484 / CSE M 584 - Fall 2016 22

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-23
SLIDE 23

Colliding Certificates

11/2/16 CSE 484 / CSE M 584 - Fall 2016 23

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-24
SLIDE 24

Consequences of Hacking a CA

  • Attacker makes themself a fake certificate for a site

(say, mail.yahoo.com): fakeCert = sigCA(“Yahoo”, <attacker’s key>)

11/2/16 CSE 484 / CSE M 584 - Fall 2016 24

slide-25
SLIDE 25

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

11/2/16 CSE 484 / CSE M 584 - Fall 2016 25

mail.yahoo.com

slide-26
SLIDE 26

Consequences of Hacking a CA

  • Attacker makes themselves a fake certificate for a

site (say, mail.yahoo.com): fakeCert = sigCA(“Yahoo”, <attacker’s key>)

  • An attacker can pretend to be any real site

– 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

11/2/16 CSE 484 / CSE M 584 - Fall 2016 26

slide-27
SLIDE 27

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

11/2/16 CSE 484 / CSE M 584 - Fall 2016 27

slide-28
SLIDE 28

Many Challenges…

  • CAs make serious mistakes

– Bad security practices, bad operational practices

  • Revocation is hard…
  • Users don’t notice when attacks happen

– We’ll talk more about this later

11/2/16 CSE 484 / CSE M 584 - Fall 2016 28

slide-29
SLIDE 29

Certificate Revocation (Q3)

11/2/16 CSE 484 / CSE M 584 - Fall 2016 29

slide-30
SLIDE 30

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 their 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

11/2/16 CSE 484 / CSE M 584 - Fall 2016 30

slide-31
SLIDE 31

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

11/2/16 CSE 484 / CSE M 584 - Fall 2016 31

slide-32
SLIDE 32

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/

11/2/16 CSE 484 / CSE M 584 - Fall 2016 32

slide-33
SLIDE 33

SSL/TLS

  • Secure Sockets Layer and Transport Layer Security

– Same protocol, new version (TLS is current)

  • 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.

11/2/16 CSE 484 / CSE M 584 - Fall 2016 33

slide-34
SLIDE 34

SSL/TLS

  • TLS is typically used on

top of a TCP connection

TLS

  • Can be used over other

transport protocols

11/2/16 CSE 484 / CSE M 584 - Fall 2016 34

slide-35
SLIDE 35

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

11/2/16 CSE 484 / CSE M 584 - Fall 2016 35

slide-36
SLIDE 36

Basic Handshake Protocol

11/2/16 CSE 484 / CSE M 584 - Fall 2016 36

C

ClientHello

S

Client announces (in plaintext):

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

Basic Handshake Protocol

11/2/16 CSE 484 / CSE M 584 - Fall 2016 37

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-38
SLIDE 38

Basic Handshake Protocol

11/2/16 CSE 484 / CSE M 584 - Fall 2016 38

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-39
SLIDE 39

Basic Handshake Protocol

11/2/16 CSE 484 / CSE M 584 - Fall 2016 39

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-40
SLIDE 40

Basic Handshake Protocol

11/2/16 CSE 484 / CSE M 584 - Fall 2016 40

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-41
SLIDE 41

“Core” SSL 3.0 Handshake (Not TLS)

11/2/16 CSE 484 / CSE M 584 - Fall 2016 41

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-42
SLIDE 42

Version Rollback Attack

11/2/16 CSE 484 / CSE M 584 - Fall 2016 42

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-43
SLIDE 43

“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)

11/2/16 CSE 484 / CSE M 584 - Fall 2016 43

slide-44
SLIDE 44

Version Check in SSL 3.0

11/2/16 CSE 484 / CSE M 584 - Fall 2016 44

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