SSL/TLS and HTTPS - PowerPoint Presentation

Slide1

SSL/TLS and HTTPS

Tyler

Moore

CS 7403

University of Tulsa

Many slides

adapted in part or whole from Dan

Boneh

, Stanford

CS155 and John Hale, TUSlide2

Goals for this lecture

Brief overview of HTTPS:

How the SSL/TLS protocol works

(briefly

)

How to use HTTPS

Integrating HTTPS into the browser

Lots of user interface problems to watch forSlide3

Threat Model: Network Attacker

Network

Attacker

Controls

network infrastructure:

Routers, DNSEavesdrops, injects, blocks, and modifies packetsExample 1: Wireless network at Internet CaféExample 2: Internet access at hotels (untrusted ISP)The TLS/SSL Solution deals with network attackersSecure and authenticated communication servicesPlatform and application independentUbiquitous session layer securitySlide4

Security Across Layers

Application layer security

Transport layer security

Network layer securitySlide5

Transport Layer Security (TLS)

Formerly known as SSL (TLS 1.2 latest version – 2008)

Negotiates and employs essential functions for secure transactions

Mutual Authentication

Data Encryption

Data IntegrityPrinciple of Economy of MechanismSecurity mechanisms should be as simple as possible

Principle of Psychological Acceptability

Security mechanisms should not make a resource more difficult to access than if the security mechanisms were not presentSlide6

TLS/SSL Security Services

Mutual authentication

Establish trust with intended recipients

Signed Digital Certificates

Server authenticates to client

Client authenticates to server (optional)Data encryption

Privacy and confidentiality

Support for different algorithms

Data Integrity

Ensure no tampering with data transmissions intentional or not

Freshness of transactions to avoid replaysSlide7

SSL/TLS overview

Alice

Enc

m

c

Bob

Dec

c

m

PK

Bob

SK

Bob

Bob generates (

SK

Bob

,

PK

Bob

)

Alice: using

PK

Bob

encrypts messages and only Bob can decrypt

Public-key encryption:Slide8

Certificates

How does Alice (browser) obtain

PK

Bob

?

CA

PK and

proof “I am Bob”

Browser

Alice

SK

CA

check

proof

issue Cert with SK

CA

:

Bob’s

key is PK

Bob’s

key is PK

choose

(SK,PK

)

Server Bob

PK

CA

Verify

c

ert

Bob uses

Cert for an extended period

(

e.g

. one year)

PK

CASlide9

Certificates: example

Important fields:Slide10

Certificates on the web

Subject’s

CommonName

can be:

An explicit name, e.g.

secon.utulsa.edu, orA wildcard cert, e.g. *.utulsa.edu or secon

*

.

utulsa.edu

matching rules:

“*” must occur in leftmost component, does not match “.” example: *.a.com

matches x.a.com but not y.x.a.com (as in RFC 2818: “HTTPS over TLS”)Slide11

Certificate Authorities

Browsers accept

certificates from a

large number of CAs

Top level CAs ≈ 60

Intermediate CAs ≈ 1200

⋮

⋮Slide12

Overview of SSL/TLS Handshake

browser

server

SK

P

1: client

-hello

P1: server

-hello +

P2: server

-cert (

PK

)

key exchange

(several options): EC-DHE

P4: Finished

cert

P2: client

-key-exchange

HTTP

data encrypted with KDF(k)

Most common: server authentication only

P2: server

-key-exchange

k

kSlide13

TLS

Handshake Protocol

DetailsSlide14

Initiates protocol and establishes security capabilities

version

: highest version understood by client

random

: 32-bit timestamp and 28 bytes generated by a secure random number generator (nonce)

session id: variable-length identifiersession id = 0 (client wants to initiate new session)session id ¹

0 (client wants to update parameters of existing connection)

cipher suite

: list of combinations of crypto algorithms supported by client, in decreasing order of preference

Key exchange methods (RSA, Diffie-Hellman, etc.)Bulk encryption (3DES, AES, etc.)MAC algorithm (MD5, SHA1, etc.)Cipher type, is-exploitable, has size, initialization vectorcompression methods

: list of compression algorithms supported by clientServer responds with a

server_hello message with the same parameters

Phase 1Slide15

Phase 2

Performs server authentication and key exchange

certificate

: X.509 certificate (optional, not necessary for anonymous Diffie-Hellman)

server key exchange message

: (optional, not necessary for fixed Diffie-Hellman or RSA key exchange)

certificate request message

: specifying the signature schema as well as a list of accepted certification authorities

hello done message

: closes up this phaseSlide16

Phase 3

Performs client authentication and key exchange

certificate message

client key exchange message

certificate verify

messageOptional, rarely usedSlide17

Phase 4

Wrap it up

change cipher spec message

finished message

: verify that the key-exchange and authentication process was successful

change cipher spec message

finished message

finished messages

are essentially hashes of the secret keys and of the whole handshake protocol (excluding the message)Slide18

Many options for key exchange

https://en.wikipedia.org/wiki/Transport_Layer_Security#

Key_exchange_or_key_agreementSlide19

Choice of key exchange method matters

RSA-based key exchange is most common configuration

Server’s private key encrypts session keys

Anyone with server’s private key can get session key, including network attacker who records encrypted traffic and later gets the key

Feature or a bug, depending on your perspective

Ephemeral Diffie-Hellman key exchange ensures forward secrecy: session keys not revealed if the server’s private key is revealed in the futureA bit slower than RSA for key exchangeNot as widely supported (though getting better)Google services now use by defaultBeware reuse of common parametersSlide20

Integrating SSL/TLS with HTTP: HTTPS

HTTPS encapsulates HTTP entirely over TLS

Entire HTTP protocol is encrypted, including request URL, headers and cookies

Because server IP addresses and ports are used by IP, these are revealed to a network attacker

Network attacker can still determine which clients are talking to which servers, and potentially even which pagesSlide21

Integrating SSL/TLS with HTTP:

HTTPS

Two complications

Web proxies

solution: browser sends

CONNECT domain-name before client-helloVirtual hosting: two sites hosted at same IP address. solution in TLS 1.1: SNI (June 2003)

client_hello_extension

:

server_name=cnn.com

implemented since FF2 and IE7 (vista)

web

proxy

web

server

corporate network

web

server

cert

CNN

cert

ABC

client-hello

server-cert ???Slide22

POODLE Downgrade Attack

For backwards compatibility, most TLS implementations support fallback to older (often insecure) versions

Padding Oracle on Downgraded Legacy Encryption (POODLE)

Discovered in Fall 2014 by Google Security Team

Middleperson attacker can force downgrade to SSL 3.0 (super old)

256 SSL 3.0 requests can obtain a byte of deciphered ciphertextSee CVE-2014-3566, CV#-2014-8730CountermeasuresOption 1: disable SSL 3.0 on client and server side (but some old clients don’t support TLS)Option 2: browsers and servers implement support for TLS_FALLBACK_SCSV, parameter to prohibit fallbackSlide23

Why is HTTPS not used for all web traffic?

C

rypto slows down web servers

(but not by much if done right)

Some ad-networks do not support HTTPS

(2015 stats: 20%)Reduced revenue for publishersIncompatible with virtual hosting (older browsers) March 2015: IE6 ≈ 1% (ie6countdown.com)Aug 2014: Google boosts ranking of sites supporting HTTPSSlide24

HTTPS in the BrowserSlide25

The lock icon: SSL indicator

Intended goal

:

Provide user with identity of page origin

Indicate to user that page contents were not

viewed or modified by a network attackerIn reality: many problems (next few slides)Slide26

When is the (basic) lock icon displayed

All elements on the page fetched using HTTPS

For all elements:

HTTPS cert issued by a CA trusted by browser

HTTPS cert is valid (e.g. not expired)

CommonName in cert matches domain in URLSlide27

The lock UI: help users authenticate site

uninformativeSlide28

The lock UI: Extended Validation Certs

Harder to obtain than regular certs

requires human at CA to approve cert request

no wildcard certs (e.g.

*.stanford.edu )

Helps block “semantic attacks”:

www.bankofthe

vv

est.com

note: HTTPS-EV and HTTPS are in the same originSlide29

A general UI attack: picture-in-picture

Trained users are more likely to fall victim to this

[JSTB’07]Slide30

HTTPS and login pages: incorrect usage

Users often land on login page over HTTP:

Type HTTP URL

into address bar

Google links to HTTP page

<form method="post"

action="

https

://onlineservices.wachovia.com/..."

View source:

(old site)Slide31

HTTPS and login pages: guidelines

General guideline:

Response to

http

://login.site.com

should be Redirect: https://login.site.com Slide32

Problems with HTTPS and the Lock IconSlide33

Problems with HTTPS and the Lock Icon

Upgrade from HTTP to HTTPS

Forged certs

Mixed content:

HTTP and HTTPS on the same page

Does HTTPS hide web traffic? Problems: traffic analysis, compression attacksSlide34

1. HTTP  HTTPS upgrade

Common use pattern:

browse site over HTTP; move to HTTPS for checkout

connect to bank over HTTP; move to HTTPS for login

SSL_strip

attack: prevent the upgrade [Moxie’08] <a href=https://…>  <a href=http://…> Location:

https

://...



Location: http://... (redirect)

<form action=https://… >  <form action=http://…>

web

server

attacker

SSL

HTTPSlide35

Tricks and Details

Tricks:

drop-in a clever

fav

icon

(older browsers)⇒ fav icon no longer presented in address barMore tricks: inject “Set-cookie” headers to delete existing session cookies in browser. Force login.Number of users who detected HTTP downgrade: 0

Slide36

Defense: Strict Transport Security (HSTS)

Header tells browser to always connect over HTTPS

S

ubsequent visits must be over HTTPS

(self signed certs result in an error)

Browser refuses to connect over HTTP or if self-signed certRequires that entire site be served over HTTPSHSTS flag deleted when user “clears private data” : security vs. privacy

web

server

Strict-Transport-

Security: max

-age

=31⋅10

6

; includeSubDomains

(ignored if not over HTTPS)Slide37

CSP:

upgrade-insecure-

requests

The problem: many pages use

<

img src=“http://site.com/img”>Makes it difficult to migrate site to HTTPSSolution:

Always

use protocol relative URLs

<

img

src=“//site.com/img

”>

<img src=“https://site.com/

img”><img

src

=“

https

:

//

othersite.com

/

img

”>

<a

href

=“

http

:/

/

othersite.com

/

img

”>

Content-Security-Policy: upgrade-insecure-requests

<

img

src

=“

http

://

site.com

/

img

”>

<

img

src

=“

http

://

othersite.com

/

img

”>

<a

href

=“

http

:/

/othersite.com/img”>Slide38

2. Certificates: wrong issuance

2011

:

Comodo

and DigiNotar CAs hacked, issue certs for Gmail, Yahoo! Mail, …2013: TurkTrust issued cert. for gmail.com (discovered by pinning)2014: Indian NIC (intermediate CA trusted by the root CA IndiaCCA) issue certs for Google and Yahoo! domains Result: (1) India CCA revoked NIC’s intermediate certificate

(2) Chrome restricts India CCA root to only seven Indian domains

2015: MCS

(intermediate CA cert issued by CNNIC) issues certs for Google domains

Result: CNNIC root no longer recognized by Chrome⇒ enables eavesdropping w/o a warning on user’s sessionSlide39

Middleperson attack using rogue cert

Attacker proxies data between user and bank.

Sees all traffic and can modify data at will.

bank

attacker

ClientHello

ClientHello

BankCert

Badguy

Cert

ServerCert

(

Bank

)

ServerCert

(

rogue

)

GET

https

://bank.com

SSL key exchange

SSL key exchange

k

1

k

1

k

2

k

2

HTTP data enc with k

1

HTTP data enc with k

2

(cert for Bank by a valid CA)Slide40

What to do? (many good ideas)

HTTP public-key pinning, TACK

Let

a

site declare CAs

that can sign its cert (similar to HSTS)on subsequent HTTPS, browser rejects certs issued by other CAsTOFU: Trust on First UseCertificate Transparency: [LL’12]idea: CA’s must advertise a log of all certs. they issuedBrowser will only use a cert if it is published on log server

Efficient implementation using

Merkle

hash trees

Companies can scan logs to look for invalid issuanceSlide41

3. Mixed Content: HTTP and HTTPS

Page loads over HTTPS, but contains content over HTTP

(e.g. <script

src

=“

http://.../script.js> ) ⇒ Active network attacker can hijack session by modifying script en-route to browserIE7:

C

hrome:

n

ever write this

Chrome policy: CSS, script, frame: blocked; images, XHR: allowedSlide42

4. Peeking through SSL: traffic analysis

Network traffic reveals length of HTTPS packets

TLS supports up to 256 bytes of padding

AJAX-rich pages have lots and lots of interactions with the server

These interactions expose specific internal state of the page

BAM!Chen, Wang, Wang, Zhang, 2010Slide43

Peeking through SSL: an example

[CWWZ’10]

Vulnerabilities in an online tax application

No easy fix. Can also be used to ID Tor traffic