IN3210 Network Security Transport Layer Security · Transport Layer Security (TLS) ... −Client...

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

So

urc

e: h

ttp

s://

ww

w.s

slla

bs.

com

/ssl

-pu

lse

/

2013201420152016201720182019

History of SSL/TLS

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

6

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

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

ChangeCipher

Spec

Alert Appli-cationData

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

ChangeCipher

Spec

Alert Appli-cationData

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)pkPS

Epk(PS)


⚫ 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

o public key does not match the certificate

o certificate is issued to wrong subject

13


⚫ 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 PS14

bgba

ga(pk, sk)

pk Sig(gb)


⚫ 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)

ServerClient

Ses

sio

n k

ey c

alcu

lati

on

2 RT

T

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

ServerClient

Ses

sio

n k

ey c

alcu

lati

on

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 PRFMaster secret

Key B

lock

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 of 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)

2424

ServerClient

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

ServerClient

Ses

sio

n k

ey c

alcu

lati

on

encrypted 1 RT

T

TLS Handshake– Details

⚫ Supported algorithms (always DH key exchange!):− Cipher suites:

▪ TLS_AEAD_HASH

o AEAD: The authenticated encryption algorithm for record protection

o 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

Imag

e S

ou

rce:

Wik

iped

ia


⚫ If client has guessed the wrong key agreement → additional RTT is required

⚫ Hello Retry Request− Chosen Key Agreement protocol

30

ServerClient

Ses

sio

n k

ey c

alcu

lati

on

encrypted

2 RT

T


⚫ 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

ServerClient

encrypted

0 RT

T

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

32TLS 1.2TLS 1.3

Monitors:• Enterprise• Provider• Intelligence Agency


⚫ 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


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.1Host: 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

Exam

ple

Sou

rce:

Wik

iped

ia

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

Bc

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


𝑝0

𝐷𝑘(𝑐0)

𝐼𝑉

B: OK

⊕

=

XX: unknownto E

Padding Oracle

46


𝑝0 = 𝐷𝑘(𝑐0) ⊕ 𝐼𝑉

IV

p0

D

c0

F0 17 D3 94 01 BD 81 0A


𝑝0

𝐷𝑘(𝑐0)

𝐼𝑉

B: OK

⊕

=

Padding Oracle

47


𝑝0 = 𝐷𝑘(𝑐0) ⊕ 𝐼𝑉

IV

p0

D

c0

F0 A9 D3 94 01 BD 81 0A


𝑝0

𝐷𝑘(𝑐0)

𝐼𝑉

B: OK

⊕

=

Padding Oracle

48


𝑝0 = 𝐷𝑘(𝑐0) ⊕ 𝐼𝑉

IV

p0

D

c0

F0 A9 56 94 01 BD 81 0A


𝑝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


𝑝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


𝑝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


𝑝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


𝑝0

𝐷𝑘(𝑐0)

𝐼𝑉

⊕

=

B: OK

000102030405060708090A

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


𝑝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 modefor 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 plaintextthe 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

https://www.ssllabs.com/ssltest/

Date post:	03-Oct-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

IN3210 Network Security Transport Layer Security · Transport Layer Security (TLS) ... −Client...

Documents