SSl/TLS Analysis
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


SSl/TLS Analysis






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

SSl/TLS Analysis Presentation Transcript

  • 1. 08 Mai 2014! Security Protocols: Modelling and Verification! Prof. Indrumator - Cătălin Bîrjoveanu " Duduman Bogdan Vlad! 1 TLS/SSL (Analysis) Text
  • 2. Overview 1. Introduction to the SSL / TLS protocol! • Widely deployed, “real-world” security protocol! • Well-understood, with detailed specifications! • Good benchmark for analysis techniques! 2. Protocol analysis! • //Starting with the RFC describing the protocol! 3. Tools
  • 3. What is TLS/SSL? ❖ Standard for Internet security! ❖ “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications ”! ❖ In practice, used to protect information transmitted between browsers and Web servers! ❖ Based on Secure Sockets Layers protocol, ver 3.0! • Same protocol design, different algorithms! ❖ Deployed in nearly every web browser
  • 4. SSL / TLS in the Real World
  • 5. TCP/IP - TLS/SSL (1)
  • 6. TCP/IP - TLS/SSL (2)
  • 7. TLS (Transport Layer Security) ❖ Provides a layer between TCP and Application ! ❖ Itself a layered protocol: Handshake over Record ! ❖ Record (sub)protocol! ❖ provides a private and reliable connection! ❖ Handshake (sub)protocol! ❖ authenticates one or both parties, negotiates security parameters! ❖ establishes secret connection keys for the Record protocol
  • 8. TCP/IP - TLS/SSL (2)
  • 9. History of the Protocol ❖ SSL 1.0! ❖ Netscape completed the design in early 1994 (Internally used)! ❖ Data integrity protection! ❖ RC4 allowed adversary to make predictable changes to the plaint text! ❖ Vulnerable to replay attacks! ❖ SSL 2.0! ❖ End of 1994, also has several problems! ❖ Handshake protection - MITM undetected!! ❖ Vulnerable to length extension attacks
  • 10. History of the Protocol ❖ SSL 3.0! ❖ fixed previous attacks! ❖ Netscape and Paul Kocher, 1996! ❖ Taher Elgamal - inventor of SSL! ❖ TLS 1.0! ❖ Internet standard based on SSL 3.0, 1999 ! ❖ RFC2246 (≈SSL3)
  • 11. History of the Protocol ❖ TLS 1.1! ❖ 2006! ❖ RFC4346! ❖ TLS 1.2! ❖ 2008! ❖ RFC5246
  • 12. Public-Key Encryption, CA & MITM ❖ “Symmetric” encryption! ❖ Share secret key! ❖ Hundred of peoples to communicate?! ❖ Distance Key Key Them You
  • 13. Public-Key Encryption, CA & MITM ❖ Solution: public-key encryption! ❖ Share public key with whole world! ❖ No known practical way to gain the private key from pkey
  • 14. Public-Key Encryption, CA & MITM ❖ Visiting first time “https”! ❖ Browser create a random private key A ! ❖ Generates corresponding public key A(blue)
  • 15. Public-Key Encryption, CA & MITM ❖ Server generate a random private key A ! ❖ Session key established! ❖ Intruder (MITM) ?!
  • 16. Public-Key Encryption, CA & MITM ❖ MITM stops the communication! ❖ MITM create his own private key (red B)! ❖ Server doesn’t know if is the browser
  • 17. Public-Key Encryption, CA & MITM ❖ MITM has the same session key (red key)! ❖ How to solve? ! ❖ Server and Browser can send there public key and compare! ❖ what if MITM knows about that - he has the session key
  • 18. Public-Key Encryption, CA & MITM ❖ Certificate Authority solves the problems! ❖ There is a single CA - Symantec (VeriSign)! ❖ FedEx - Federal Express - encryption key H! ❖ MITM has the public key CA! ❖ What browser and server can do?
  • 19. Public-Key Encryption, CA & MITM ❖ Server encrypts public key A with certificate key H! ❖ Browser do the same using the built-in CA
  • 20. Public-Key Encryption, CA & MITM ❖ CA compares the 2 public keys! ❖ CA sends reply to them! ❖ What if MITM appear?! ❖ the browser will not be able to decrypt (key random R)
  • 21. Obtaining an SSL Certificate ❖ XYZ Inc., intends to secure their customer checkout process, account management, and internal employee correspondence on their website, ❖ Steps: 1. XYZ creates a Certificate Signing Request (CSR) and during this process, a private key is generated. 2. XYZ goes to a trusted, third party Certificate Authority, such as Trustwave . Trustwave takes the certificate signing request and validates XYZ in a two step process. Trustwave validates that XYZ has control of the domain and that XYZ Inc. is an official organization listed in public government records. 3. When the validation process is complete, Trustwave gives XYZ a new public key (certificate) encrypted with Trustwave's private key. 4. XYZ installs the certificate on their webserver(s).
  • 22. How Customers Communicate with the Server using SSL Steps: 1. A customer makes a connection to on an SSL port, typically 443. This connection is denoted with https instead of http. 2. sends back its public key to the customer. Once customer receives it, his/ her browser decides if it is alright to proceed. 3. The public key must NOT be expired 4. The public key must be for only 5. The client must have the public key for Trustwave installed in their browser certificate store. 99.9% of all modern browsers (1998+) include the Trustwave root certificate. If the customer has Trustwave trusted public key, then they can trust that they are really communicating with XYZ, Inc.
  • 23. How Customers Communicate with the Server using SSL ! 7.If the customer decides to trust the certificate, then the customer will be sent to his/her public key. will next create a unique hash and encrypt it using both the customer's public key and's private key, and send this back to the client. 9.Customer's browser will decrypt the hash. This process shows that the sent the hash and only the customer is able to read it. 10.Customer and website can now securely exchange information!
  • 24. Tools 1.! Security Protocol Analysis! ❖ Scyther ❖ Scyther-proof ❖ Tamarin prover 2.! Access Control! ❖ FPL 3.! Static Security Analysis! ❖ FAST 4.! Protocol Testing! ❖ SecFuzz 5.! Specification synthesis! ❖ Mid-point synthesis 6.! Monitoring! ❖ MonPoly 7! Isabelle/HOL frameworks! ❖ ProtoVeriPhy ❖ Developing Security Protocols by Refinement ❖ Verification of IBM 4765's Persistent Memory Manager 8. Avispa! 9. ProVerif
  • 25. The Scyther Tool ❖ Tool for the formal analysis of security protocols ! ❖ it is assumed that all cryptographic functions are perfect: the adversary learns nothing from an encrypted message unless he knows the decryption key.! ❖ Description of a protocol in the spdl language ! ❖ based on the operational semantics! ❖ spdl (Security Protocol Description Language)
  • 26. The Scyther Tool ❖ Analysis of infinite sets of traces in terms of patterns! ❖ Support for multi-protocol analysis! ❖ Assist in the analysis of classes of attacks and possible protocol behaviours, or to prove correctness for an unbounded number of protocol sessions.! ❖ Can optionally output the proof tree (by using the backend).! ❖ The tool provides useful results even in the case that no attack is found
  • 27. The Scyther Tool ❖ ProVerif or the Avispa tools have shown to be effective at finding attacks on protocols (Avispa) or establishing correctness of protocols (ProVerif).! ❖ Scyther offer verification, falsification, and the analysis of security protocols.! ❖ Performance
  • 28. Installation Scyther Tool ❖ Scyther can be downloaded from the following website:! ❖! ❖ Installation instruction are included in the downloadable Scyther archives. Scyther is available for the Windows, Linux and Mac OS platforms.
  • 29. Scyther Input File ❖ A minimal input file:! ! protocol ExampleProtocol(I,R) {! role I { };! role R { };! };
  • 30. Input Language ❖ Main purpose of the language is to describe protocols, which are defined by a set of roles.! ❖ Protocol definition takes as a parameter a sequence of roles, which are then defined within its body.! ❖ Roles - are sequences of events, i. e., declarations, send, receive, or claim events.! ❖ Security protocols rely on generating random values. Can be specified by declaring them inside a role definition using the fresh declaration.! ❖ role X(...) {! ❖ fresh Na: Nonce;! ❖ send_1(X,Y,Na);! ❖ }
  • 31. Input Language ❖ To receive a nonce into a variable with name Na, we specify:! ❖ role Y(...) {! ❖ var Na: Nonce;! ❖ recv_1(X,Y,Na);! ❖ }! ❖ Local declaration! ❖ Two terms can combined into a term pair: we write (x,y)! ❖ Symmetric keys: { ni }kir! ❖ Asymmetric keys: { ni } pk(I)
  • 32. Input Language ❖ Hash functions are essentially encryptions with a function, of which the inverse is not known by anybody:! ❖ global declaration: hashfunction H1! ❖ how are used: H1(ni);! ❖ Types: Agent, Function, Nonce, Ticket! ❖ You can define a new type: user type! ❖ Recv and Send events mark receiving and sending a message!
  • 33. Input Language ❖ Claim events are used in role specifications to model intended security properties. For example, the following claim event models that Ni is meant to be secret! ❖ claim(I, Secret, Ni);! ❖ Claim types:! ❖ Secret! ❖ SKR, echivalent to Secret but additionally mark the parameter term as a session-key! ❖ Alive - Aliveness (of all roles) ! ❖ Weakagree - Weak agreement (of all roles)
  • 34. Input Language ❖ Claim types:! ❖ Nisynch (Authentification Property, Non-injective Synchronisation)! ❖ Niagree (Authentification Property, Non-injective Agreement)! ❖ Reachable! ❖ when this claim is verified, Scyther will check whether this claim can be reached at all. It is true iff there exists a trace in which this claim occurs. This can be useful to check if there is no obvious error in the protocol specification, and is in fact inserted when the--check mode of Scyther is used.! ❖ Empty! ❖ this claim will not be verified, but simply ignored. It is only useful when Scyther is used!
  • 35. – It’s time to see TLS on Scyther Tool
  • 36. Simplified TLS key transport protocol ❖ Protocol 4.24 is a simplified version of one possible protocol which transports the 'pre- master secret', PMK, from the client A to the server B" ❖ Session key Kab is calculated as Kab = MACpmk(Na,Nb)" ❖ TLS protocol specifies that four different session keys must be derived from the pre-master secret: one for encryption and one for data integrity (MAC calculation) in each direction. !
  • 37. Simplified TLS key transport protocol ❖ Message sequences Mess_Seq1, Mess_Seq2 and Mess_Seq3 consist of hashes of the sequence of all previous exchanged messages up to that point using a hash function H.! ❖ Mess_Seq1 = H(Na, Nb, Eb(PMK)).!
  • 38. Bibliografie 1. Protocols for Authentication and Key Establishment - C.Boyd, A.Mathuria! 2. Operational Semantics of Security Protocols - Cas Cremers and Sjouke Mauw, Eindhoven University of Technology, Department of Mathematics and Computer Science! 3. How SSL works! 4. Security Tools! 5. Scyther Manual! 6. bindings-on-iis.aspx! 7. Secure_Socket_Layer.html