BYU logo Computer Science
CS 465 Introduction to Security and Privacy

TLS

Introductions

  • introductions of two students

Questions on the readings

The readings today are from Computer Security and the Internet, Chapter 9, sections 9.2

SSL and TLS hsitory

TLS history

Source of image: SSL and TLS, Rescorla

SSL record structure

SSL records

Source of image: Network and Security Essentials, Stallings

TLS handshake and DH key exchange

  • the main purpose of the TLS handshake is to etablish a shared key
  • note this shows Diffie-Hellman, but there are a variety of ways to complete the handshake
TLS handshake and key exchange

  • parts of the handshake

    • Client Hello

      • Random client: random number used later to derive shared key
      • Cipher Suites: zero or more
      • Session ID: can be used to update or resume a connection

    • Server Hello

      • Random server: random number used later to dervice shared key
      • Cipher Suite: the single cipher suite selected from the client’s list (or the connection is closed if none is available)
      • Session ID: can indicate a resumed connection or a new connection

    • Server Certificate

      • a chain of certificates that authenticate the server to the client

    • Server Key Exchange

      • random client from above
      • random server from above
      • signed Diffie-Hellman parameters

    • Server Hello Done

      • empty, signals end of key exchange messages
      • note, this is needed because, e.g. Server Key Exchange message may not be needed

    • Client Key Exchange

      • public Diffie Hellman message

    • Change Cipher Spec

      • potentially multiple messages to change the cipher suite

    • Finished

      • sent after cipher change messages
      • verifies the key exchange and authentication was successful
      • contains some data to verify the previous exchanges — HMAC of master secret, a text string, hash of hasndshake messages
      • first message protected with the negotiated algorithms, keys, and secrets
      • after this message, the peers can exchange data

    • everything after the key exchange is encrypted and protected with a MAC (unless AES GCM mode used) — this means an attacker cannot modify algorithms chosen

    • can use a pre-shared key, meaning a key from a previous session

    • Diffie-Hellman keys are ephemeral — erased after use

TLS Cipher Suites

  • defines the algorithms used during the TLS connection

    • key exchange algorithm — for exchanging/creating a symmetric encryption key
    • authentication algorithm — for digital signatures
    • bulk encryption algorithm — for encrypting the data
    • MAC algorithm — for security

  • example: ECDHE-ECDSA-AES128-GCM-SHA256

    • ECDHE: Elliptic-curve Diffie-Hellman
    • ECDSA — Elliptic-curve Digital Signature Algorithm
    • AES 128 — AES with 128-bit key
    • GCM — Galois/Counter Mode — block cipher with high performance (parallelizable) and patent-free
    • SHA256 — MAC algorithm

Organization and Extended Validation certificates

types of certificates

  • DV (Domain Validated) certificates

    • demonstrate control of the domain, which could be responding to email sent to admin@domain.com
    • inexpensive or free

  • OV (Organization Validated) certificates

    • manual checks to certify ownership of a real-world organization

  • EV (Extended Validation) certificates verify

    • real-world existance of a legal entity in the Subject
    • registration in government-recognized databases
    • physical existence matching location in certificate
    • identity of person requesting certificate and their relationship to the organization
    • control of the domain

  • IV (Individual validated) certificates

    • user decided to trust them (e.g. self-signed certificates)

  • users don’t know the difference between DV, OV, and EV

Attacks on TLS

  • rogue certificates — see Hackers spied on 300,000 Iranians using fake Google certificate, 2011

  • TLS stripping attacks — block the signal to upgrade from HTTP to HTTPS

    • see website configuration below
    • use browser tools to see the redirect
    • see HTTPS Everywhere browser extension
    • revocation failures can be exploited

  • difficulties with browser trust model

    • how do users or browsers decide who is trustworthy and who is not?
    • poor trust agility — no system to dynamically add/remove certificates from the root store, it’s up to the OS or browser vendor
    • intermediate CAs are unaccountable — can only remove root CAs

  • certificate transparency helps expose rogue certificates

    • this uses a blockchain to track all certificates
    • an attacker can avoid putting a rogue certificate into the blockchain, but then browsers will reject it as not valid
    • an attacker can put the rogue certificate into the blockchain, and then once caught the signing CA will be banned
    • so the system helps shorten the lifetime of attacks
    • for details, see Certificate Transparency

Other TLS topics

Class Exercise