tls by suchenfz


									CS 378


         Vitaly Shmatikov

                            slide 1
Reading Assignment
Kaufman. Chapter 19.

                        slide 2
What is SSL / TLS?
Transport Layer Security protocol, version 1.0
  • De facto standard for Internet security
  • “The primary goal of the TLS protocol is to provide
    privacy and data integrity between two communicating
     – … against active, man-in-the-middle network attacker
  • Used to protect information transmitted between
    browsers and Web servers, VoIP, email, etc.
Based on Secure Sockets Layers protocol, ver 3.0
  • Same protocol design, different algorithms
Deployed in nearly every Web browser
                                                              slide 3
SSL / TLS in the Real World

                              slide 4
What Does the Lock Icon Mean?

The origin of the page is what it says in the
 address bar
  • User must interpret what he sees - remember
Contents of the page have not been viewed or
 modified by a network attacker

                                                  slide 5
Purpose of SSL / TLS
SSL/TLS aims to provide secure communications
 in the presence of a network attacker
  • Sitting with your laptop in an Internet café connected
    to a dodgy ISP in a hostile authoritarian country
Attacker 0wns the network
  • WiFi, DNS, routers, his own websites
  • Can listen to any packet, modify packets in transit,
    inject his own packets into the network

                                                             slide 6
History of the Protocol
SSL 1.0
  • Internal Netscape design, early 1994?
  • Lost in the mists of time
SSL 2.0
  • Published by Netscape, November 1994
  • Several weaknesses
SSL 3.0
  • Designed by Netscape and Paul Kocher, November 1996
TLS 1.0
  • Internet standard based on SSL 3.0, January 1999
  • Not interoperable with SSL 3.0
     – TLS uses HMAC instead of MAC; can run on any port   slide 7
TLS Basics
TLS consists of two protocols
  • Common pattern for key establishment protocols
Handshake protocol
  • Use public-key cryptography to establish a shared
    secret key between the client and the server
Record protocol
  • Use the secret key established in the handshake
    protocol to protect communication between the client
    and the server
We will focus on the handshake protocol
                                                           slide 8
TLS Handshake Protocol
Runs between client (typically, Web browser) and
 server (typically, website)
Negotiate version of the protocol and the set of
 cryptographic algorithms to be used
  • Interoperability between different implementations of
    the protocol
Authenticate client and server (optional)
  • Use digital certificates to learn each other‟s public keys
    and verify each other‟s identity
Use public keys to establish a shared secret
                                                            slide 9
Handshake Protocol Structure



 C          [Certificate],

            switch to negotiated cipher

                                          switch to negotiated cipher
Record of all sent and                                   Finished
received handshake messages
                                                                            slide 10


                Client announces (in plaintext):
                • Protocol version he is running
                • Cryptographic algorithms he supports

                • Fresh, random number

                                                             slide 11
ClientHello (RFC)
struct {                                            Highest version of the protocol
                                                       supported by the client

  ProtocolVersion client_version;
  Random random;           Session id (if the client wants to
                               resume an old session)
  SessionID session_id;                  Set of cryptographic algorithms
                                          supported by the client (e.g.,
  CipherSuite cipher_suites;                 RSA or Diffie-Hellman)

  CompressionMethod compression_methods;
} ClientHello

                                                                                 slide 12

      C, Versionc, suitec, Nc


       Server responds (in plaintext) with:

       • Highest protocol version supported by
         both client and server                          S
       • Strongest cryptographic suite selected
         from those offered by the client
       • Fresh, random number

                                                             slide 13

      C, Versionc, suitec, Nc

                                  Versions, suites, Ns,

 C      Server sends his public-key certificate           S
        containing either his RSA, or
        his Diffie-Hellman public key
        (depending on chosen crypto suite)

                                                              slide 14

      C, Versionc, suitec, Nc

                                   Versions, suites, Ns,

 C    ClientKeyExchange
       Client generates some secret key material
       and sends it to the server encrypted with
       the server‟s public key (if using RSA)

                                                               slide 15
ClientKeyExchange (RFC)
struct {
  select (KeyExchangeAlgorithm) {
     case rsa: EncryptedPreMasterSecret;
     case diffie_hellman: ClientDiffieHellmanPublic;
  } exchange_keys
} ClientKeyExchange            Where do random
                                     bits come from?
struct {
  ProtocolVersion client_version;
  opaque random[46];             Random bits from which
                              symmetric keys will be derived
                              (by hashing them with nonces)
} PreMasterSecret                                              slide 16
Debian PRNG (2006-08)
A line of code from md_rand in Debian Linux
  • MD_Update(&m,buf,j); /* purify complains */
Without this line, seed for the pseudo-random
 generator is derived only from process ID
  • Default maximum on Linux = 32768
Result: all keys generated using Debian-based
 OpenSSL package in 2006-08 are broken
  • “Affected keys include SSH keys, OpenVPN keys,
    DNSSEC keys, and key material for use in X.509
    certificates and session keys used in SSL/TLS
                                                     slide 17
“Core” SSL 3.0 Handshake

     C, Versionc=3.0, suitec, Nc

                                    Versions=3.0, suites, Ns,


 C                  C and S share some
          secret key material (secretc) at this point

       switch to key derived           switch to key derived
       from secretc , Nc , Ns          from secretc , Nc , Ns

                                                                    slide 18
Version Rollback Attack

     C, Versionc=2.0, suitec, Nc

     Server is fooled into thinking he   Versions=2.0, suites, Ns,
     is communicating with a client
     who supports only SSL 2.0

 C    {Secretc}PKs

       C and S end up communicating using SSL 2.0
        (weaker earlier version of the protocol that
          does not include “Finished” messages)

                                                                         slide 19
SSL 2.0 Weaknesses (Fixed in 3.0)
Cipher suite preferences are not authenticated
  • “Cipher suite rollback” attack is possible
Weak MAC construction
SSL 2.0 uses padding when computing MAC in
 block cipher modes, but padding length field is
 not authenticated
  • Attacker can delete bytes from the end of messages
MAC hash uses only 40 bits in export mode
No support for certificate chains or non-RSA
 algorithms, no handshake while session is open
                                                         slide 20
“Chosen-Protocol” Attacks
Why do people release new versions of security
 protocols? Because the old version got broken!
New version must be backward-compatible
  • Not everybody upgrades right away
Attacker can fool someone into using the old,
 broken version and exploit known vulnerability
  • Similar: fool victim into using weak crypto algorithms
Defense is hard: must authenticate version early
Many protocols had “version rollback” attacks
  • SSL, SSH, GSM (cell phones)
                                                             slide 21
Version Check in SSL 3.0

       C, Versionc=3.0, suitec, Nc

                                         Versions=3.0, suites, Ns,
     “Embed” version                     “ServerHelloDone”
     number into secret

 C      {Versionc,Secretc}PKs
                                Check that received version is
                                equal to the version in ClientHello
                        C and S share some
               secret key material secretc at this point

        switch to key derived               switch to key derived
        from secretc, Nc, Ns                from secretc, Nc, Ns

                                                                          slide 22
SSL/TLS Record Protection

                  Use symmetric keys
                  established in handshake protocol

                                                slide 23
When Should The Lock Be Shown?

All elements on the page fetched using HTTPS
 For all elements:
HTTPS certificate is issued by a certificate
 authority (CA) trusted by the browser
HTTPS certificate is valid – means what?
  • Not expired… is this it?
Common Name in the certificate matches
 domain name in the URL (more on this later)
                                                slide 24
Combining HTTPS and HTTP
Page served over HTTPS but contains HTTP
  • IE 7: no lock, “mixed content” warning
  • Firefox: “!” over lock, no warning by default
  • Safari: does not detect mixed content
                                                    Lock icon
                                            Flash file served
                                               over HTTP
  • Flash does not trigger warning in IE7 and FF
Network attacker can now inject scripts,
 hijack session – what does the lock mean, again?
                                                            slide 25
HTTP  HTTPS and Back
Typical pattern: HTTPS upgrade
  • Come to site over HTTP, redirect to HTTPS for login
  • Browse site over HTTP, redirect to HTTPS for checkout
sslstrip: network attacker downgrades connection
              HTTP                   SSL

  • Rewrite <a href=https://…> to <a href=http://…>
  • Redirect Location: https://... to Location: http://...
  • Rewrite <form action=https://… >       Can server detect
         to <form action=http://…>           this attack?
                                                               slide 26
Will You Notice?
                                      [Moxie „08]


            Clever favicon inserted
            by network attacker

                                                    slide 27

To top