SSL/TLS

Secure communication over insecure channels

Karol Babioch <karol@babioch.de>

NULL 911 - July 31, 2019

“Watch out for the padlock”

SSL padlock

+ a lot of details ...

About me

  • Open Source Enthusiast
  • Engineering Infrastructure @ SUSE
  • ❤ Crypto, authentication, IT security, ...

Agenda

  • Protocol overview
  • Handshake
  • Attacks
  • TLS 1.3
  • Good practice and recommendations
  • Q&A

Resources

The SSL/TLS “bible”

Bulletproof SSL and TLS book cover

Source: Bulletproof SSL and TLS by Ivan Ristić

SSL/TLS overview

Used everyhwere ...

  • on top of other protocols (https, imaps, etc.)
  • in many applications (VPN, mail, chat, etc.)
  • implemented for basically all devices
  • implemented for operating systems

SSL vs. TLS

  • Two names for essentially the same protocol
  • Technically correct: TLS
  • Most people still use: SSL
  • → Nevermind

Secure communication over insecure channels

Alice, Bob & Mallory

Source: elektronik-kompendium.de

Goals of TLS

  • Cryptographic security
  • Interoperability
  • Extensibility
  • Efficiency

Security provided by TLS

  • Confidentiality
  • Integrity
  • Authenticity

Networking layer

# OSI layer Description Protocols
7 Application Application data HTTP, SMTP, IMAP
6 Presentation Data representation, encryption SSL/TLS
5 Session Management of multiple connections -
4 Transport Delivery of packets and streams TCP, UDP
3 Network Routing and delivery of datagrams IP, IPsec
2 Data link Local data connection Ethernet
1 Physical “Cables” CAT5

Protocol history

Version Year Description
SSL 1 - Never publicly released
SSL 2 1994 Broken by design (no security experts involved)
SSL 3 1995 New protocol design
TLS 1.0 1999 Migration from Netscape to IETF, minor changes only
TLS 1.1 2006 Security fixes, TLS extensions
TLS 1.2 2008 Authenticated encryption, removed hardcoded primitives
TLS 1.3 2018 A lot of changes, see later!

Crypto 101

  • Hash functions
  • Symmetric cryptography
  • Asymmetric cryptography

(Cryptographic) hash functions

  • (Fixed-size) digest (“hash value”) for any input
  • Input → digest (easy)
  • Digest → input (difficult)
  • Unlikely for two messages to have same digest

(Cryptographic) hash functions

Cryptographic hash function

Source: Wikipedia

(Cryptographic) hash function

  • ≠ encryption
  • Also referred to as: One way hash functions
  • Use cases: integrity, signatures, ...
  • Examples: SHA1, SHA2 (256, 384, 512), SHA3, MD5

Symmetric cryptography

  • Secret key to encrypt plaintext → ciphertext
  • Same key to decrypt ciphertext → plaintext
  • “Intuitive” to understand

Symmetric cryptography

Symmetric cryptography

Source: Wikipedia

Symmetric cryptography

  • Types of ciphers: block vs. stream
  • Modes of operation: ECB, CBC, GCM, ...
  • Typical key lengths: 64, 128, 192, 256 bits
  • Examples: AES, DES, 3DES, RC4, Blowfish, ...
  • Key management does not scale well

Asymmetric cryptography

  • Different keys for encryption and decryption
  • Key pair: private and public key

Asymmetric cryptography

Asymmetric key pair

Source: Wikipedia

Public key encryption

  • Requires one key pair (of recipient)
  • Message encrypted with public key
  • Message decrypted with private key
  • Only recipient has private key

Public key encryption

Asymmetric cryptography

Source: Wikipedia

Digital signatures

  • Requires one key pair (of sender)
  • Digital signature = encrypted hash of message
  • Recipient needs to know public key of sender
  • Proves that sender has control over private key

Digital signatures

Digital signature

Source: Wikipedia

Key agreement / shared secret

  • Requires two key pairs
  • Both parties can derive same secret
  • Eavesdropper cannot derive secret

Key agreement / shared secret

Public key shared secret

Source: Wikipedia

Asymmetric cryptography

  • Details (= math) are complex and tricky
  • Examples: RSA, Diffie-Hellman (DH), Elliptic curve cryptography (ECC), ...
  • Typical key lengths: 1024, 2048, 4096 bits
  • Key management scales way better

Hybrid cryptosystem

  • Combination of symmetric & asymmetric crypto
  • Asymmetric crypto to establish connection and agree on key
  • Symmetric encryption for actual transmission of data
  • SSL/TLS is a hybrid cryptosystem

Hybrid cryptosystem

  • SSL/TLS
  • IPsec
  • OpenPGP
  • Messenger
  • ...

Hybrid cryptosystem

Symmetric RSA/DSA/DH ECC Hash function
80 1024 160 160
112 2048 224 224
128 3072 256 256
256 15360 512 512

Comparison of “strength”

Source: Bulletproof SSL and TLS, p. 18

SSL/TLS handshake

SSL/TLS handshake

  • Agree on capabilities and parameters
  • Authentication (certificates)
  • Agree on shared master secret
  • Verify that handshake has not been modified

SSL/TLS handshake

SSL/TLS handshake

Source: Cloudflare

ClientHello

					
Handshake protocol: ClientHello
	Version: TLS 1.2
	Random
		Client time: May 22, 2030 02:43:46 GMT
		Random bytes: b76b0e61829557eb4c611adfd2d36eb232dc1332fe29802e321ee871
	Session ID: (empty)
	Cipher Suites
		Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
		Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
		Suite: TLS_RSA_WITH_AES_128_GCM_SHA256
		Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
		Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
		Suite: TLS_RSA_WITH_AES_128_CBC_SHA
		Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA
		Suite: TLS_RSA_WITH_RC4_128_SHA
	Compression methods
		Method: null
	Extensions
		Extension: server_name
			Hostname: www.feistyduck.com
		Extension: renegotiation_info
		Extension: elliptic_curves
			Named curve: secp256r1
			Named curve: secp384r1
		Extension: signature_algorithms
			Algorithm: sha1/rsa
			Algorithm: sha256/rsa
			Algorithm: sha1/ecdsa
			Algorithm: sha256/ecdsa

ServerHello

					
Handshake protocol: ServerHello
	Version: TLS 1.2
	Random
		Server time: Mar 10, 2059 02:35:57 GMT
		Random bytes: 8469b09b480c1978182ce1b59290487609f41132312ca22aacaf5012
	Session ID: 4cae75c91cf5adf55f93c9fb5dd36d19903b1182029af3d527b7a42ef1c32c80
	Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	Compression method: null
	Extensions
		Extension: server_name
		Extension: renegotiation_info

Certificate

  • Optional, but typically sent
  • Typically X509 certificate chain
  • Chain without root
  • in ASN.1 DER encoding

ServerKeyExchange

  • Additional data for key exchange
  • Content depends on cipher suite, etc.

ServerHelloDone

  • All done from server side
  • Wait for further messages from client

ClientKeyExchange

  • Client data for key exchange

ChangeCipherSpec

  • Switching to encryption

Finished

  • Signal that handshake is complete
  • Used to verify integrity of handshake

Client authentication

  • Server can request authentication from client
  • Communicated via CertificateRequest message

Server Name Indication (SNI)

  • Client sends “hostname” along with ClientHello
  • Server can respond with correct certificate, etc.

Authentication

  • Implicitly authentication during handshake
  • Tightly coupled with key exchange
  • Details require more cryptographic know-how
  • RSA, DH, DHE, ECDH, ECDHE, ...
  • ≠ RSA / DSA / ECDSA certificates

Handshake (RSA)

SSL handshake with RSA

Source: Cloudflare

Handshake (RSA)

  • Client generates secret
  • Encrypts it with server's public key
  • Only server can decrypt it
  • Problem: Forward secrecy
  • Problem: Bleichenbacher “attack”

Handshake (DH/DHE/ECDH/ECDHE)

SSL handshake with DH

Source: Cloudflare

Handshake (DH/DHE/ECDH/ECDHE)

  • Shared secret is derived via Diffie-Hellmann
  • Both parties contribute to the shared secret
  • Signature (e.g. RSA) is used for integrity
  • Forward Secrecy

Session resumption

  • Initial handshake is “expensive”
  • Idea: Re-use already existing sessions
  • Two concepts: Session IDs & session tickets

Session IDs

  • Both parties store context for some period of time
  • Server provides session ID in ServerHello
  • Client remembers session ID and sends it with next ClientHello
  • Server accepts session ID
  • Regenerate session keys
  • ...

Session IDs

Session resumption with session ID

Source: Cloudflare

Session tickets

  • Only later introduced (RFC 4507, RFC5077)
  • State is kept by the client (encrypted)
  • Otherwise similar to session IDs

Session tickets

Session resumption with session ticket

Source: Cloudflare

Session tickets

generate session ticket keys randomly, distribute them to the servers without ever touching persistent storage and rotate them frequently.

Adam Langley

Session resumption

TLS Session Resumption: Full-speed and Secure

Attacks on SSL/TLS

Classes of attacks

  • Implementation issues
  • Protocol attacks

Implementation issues

  • Flaws with certification validation
  • Random number generation, entropy, ...
  • Heartbleed
  • Export grade crypto (FREAK, Logjam, ...)
  • Downgrade attacks
  • ...

Protocol attacks

  • BEAST
  • Lucky 13
  • RC4 weaknesses
  • POODLE
  • SLOTH
  • DROWN
  • Sweet32
  • NSA's Bullrun
  • ...

Protocol attacks

  • Details are very complex
  • Some attacks are easy to exploit
  • Some attacks are (mostly) theoretical
  • Cryptography is constantly evolving

Importance of crypto agility

  • BEAST attack announced in 2011
  • → block ciphers unsafe to use with ≤ TLS 1.0
  • Support for TLS 1.1 & TLS 1.2 was lacking
  • Recommendation: Use RC4
  • → In 2013 ~ 50% RC4 usage

Importance of crypto agility

  • RC4 is a symmetric stream cipher
  • Was designed by Ron Rivest in 1987
  • Easy to implement and very fast
  • Biases & weaknesses
  • More weaknesses became known ~ 2013

Importance of crypto agility

  • TLS 1.1 and above are not affected by BEAST
  • Block ciphers with AEAD
  • Implementation and deploy rates have changed
  • 2015 RFC 7465 forbid further usage of RC4 in TLS
  • Modern browsers removed RC4 during 2016
  • → Currently only ~ 15% RC4 support
  • → Good security, broken appliances

TLS 1.3

What's new?

TLS 1.3

  • Latest version of TLS protocol
  • Started in 2013, finalized in 2018
  • Faster, easier, more secure
  • Already implemented and widely used ...
  • RFC8446

Improved security

  • Removed RSA key exchange in favor of DHE
  • Diffie-Hellman named groups
  • Removed troublesome ciphers
  • Only AEAD ciphers
  • Removed PKCS#1 v1.5 in favor of RSA-PSS
  • Signing entire handshake
  • Simplified cipher suite negotiation

Improved performance

  • 1-RTT mode
  • 0-RTT resumption

1-RTT mode

  • Reduced options for cipher suite negotation
  • Parameters for key exchange are easy to guess (
    ECDHE
    with 
    X25519
    or 
    P-256
    )
  • Client send DH key shares in the first message
  • When server does not support the key shares, server can send 
    HelloRetryRequest
TLS 1.2 DH handshake

Source: Cloudflare

TLS 1.3 DH handshake

Source: Cloudflare

0-RTT resumption

  • Client & server derive resumption master secret during session
  • Can be stored session ID or as ticket on client
  • Upon resumption, client uses PSK to encrypt data
  • Improved performance, but ...

0-RTT attack

0-RTT-attack

Source: Cloudflare

0-RTT attack

More resources on TLS 1.3

Recommendations & powerful tools

SSL server test: Good

Qualys SSL report

Source: SSL Labs

SSL server test: Bad

Qualys SSL report

Source: SSL Labs

SSL server test: Ugly

Qualys SSL report

Source: SSL Labs

Q&A