Skip to main content

TLS and PKI

SSL/TLS​

  • TLS is a protocol that provides authenticated and encrypted sessions
  • Secure Socket Layer (SSL) came first, then after v3.0 it became Transport Layer Security (TLS)

TLS​

Record Layer - Using established symmetric keys and other session info, will encrypt application packets, much like IPSec. Handshake Layer - Used to establish session keys, as well as authenticate either party - usually the server using a public-key certificate.

  1. Client and server say hello - Which TLS version, ciphers, algorithms etc
  2. Pair agree on cipher suit
  3. Public key verification - Used to confirm the identity of the server. Certificate includes public key, signature is computed with the private key
  4. Key exchange - Both parts of a Diffie-Hellman key exchange. Modern TLS uses an elliptic curve version of the scheme. Ephemeral means we do this fresh for every handshake.
    1. Symmetric keys - Confirm everything has worked safely. Hash function is useful for creating this.
  5. Final checks - Contains a digest of all the messages in the handshake
  6. Send Application Data - Switch to regular TLS records for an encrypted session

1.3 Improvements​

  • Major handshake improvements
  • All ciphers removed except for modern AEAD
  • Key exchange and authentication separated from ciphers
  • Wider use of extensions
  • 0-RTT Resumption

Application Data​

  • Handshake embeds much of the key exchange into the hello message
  • Client guesses a key sharing algorithm within client hello
  • If the key share isn't supported, server sends a hello retry request
  • Encryption begins after the second msg

0-RTT Resumption​

0 During application data, the server can send a pre-shared key for use next time Doesn't always supply forward secrecy 1-RTT session resumption is closer to the original 1.2 session keys

Vulnerabilities​

  • MITM are usually countered using public-key authentication
  • The majority of TLS problems are implementation
    • Heartbleed
  • Protocol downgrade attacks can be a concern - many servers still allow weak cipher suits

Public Key Infrastructure (PKI)​

Key Problem

  1. No real reason to trust certificates
  2. Have no real reason to trust the signature

Digital Certificates​

  • Need trust
  • Can use a trusted third party in order to verify the ownership of a public key
  • Primarily managed through (PKI)
  • Certificates usually held in X509 format

Issuance​

  • Server has a public key that they want people to trust
  • Server creates a Certificate Signing Request (CSR)
  • A Certification Authority (CA) uses this to create and sign a certificate

Server can supply digital signatures using the public key, backed by the certificate when request, during a TLS handshake

Chain of trust​

  • Verify the trust in the certificate
  • In many cases, the chain involves multiple certificates
  • Chains always end in a root certificate, located on the machine

Management of Root Certificates​

  • Major OS vendors operate root certificate programs

Limitations of PKI​

  • Administrators use it badly - use of wildcard certificates. Poor server setup = low quality ciphers
  • Over-reliance on a few key libraries
  • Users don't understand it
  • Main problem with PKI is that once you've trusted one or more CAs, you trust every certificate signed by them
  • If a private key is stolen - the certificate must eb revoked
  • Open Certificate Status Protocol (OCSP) - Challenge-response in which a CA is polled for live revocation status.

Alternatives​

  • Public CA
  • Private CA
  • Self-signed is bad as harder to deploy and may encourage bad practice