Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
How Secure is TLS?
miTLS: a verified reference implementation
Cédric Fournet
with
Karthikeyan Bhargavan, Antoine Delignat-...
2015 TLS 1.3?
SChannel, OpenSSL, NSS, GnuTLS, JSSE, PolarSSL
still patched every month! + Snowden allegations
Well-underst...
Threat modelSecurity Goal
connect(server,port);
send(d1);
send(d2);
send(d3);
…
accept(port);
d1’ = recv();
d2’ = recv();
...
Security Goal
X.509 public-key
infrastructure
connect(server,port);
send(d1);
send(d2);
send(d3);
…
accept(port);
d1’ = re...
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 ...
Many obsolete crypto
constructions
•
•
•
•
•
Countermeasures
Disable these features:
SSL3, compression, RC4
Implement miti...
The duplicate goto always branches
to the end of the function with err = 0
The key is not bound to the
server signing-key ...
Memory safety
Buffer overruns leak secrets
Missing checks
Forgetting to verify
signature/MAC/certificate
bypasses crypto g...
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 ...
Infrastructure
certificate management
Application
HTTPS clients & servers
IEEE Security & Privacy 2014
HTTP/1.1 302 Redirect
Location: https://x.com/P
Set-Cookie: SID=[SessionToken]; secure
Content-Length: 0
Many web services...
https://www.secure-resumption.com/
Client TLS library
Chromium
Opera 15+
NSS
Internet
Explorer
SChannel
Safari &
Apple mail
Secure
Transport
Apple Mail
Secur...
Protocol Logic
e.g. ambiguous messages
• cause clients and server
to negotiate older weaker TLS
Cryptography
e.g. no fresh...
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 att...
symmetric
encryption
(AES-CBC)
Cryptographic algorithms
symmetric
encryption
(RC4)
Secure RPC
some
application code
TLS 1....
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
DHGrou...
type connection // for each local instance of the protocol
// creating new client and server instances
val connect: TcpStr...
concrete TLS & ideal TLS
are computationally
indistinguishable
miTLS
implementation
miTLS typed API
Bytes, Network
lib.fs
...
7,000 lines of F#
checked against
3,000 lines of F7
type annotations
+
3,000 lines of EasyCrypt
for the core key exchange
...
reference code vs
production code
Sufficient for simple applications.
We miss system engineering:
custom memory manager,
c...
We account for some side-channels, not for timing
1. verification tools: F7, Z3, EasyCrypt
now: mechanized theory using Co...
http://www.mitls.org
fournet@microsoft.com
How (un)secure is SSL/TLS?
How (un)secure is SSL/TLS?
How (un)secure is SSL/TLS?
How (un)secure is SSL/TLS?
How (un)secure is SSL/TLS?
How (un)secure is SSL/TLS?
Upcoming SlideShare
Loading in …5
×

How (un)secure is SSL/TLS?

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/

  • Login to see the comments

How (un)secure is SSL/TLS?

  1. 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. 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. 3. Threat modelSecurity Goal connect(server,port); send(d1); send(d2); send(d3); … accept(port); d1’ = recv(); d2’ = recv(); d3’ = recv(); … authentication infrastructure
  4. 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. 5. Client Server
  6. 6. Client Server
  7. 7. Client Server
  8. 8. Client Server
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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, …)
  13. 13. Implementation Bugs many critical errors Test results for OpenSSL: each arrow is a bug IEEE Security & Privacy 2015
  14. 14. 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
  15. 15. Infrastructure certificate management
  16. 16. Application HTTPS clients & servers IEEE Security & Privacy 2014
  17. 17. 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
  18. 18. https://www.secure-resumption.com/
  19. 19. 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
  20. 20. 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
  21. 21. IEEE Security & Privacy 2013
  22. 22. https://www.miTLS.org
  23. 23. 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
  24. 24. 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
  25. 25. TLS.fs7 TLS.fs TLS.fsi Type (F7) Prove (Z3) Compile (F#) Erase types Handshake.fs7 Record.fs7 Modular Type-checking
  26. 26. 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
  27. 27. 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
  28. 28. 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)
  29. 29. 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
  30. 30. 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
  31. 31. 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)
  32. 32. http://www.mitls.org fournet@microsoft.com

×