How Secure is TLS?miTLS: a verified reference implementation

Cédric FournetwithKarthikeyan Bhargavan, Antoine Delignat-Lavaud, Markulf Kohlweiss,Alfredo Pironti, Pierre-Yves Strub, Santiago Zanella Beguelin

https://www.miTLS.org

2015 TLS 1.3?

SChannel, OpenSSL, NSS, GnuTLS, JSSE, PolarSSLstill patched every month! + Snowden allegations

Well-understood, detailed specsmany security theorems…mostly for small simplified models of TLS

Threat modelSecurity Goal

connect(server,port);

send(d1);

send(d2);

send(d3);

…

accept(port);

d1’ = recv();

d2’ = recv();

d3’ = recv();

…

authentication

infrastructure

Security Goal

X.509 public-key

infrastructure

connect(server,port);

send(d1);

send(d2);

send(d3);

…

accept(port);

d1’ = recv();

d2’ = recv();

d3’ = recv();

…

Client Server

Client Server

Client Server

Client Server

Protocol Logic

e.g. ambiguous messages

• cause clients and server

to negotiate weak sessions

Cryptography

e.g. not enough randomness

• write applet to realize

adaptive attack (BEAST)

Weak Algorithms

MD5, PKCS1, RC4, …

Implementation Bugs

many critical errors

TLS

DESIGN

Many obsolete crypto constructions

•

•

•

•

•

CountermeasuresDisable these features:

SSL3, compression, RC4

Implement mitigations

very very carefully:

• empty fragment

to initialize IV

for TLS 1.0 AES-CBC

• constant-time mitigation

for Bleichenbacher attacks

• constant-time plaintext

length-hiding HMAC to

prevent Lucky 13

The duplicate goto always branches

to the end of the function with err = 0

The key is not bound to the

server signing-key certificate

Implementation Bugs

many critical errors

then GnuTLS, Mar’14

then Heartbleed,OpenSSL, April’14

then Poodle, Sep’14

Memory safety Buffer overruns leak secrets

Missing checks Forgetting to verify signature/MAC/certificatebypasses crypto guarantees

Certificate validationASN.1 parsing, wildcard certificates

State machine bugsMost TLS implementations don’t conform to specUnexpected transitions break protocol (badly)

(EarlyCCS, OpenSSL, …)

Implementation Bugs

many critical errors

Test results for OpenSSL:

each arrow is a bug

IEEE Security & Privacy 2015

Protocol Logic

e.g. ambiguous messages

• cause clients and server

to negotiate weak sessions

Cryptography

e.g. not enough randomness

• write applet to realize

adaptive attack (BEAST)

Weak Algorithms

MD5, PKCS1, RC4, …

Implementation Bugs

many critical errors

TLS

DESIGN

Infrastructure

certificate management

Application

HTTPS clients & servers

Infrastructure

certificate management

Application

HTTPS clients & servers

IEEE Security & Privacy 2014

HTTP/1.1 302 RedirectLocation: https://x.com/PSet-Cookie: SID=[SessionToken]; secureContent-Length: 0

Many web services rely

on session tokens to

authenticate their users

The secure cookie attribute

tells the client browser that

the cookie is HTTPS-only

Many browsers silently

process truncated

HTTP (e.g. images)

After truncation,

any fake HTTP query leaks

the authentication token

Demo: hijacking

Google & Facebook

user accounts

Browser vulnerable

to truncations?Header Body (Length) Body (Chunked)

Android 4.2.2 YES YES YES

Chrome 27 YES YES YES

Chrome 28 NO NO YES

Firefox 24 NO YES YES

Safari Mobile 7.0.2 YES YES YES

Opera Mini 7.5 YES YES YES

Opera Classic 12.1 YES YES YES

Internet Explorer 10 NO YES YES

https://www.secure-resumption.com/

Client TLS library

Chromium

Opera 15+NSS

Internet

ExplorerSChannel

Safari &

Apple mail

Secure

Transport

Apple MailSecure

Transport

CURL OpenSSL

CURL GnuTLS

Wget OpenSSL

NodeJS HTTPS OpenSSL

PHP SSL

TransportOpenSSL

Apache

HttpClientJSSE 1.7

SVN / Neon OpenSSL

SVN / Neon OpenSSL

Cadaver/Neon OpenSSL

Git / CURL GnuTLS

Protocol Logic

e.g. ambiguous messages

• cause clients and server

to negotiate older weaker TLS

Cryptography

e.g. no fresh IV

• write applet to realize

adaptive attack (BEAST)

Weak Algorithms

MD5, PKCS1, RC4, …

Implementation Bugs

many critical errors

TLS

DESIGN

Infrastructure

certificate management

Application

HTTPS clients & servers

IEEE Security & Privacy 2013

https://www.miTLS.org

TLS negotiates its use of cryptography

Not all algorithms are equal!Cautionary tale: ECDHE considered safest,open to attack for 2 years due to bug in elliptic curve fast multiplication

Clients and servers should get security for the ciphersuite they prefer, not the weakest they support

Circular dependency: TLS relies onthe ciphersuites being negotiated

We verify TLS generically,for multiple ciphersuites & algorithms

This requires new cryptographic models

symmetric

encryption

(AES-CBC)Cryptographic algorithms

symmetric

encryption

(RC4)

Secure RPC

some

application code

TLS 1.2

Applications & Adversaries

Security protocols

Cryptographic constructionsencrypt

then-MACfragment-MAC-

encode-then-encrypt

some

attacksome

attack

some

attack

message

authentication

(SHA1)

INT-CMA IND-CPA

authenticated encryption

secure channel

TLS.fs7

TLS.fs

TLS.fsi

Type

(F7)

Prove

(Z3)

Compile

(F#)

Erase types

Handshake.fs7

Record.fs7

Modular Type-checking

Modules for miTLS

TLS.fs7

TLS.fs

TLS.fsi

Type

(F7)

Prove

(Z3)

Compile

(F#)

Erase types

Handshake.fs7

Record.fs7

KEM

DHGroup

DH

KEF

KDF/

MAC

RSA

Cert

Sig

SessionDB StAE

LHAE

Enc

MAC

Record

Dispatch

TCP

Untyped Adversary

Encode

LHAEPlain

StPlain

TLSFragmentAlertDatastream

Handshake (and CCS)

TLSInfoTLSConstants

Handshake/CCS

TLS

Record

AppData

Base Bytes

Untyped APIAdversary

RPC

RPCPlainApplication

TLS API

Alert

Protocol

AppData

Protocol

Nonce

TLS

CoreCrypto

RSAKey

Auth

AuthPlain

Extensions

1

2

3 4 5

6 7

Range

8

9

Error

type connection // for each local instance of the protocol

// creating new client and server instances

val connect: TcpStream -> params -> (;Client) nullconnection Result

val accept: TcpStream -> params -> (;Server) nullconnection Result

// triggering new handshakes, and closing connections

val rehandshake: c:connection{Role(c)=Client} connection Result

val request: c:connection{Role(c)=Server} connection Result

val shutdown: c:connection TcpStream Result

// writing data

type (;c:connection,data:(;c) msg_o) ioresult_o =

| WriteComplete of c':connection

| WritePartial of c':connection * rest:(;c') msg_o

| MustRead of c':connection

val write: c:connection -> data:(;c) msg_o -> (;c,data) ioresult_o

// reading data

type (;c:connection) ioresult_i =

| Read of c':connection * data:(;c) msg_i

| CertQuery of c':connection

| Handshake of c':connection

| Close of TcpStream

| Warning of c':connection * a:alertDescription

| Fatal of a:alertDescription

val read : c:connection -> (;c) ioresult_i

concrete TLS & ideal TLSare computationally indistinguishable

miTLS

implementation

miTLS typed API

Bytes, Network

lib.fs

Cryptographic Provider

cryptographic assumptions

any program

representing the

adversary

applicationdata stream

miTLS ideal

implementation

miTLS typed API

application

Safe, except for a

negligible probabilitySafe by typing

(info-theoretically)

7,000 lines of F# checked against3,000 lines of F7type annotations

+

3,000 lines of EasyCryptfor the core key exchange

miTLS

implementation

miTLS typed API

Bytes, Network

lib.fs

Cryptographic Provider

cryptographic assumptions

any program

representing the

adversary

applicationdata stream

miTLS ideal

implementation

miTLS typed API

application

reference code vs production code

Sufficient for simple applications.

We miss system engineering:custom memory manager,crypto hardware acceleration,low-level countermeasures…

We are considering building a lower-level, lightweight, verified implementation of TLS

305 292419

20 57 45

miTLS OpenSSL JSSE

Handshake (Sessions/S)RSA

DHE

0

50

100

150

200

250

Transport

Layer (MB/S)

RC4-MD5

RC4-SHA

3DES-SHA

AES128-SHA

AES128-SHA256

AES256-SHA

AES256-SHA256

We account for some side-channels, not for timing

1. verification tools: F7, Z3, EasyCryptnow: mechanized theory using Coq/SSReflect

next: certified F* tools and SMT solver

2. cryptographic assumptionsnow: concrete reductions using Easycrypt

next: mechanized proofs using relational probabilistic logic

3. the F# compiler and runtime: Windows and .NETnext: minimal TCB running e.g. on isolated core (SGX)

4. core cryptographic providersnext: correctness for selected algorithms (elliptic curves)

http://www.mitls.org

fournet@microsoft.com