Dans cette session, Cedric Fournet, chercheur principal à Microsoft Research Cambridge et au Centre de Recherche Commun INRIA-Microsoft Research nous présentera un panorama des types de vulnérabilités classiques de TLS ainsi que le projet "MiTLS" qui leur a permis, en avril 2014, de révéler une vulnérabilité majeure mais n'ayant pas fait l'objet d'attaques jusqu'à sa découverte. MiTLS est une implémentation expérimentale vérifiée mathématiquement de TLS : MiTLS est implémenté en F# et spécifié en F7. MiTLS est une plateforme de recherche et de test permettant de revisiter les attaques connues et régulièrement d'en trouver de nouvelles et donc de renforcer la robustesse du protocole en connexion avec l'IETF. TLS 1.2 (connu aussi comme SSL 3.0) est le protocole de cryptographie le plus répandu pour sécuriser les communications et les échanges sur Internet. Successeur de SSL, TLS est la garantie que vos transactions bancaires sur le web ou que votre messagerie seront bien protégées. TLS est omniprésent : HTTPS, 802.1x, VPNs, files, mail, VoIP… Et pourtant, est-ce que la confiance qu'on lui accorde est bien méritée ? Est-ce que TLS est sûr à 100% ? TLS a une histoire longue de 18 ans de défauts et de correctifs, depuis la logique de sa spécification jusqu'aux multiples implémentations. Son omniprésence au cœur du système de confiance du web rend nécessaire une démarche organisée, rationnelle et préventive de détection de ses vulnérabilités. http://www.mitls.org/wsgi/home http://research.microsoft.com/en-us/projects/f7/

1. How Secure is TLS?
miTLS: a verified reference implementation
Cédric Fournet
with
Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Markulf Kohlweiss,
Alfredo Pironti, Pierre-Yves Strub, Santiago Zanella Beguelin
https://www.miTLS.org

2. 2015 TLS 1.3?
SChannel, OpenSSL, NSS, GnuTLS, JSSE, PolarSSL
still patched every month! + Snowden allegations
Well-understood, detailed specs
many security theorems…
mostly for small simplified models of TLS

3. Threat modelSecurity Goal
connect(server,port);
send(d1);
send(d2);
send(d3);
…
accept(port);
d1’ = recv();
d2’ = recv();
d3’ = recv();
…
authentication
infrastructure

4. Security Goal
X.509 public-key
infrastructure
connect(server,port);
send(d1);
send(d2);
send(d3);
…
accept(port);
d1’ = recv();
d2’ = recv();
d3’ = recv();
…

5. Client Server

6. Client Server

7. Client Server

8. Client Server

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

11. Many obsolete crypto
constructions
•
•
•
•
•
Countermeasures
Disable 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

12. 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
thenGnuTLS, Mar’14
thenHeartbleed,
OpenSSL, April’14
thenPoodle, Sep’14

13. Memory safety
Buffer overruns leak secrets
Missing checks
Forgetting to verify
signature/MAC/certificate
bypasses crypto guarantees
Certificate validation
ASN.1 parsing,
wildcard certificates
State machine bugs
Most TLS implementations
don’t conform to spec
Unexpected transitions break
protocol (badly)
(EarlyCCS, OpenSSL, …)

14. Implementation Bugs
many critical errors
Test results for OpenSSL:
each arrow is a bug
IEEE Security & Privacy 2015

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

16. Infrastructure
certificate management

17. Application
HTTPS clients & servers
IEEE Security & Privacy 2014

18. HTTP/1.1 302 Redirect
Location: https://x.com/P
Set-Cookie: SID=[SessionToken]; secure
Content-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

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

20. Client TLS library
Chromium
Opera 15+
NSS
Internet
Explorer
SChannel
Safari &
Apple mail
Secure
Transport
Apple Mail
Secure
Transport
CURL OpenSSL
CURL GnuTLS
Wget OpenSSL
NodeJS HTTPS OpenSSL
PHP SSL
Transport
OpenSSL
Apache
HttpClient
JSSE 1.7
SVN / Neon OpenSSL
SVN / Neon OpenSSL
Cadaver/Neon OpenSSL
Git / CURL GnuTLS

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

24. IEEE Security & Privacy 2013

25. https://www.miTLS.org

26. 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 on
the ciphersuites being negotiated
We verify TLS generically,
for multiple ciphersuites & algorithms
This requires new cryptographic models

27. symmetric
encryption
(AES-CBC)
Cryptographic algorithms
symmetric
encryption
(RC4)
Secure RPC
some
application code
TLS 1.2
Applications & Adversaries
Security protocols
Cryptographic constructions
encrypt
then-MAC
fragment-MAC-
encode-then-encrypt
some
attack
some
attack
some
attack
message
authentication
(SHA1)
INT-CMA IND-CPA
authenticated encryption
secure channel

28. TLS.fs7
TLS.fs
TLS.fsi
Type
(F7)
Prove
(Z3)
Compile
(F#)
Erase
types
Handshake.fs7
Record.fs7
Modular Type-checking

29. 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
TLSFragmentAlert
Datastream
Handshake (and CCS)
TLSInfoTLSConstants
Handshake/CCS
TLS
Record
AppData
Base Bytes
Untyped API
Adversary
RPC
RPCPlain
Application
TLS API
Alert
Protocol
AppData
Protocol
Nonce
TLS
CoreCrypto
RSAKey
Auth
AuthPlain
Extensions
1
2
3 4 5
6 7
Range
8
9
Error

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

33. concrete TLS & ideal TLS
are computationally
indistinguishable
miTLS
implementation
miTLS typed API
Bytes, Network
lib.fs
Cryptographic Provider
cryptographic assumptions
any program
representing the
adversary
application
data stream
miTLS ideal
implementation
miTLS typed API
application
Safe, except for a
negligible probability
Safe by typing
(info-theoretically)

34. 7,000 lines of F#
checked against
3,000 lines of F7
type annotations
+
3,000 lines of EasyCrypt
for the core key exchange
miTLS
implementation
miTLS typed API
Bytes, Network
lib.fs
Cryptographic Provider
cryptographic assumptions
any program
representing the
adversary
application
data stream
miTLS ideal
implementation
miTLS typed API
application

35. 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 292
419
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

36. We account for some side-channels, not for timing
1. verification tools: F7, Z3, EasyCrypt
now: mechanized theory using Coq/SSReflect
next: certified F* tools and SMT solver
2. cryptographic assumptions
now: concrete reductions using Easycrypt
next: mechanized proofs using relational probabilistic logic
3. the F# compiler and runtime: Windows and .NET
next: minimal TCB running e.g. on isolated core (SGX)
4. core cryptographic providers
next: correctness for selected algorithms (elliptic curves)

37. http://www.mitls.org
fournet@microsoft.com