Transport Layer Security The TLS Protocol Transport Layer Security - - PowerPoint PPT Presentation

IN3210 – Network Security

Transport Layer Security

The TLS Protocol

Transport Layer Security (TLS)

⚫ Security goals:

− Authentication − Integrity − Confidentiality

⚫ Transparent security protocol between TCP and application ⚫ Widespread usage:

− HTTP over TLS (HTTPS), IMAP over TLS (IMAPS), …

⚫ Security for single application (in contrast to IPSec):

− Online Banking − Online Shopping

3

History of SSL/TLS

⚫ 1994: SSL 1.0 – Developed by

Netscape Communications (never released)

⚫ 1995: SSL 2.0 – Published with Netscape Navigator 1.1

(officially deprecated 2011)

⚫ 1996: SSL 3.0 – Fixes severe security issues found in SSL 2.0

(officially deprecated 2015)

⚫ 1999: TLS 1.0 – RFC 2246 (deprecation planned for 2020) ⚫ 2006: TLS 1.1 – RFC 4346 (deprecation planned for 2020) ⚫ 2008: TLS 1.2 – RFC 5246 ⚫ 2018: TLS 1.3 – RFC 8446

4

TLS Versions supported by Web Servers

5 Source: https://www.ssllabs.com/ssl-pulse/

2013 2014 2015 2016 2017 2018 2019

History of SSL/TLS

⚫ https://www.feistyduck.com/ssl-tls-and-pki-history/

6

TLS < 1.3

7

TLS: Protocols and Layers

9

Handshake Change Cipher Spec Alert Application Data TLS Record Layer TCP Layer IP Layer

TLS Handshake

⚫ Negotiation of cryptographic algorithms + parameters ⚫ Authentication of communication partners

(just server or mutual)

⚫ Exchange of symmetric session key

10

Hand- shake Change Cipher Spec Alert Appli- cation Data TLS Record Layer TCP Layer IP Layer

TLS Record Layer

⚫ „Core functionality“ of TLS ⚫ Accepts data from upper layer and performs (in that order):

− Fragmentation − Compression − Authentication (e.g. MAC) using session key − (Symmetric) Encryption using session key

11

Hand- shake Change Cipher Spec Alert Appli- cation Data TLS Record Layer TCP Layer IP Layer

Key Exchange + Server Authentication

⚫ RSA Encryption (simplified)

− Server sends public key (inside a X.509 certificate) − Client generates random number (premaster secret, PS) − Client encrypts PS using the server public key and sends the result − Server decrypts PS using its private key sk − All further communication is encrypted with session key derived from PS − (Implicit) authentication: only the owner of the private can participate in further communication

12

(pk, sk) pk PS Epk(PS)

Key Exchange + Server Authentication

⚫ Attacks on RSA Encryption

− Attacker eavesdrops communication:

→ can not decrypt encrypted key

− Attacker replaces Epk(PS) with Epk(PS*) with PS* known to her

→ has negotiated a shared key with the server, but not with the client (i.e. can not communicate with the client)

− Attacker replaces server public key with the attacker's public key

→ Public keys are protected by certificate, client can detect the change

• public key does not match the certificate
• certificate is issued to wrong subject

13

Key Exchange + Server Authentication

⚫ Diffie Hellman Key Exchange

− Client and server generate DH secret value a and b − Client and server calculate DH public value ga and gb and send it − Server sends public key (inside a X.509 certificate) − Server creates signature over gb (using its private key sk) and send it − Client verifies signature − Client and server calculate the DH shared secret (premaster secret, PS) − All further communication is encrypted with session key derived from PS

14

b gb a ga (pk, sk) pk Sig(gb)

Key Exchange + Server Authentication

⚫ Attacks on Diffie Hellman Key Exchange

− Attacker eavesdrops communication

→ can not break DH key exchange

− Attacker replaces gb

→ signature does not match

− Attacker replaces pk with her own public key (and creates signature with her own private key)

→ public keys are protected by certificate, client can detect the change

− Attacker replace ga with ge (e know to attacker)

→ has negotiated a shared key with the client, but not with the server (i.e. can not communicate with the server)

15

Forward Secrecy

⚫ A key exchange protocol offers (perfect) forward secrecy

 the session key is not compromised even if the private server key is compromised

⚫ Imagine the following situation:

− Attacker records the complete handshake − Attacker learns later (after the protocol has finished) the private key

⚫ RSA:

− Attacker uses the private to decrypt the premaster secret + calculates the session key → no forward secrecy

⚫ DH:

− Attacker can still not break the DH key exchange → forward secrecy − Session key is “ephemeral”

16

TLS Handshake (here: using RSA)

⚫ Client Hello:

− Supported algorithms − 1. random number

⚫ Server Hello:

− Selected algorithms − 2. random number − Session ID

⚫ Client Key Exchange:

− Encrypted premaster secret

⚫ Change Cipher Spec:

− Starts message protection

⚫ Finished:

− Authenticates all previous messages (protects from downgrade attacks)

Server Client

Session key calculation

2 RTT

17

encrypted

TLS Handshake (here: using DH)

⚫ Client +Server Key Exchange:

− Diffie Hellman key exchange − (with Server Key Exchange signed) − Groups:

▪ “DHE”: Finite Field DH ▪ “ECDHE”: Elliptic Curve DH

18

Server Client

Session key calculation

encrypted

TLS Handshake – Details (1)

⚫ Algorithms

− Different types of algorithms bundled into “Cipher Suites” − Format: TLS_key-exchange-algorithm_WITH_data-protection-algorithm − Example: TLS_DHE_WITH_AES_128_CBC_SHA256

▪ DHE = Diffie Hellman key exchange (E = ephemeral) ▪ AES with CBC mode for encryption ▪ SHA256 as hash function for authentication and integrity protection

⚫ Client offers list of cipher suites – server selects one ⚫ Further examples for Cipher Suites:

− TLS_RSA_WITH_RC4_128_SHA − TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

19

TLS Handshake – Details (2)

⚫ Random numbers in ClientHello and ServerHello

− Client and Server select independently random numbers − Random numbers are included in session key calculation

⚫ Certificate

− Most Cipher Suites required certificates for server authentication − X.509 format

⚫ Session ID

− For new session

▪ Client sends empty session ID field ▪ Server chooses session ID

− For resumed session

▪ Client sends known session ID

20

TLS Handshake – Session Key Calculation

⚫ Key material calculation

(general)

− Uses “Key Expansion” − Internally using a pseudo random function (based on hash function) − Can produce arbitrary length key material

⚫ Master secret calculation

− Input: Premaster Secret, random number client, random number server − Output: Master Secret (48 byte)

⚫ Encryption/MAC key calculation

− Input: Master Secret, random number client, random number server − Output: Key block, is partitioned into required keys

21

Random (Client) Random (Server) Premaster secret

PRF PRF

Master secret Key Block Client MAC Server MAC

. . .

TLS Handshake – Session Key Calculation

⚫ Required keys:

− Encryption (Client) − Encryption (Server) − Authentication / MAC (Client) − Authentication / MAC (Server) − Initialization Vectors

22

TLS: Resuming Sessions

⚫ “Client Hello” contains session ID

• f session to be resumed

⚫ Server responds with same

session ID

⚫ No key exchange required

23

Client Server

TLS: Client Authentication

⚫ Client authentication with

certificate optional in TLS

− Server

▪ “Certificate Request” requests client authentication

− Client:

▪ “Certificate”: client certificate ▪ “Certificate Verify”: signature over previous messages (proves ownership of private key)

24 24

Server Client

TLS 1.3

25

Major Changes in TLS 1.3

⚫ Removal of old algorithms

− e.g. RC4, SHA-1

⚫ Removal of insecure methods

− CBC, compression, “MAC then encrypt”

⚫ Removal of non-forward-secrecy key exchange

− RSA, “DH static”

⚫ Simpler and faster handshake:

− in most cases 1-RTT − even 0-RTT possible

⚫ Many cryptographic improvements

− e.g. EC, padding, DH groups

⚫ Better privacy

− more encrypted protocol parameters

26

TLS Handshake (1 RTT)

⚫ Client assumes a key agreement

protocol

⚫ Sends key share for this

protocol in his first message

⚫ Client Hello:

− Supported algorithms (incl. guessed key agreement protocol) − Client key share

⚫ Server Hello:

− Chosen algorithms (incl. key agreement protocol) − Server key share

27

Server Client

Session key calculation

encrypted

1 RTT

TLS Handshake– Details

⚫ Supported algorithms (always DH key exchange!):

− Cipher suites:

▪ TLS_AEAD_HASH

• AEAD: The authenticated encryption algorithm for record protection
• HASH: The hash algorithm for key derivation

▪ TLS_AES_128_GCM_SHA256 ▪ TLS_AES_256_GCM_SHA384 ▪ TLS_CHACHA20_POLY1305_SHA256

− Diffie Hellman group:

▪ Elliptic curve (e.g. secp256r1, x25519) ▪ Finite field (e.g. 2048 bit, 3072 bit)

− Signature algorithm (e.g. ECDSA, RSA)

28

AES with Galois/Counter Mode (GCM)

⚫ Combines encryption

and authentication

29 Image Source: Wikipedia

TLS Handshake (2 RTT)

⚫ If client has guessed the wrong

key agreement → additional RTT is required

⚫ Hello Retry Request

− Chosen Key Agreement protocol

30

Server Client

Session key calculation

encrypted

2 RTT

TLS Handshake (0 RTT)

⚫ If client and server already have

a shared key (from a previous session) → application data can be sent (encrypted) on the first flight

⚫ Weaker security properties

(e.g. no replay protection)

⚫ Should not be used not for

requests triggering an action (e.g. shopping, banking)

⚫ Can be used e.g. for requesting

a (static) Web page

31

Server Client

encrypted

0 RTT

TLS and „Security Monitoring“ (1)

⚫ In TLS all application data encrypted ⚫ Parameters visible to an external “monitor”:

− IP address (no very helpful) − Server name from certificate

⚫ However in TLS 1.3:

− Certificate is encrypted − Increases privacy − Makes surveillance harder

32

TLS 1.2 TLS 1.3

Monitors:

• Enterprise
• Provider
• Intelligence Agency

TLS and „Security Monitoring“ (2)

⚫ Nowadays the insecure key exchange methods in TLS <1.3

are (mis-)used for network monitoring:

− All network traffic is copied to the monitor − Monitor has a copy of the server’s private key − Monitor can decrypt the RSA key exchange (or DH with static keys) − Monitor can decrypt all traffic

⚫ This is not possible any more with TLS 1.3 ⚫ ETSI created an alternative security protocol: ETS (formerly

eTLS) still allowing interception

33

TLS and „Security Monitoring“ (2)

34

Further Details on TLS

35

Server Name Identification

36

192.0.2.1 www.example.org www.mypage.name

⚫ Common Web hosting:

− 1 Web server (1 IP address) − multiple domain names/Web pages − Web server demultiplexes requests

⚫ How does the server know the

target domain/pages)?

⚫ HTTP/1.1:

− Mandatory header field “host”

GET /index.html HTTP/1.1 Host: www.example.org

Server Name Identification

37

192.0.2.1 www.example.org www.mypage.name

⚫ Problem with HTTP over TLS hosting:

− Different domains/pages have different certificates (+ private keys) − Web server must select certificate at the beginning of the TLS connection, i.e. before the HTTP request

⚫ Solution:

− Host name is (additionally) sent inside the client hello message (SNI, server name identification)

TLS: Implementation Aspects

⚫ TLS implemented on application level

− For example by using the openssl library

⚫ Application (or even the user) decides about security level

− Advantages? Disadvantages?

⚫ How to choose TLS protected connection:

− Browser: URL starts with “https” − TLS protected service typically offered on different port:

▪ 80 (http) 443 (https) ▪ 143 (IMAP) 993 (IMAPS)

38

Opportunistic TLS

⚫ Some protocols allows switching to TLS protection inside

given connection (“STARTTLS”)

⚫ Most common usage: SMTP, IMAP, POP3 ⚫ Example (SMTP/STARTTLS):

[establish TCP connection] S: 220 mail.example.org ESMTP service ready C: EHLO client.example.org S: 250 mail.example.org offers a warm hug of welcome S: 250 STARTTLS C: STARTTLS S: 220 Go ahead [TLS handshake] C: EHLO client.example.org [TLS secured]

39 Example Source: Wikipedia

UDP Security

⚫ Problem:

− TLS can only be used with TCP

⚫ Approach for UDP:

− Security mechanisms moved into application − Datagram TLS (RFC 4347)

▪ Secures individual packets ▪ Packet loss and packet order no issue with UDP ▪ Reliable transport of handshake messages

40

Attacks on TLS

41

Padding Oracle Attack

⚫ Recapitulation: Block cipher and Padding ⚫ Encryption:

− Fill plaintext to multiple of block size (padding) − Encrypt

⚫ Decryption:

− Decrypt − Verify padding (e.g. PKCS #5) − If padding invalid (e.g. PKCS #5: ... 08 02) send an error messages

42

Padding Oracle

⚫ A send encrypted messages (using CBC) to B ⚫ E eavesdrops encrypted messages ⚫ E sends modified messages to B ⚫ B decrypts messages and responses with “Padding Error” or

“OK”

43

A E B c c* k c = Enck(p) k Deck(c) Deck(c*)

OK / Error

Padding Oracle

⚫ A and B communicating using

block cipher with CBC mode (decryption at B illustrated)

⚫ E has picked up 2 cipher text blocks

(for simplification let’s assume E knows IV and c0 and c0 includes the end of a message) → E wants to learn p0

⚫ If E sends cipher text to B, B decrypts the cipher text and

sends error message if padding of decrypted message is invalid

⚫ In practice: even if B does not explicitly send error messages,

E can often derive the result of the padding verification (e.g. timing, behavior)

44

IV p0 p1

D

c0 c1

D

p2 c2

D

Padding Oracle

45

XX XX XX XX XX XX XX XX

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

A4 17 D3 94 01 BD 81 0A XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 B: OK ⊕ =

XX: unknown to E

Padding Oracle

46

XX XX XX XX XX XX XX XX

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

F0 17 D3 94 01 BD 81 0A XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 B: OK ⊕ =

Padding Oracle

47

XX XX XX XX XX XX XX XX

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

F0 A9 D3 94 01 BD 81 0A XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 B: OK ⊕ =

Padding Oracle

48

XX XX XX XX XX XX XX XX

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

F0 A9 56 94 01 BD 81 0A XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 B: Error Checked by B = Padding ⊕ =

Padding Oracle

49

XX XX 06 06 06 06 06 06

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

A4 17 D3 94 01 BD 81 0A XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 ⊕ =

Padding Oracle

50

XX XX 06 06 06 06 06 07

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

A4 17 D3 94 01 BD 81 0B XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 ⊕ =

0A  06  07

Padding Oracle

51

XX XX 07 07 07 07 07 07

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

A4 17 D2 95 00 BC 80 0B XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 ⊕ = B: Error

Padding Oracle

52

XX XX 07 07 07 07 07 07

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

A4 D2 95 00 BC 80 0B XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 ⊕ = B: OK

00 01 02 03 04 05 06 07 08 09 0A

B: Error

Padding Oracle

53

XX 07 07 07 07 07 07 07

𝑞0 = 𝐸𝑙(𝑑0) ⊕ 𝐽𝑊

IV p0

D

c0

A4 0A D2 95 00 BC 80 0B XX XX XX XX XX XX XX XX

𝑞0 𝐸𝑙(𝑑0) 𝐽𝑊 ⊕ =

p0[1] = 0A  07  17 = 1A

Padding Oracle

⚫ Number of guesses for recovering a complete block (128 bit):

− “Simple” brute fore: 2128 − Padding oracle: 16 * 256 = 212

54

Attack on CBC

⚫ Recapitulation: CBC mode

for encryption

⚫ Prerequisite for attack:

attacker can choose plain text

⚫ Attacker guesses 𝑞𝑗 = 𝑦 ⚫ For plain text 𝑞𝑘 he chooses 𝑦 ⊕ 𝑑𝑗−1 ⊕ 𝑑

𝑘−1

⚫ If guess is correct:

𝑑

𝑘 = 𝐹 𝑛𝑘 ⊕ 𝑑 𝑘−1 = 𝐹 𝑦 ⊕ 𝑑𝑗−1 ⊕ 𝑑 𝑘−1 ⊕ 𝑑𝑗−1 =

= 𝐹 𝑦 ⊕ 𝑑𝑗−1 = 𝐹 𝑛𝑗 ⊕ 𝑑𝑗−1 = 𝑑𝑗

⚫ If guess is not correct, repeat attack

55

IV p0 p1

E

c0 c1

E

p2 c2

E

Attack on CBC

⚫ BEAST attack (2011)

− attacker places JavaScript code in legitimate Web site (e.g. via iFrame) − Attack program can send arbitrary data over existing TLS connection → requirements for attack fulfilled − Attack program tries for guess the cookie for legitimate Web Site

56

TLS

Attack on CBC

⚫ Countermeasures:

− Upgrade to TLS 1.1 or TLS 1.2 → new IV for each record − Sending empty blocks in the beginning → guessing is harder − Avoiding CBC mode → GCM mode recommended − Use of RC4 (but check also next slide)

57

RC4

⚫ Stream cipher ⚫ Developed 1987 by Ron Rivest ⚫ Widespread usage in TLS and WEP ⚫ Weaknesses in „randomness“ ⚫ Given enough different encryption of the same plaintext

the plaintext can be recovered

⚫ Not recommend any more

Famous Attacks on TLS

⚫ Downgrade Attacks

− POODLE − FREAK − Logjam

⚫ Padding Oracle

− Lucky Thirteen − ROBOT

⚫ Misusing CBC

− BEAST

⚫ Misusing Compression

− CRIME

59

TLS and the Web

60

Security for the Web

⚫ Typical usage:

− Confidentiality: TLS − Integrity: TLS − Authentication (Server → Client): TLS / Certificate − Authentication (Client → Server):

▪ Password (entered into HTML form) transported via HTTP POST ▪ Advantages / disadvantages compared to TLS client authentication?

TLS in the Browser

TLS in the Browser

⚫ The browser is checking:

− Was the TLS handshake successful? (this proves that the server owns the private key) − Hostname address bar = Hostname inside certificate? − Exists signed chain from server certificate to trustworthy CA? − Is certificate still valid? − Was the certificate not revoked?

TLS in the Browser

Summary

65

Summary

⚫ TLS most widespread security protocol for layer 4 ⚫ Allows application specific security ⚫ User can directly influence security level ⚫ Problems:

− certificate management − usage of insecure algorithms → regular configuration verification − weaknesses in protocol or implementation

66

Practical Usage Recommendations

⚫ Server test: https://www.ssllabs.com/ssltest/ ⚫ TLS version: 1.2 (or 1.3) ⚫ Key Exchange: (ephemeral) Diffie Hellman (EC or FF) ⚫ Encryption/Integrity: AES/GCM ⚫ Hash (MAC, Key Derivation): SHA-2

67