iLab TLS and packet filters Benjamin Hof hof@in.tum.de Lehrstuhl - - PowerPoint PPT Presentation

iLab

TLS and packet filters Benjamin Hof hof@in.tum.de

Lehrstuhl für Netzarchitekturen und Netzdienste Fakultät für Informatik Technische Universität München

Lab 7 – 17ws

1 / 41

Outline

Trust Transport Layer Security Packet filter Netfilter

2 / 41

Outline

Trust Transport Layer Security Packet filter Netfilter

3 / 41

Security in the Internet threat model

◮ secure endpoints ◮ insecure network ◮ parties have public-key pairs ◮ one party sends public key 4 / 41

Establishing trust

Problem: I see this key, but does it really belong to mail.in.tum.de.?

Possibilities

• 1. certificate authorities (CA) spanning public key infrastructure

(PKI)

• 2. web of trust
• 3. trust on first use
• 4. pin
• 5. . . .

5 / 41

Certificate

◮ public key ◮ entity name ◮ validity period ◮ signer information

+ signature over all these fields CA signs with its private key

6 / 41

Certification process

◮ issued by CA ◮ prove control over domain to CA ◮ CA signs with its private key: your public key, other certificate

information

◮ certificate is sent to you ◮ CAs bind names to keys ◮ Browser/OS come with a list of trusted CA certificates. 7 / 41

Revocation

◮ e. g. when private key is compromised ◮ collected in a signed certificate revocation list (CRL) ◮ query the CA with the online certificate status protocol (OCSP) ◮ essentially unsolved right now 8 / 41

Certificate verification

◮ trusted CA ◮ name correct ◮ validity period ◮ valid signature ◮ not revoked

If all conditions are fulfilled, the certificate is considered verified. Party is authenticated, but no statement on trustworthiness!

9 / 41

CA/Browser Forum

◮ voluntary association ◮ negotiate the rules and controls for issuance ◮ different levels of assurance without security benefit 10 / 41

Problems

◮ many trusted CAs ◮ very difficult to remove CAs ◮ any CA may sign a certificate for anyone, anywhere ◮ tons of misissuances ◮ CAs by governments ◮ CAs have been compromised ◮ CAs have sold person-in-the-middle boxes ◮ certificate revocation problematic ◮ complicated format 11 / 41

Certificate transparency

Idea

◮ irrevocably publish issuances ◮ enable everybody to check if presented certificate was published ◮ no hiding of misissuances anymore ◮ open and public ◮ multiple logs ◮ efficient check if certificate is in log ◮ efficient check if only append operations have been done in this

log

◮ Chrome will demand CT starting April 2018 ◮ Firefox: unclear, some work has been done 12 / 41

Outline

Trust Transport Layer Security Packet filter Netfilter

13 / 41

Transport Layer Security

◮ confidentiality and data integrity

(not signed artifacts)

◮ peer authentication ◮ client-server ◮ transparent for applications e. g.,

IMAPS, HTTPS

◮ 1996: SSL 3.0, 2008: TLS 1.2 ◮ TLS 1.3 in development

application TLS TCP IP link layer

14 / 41

Subprotocols

handshake change cipher spec alert application data record

15 / 41

Record protocol

7 8 15 16 23 24 31

type major version minor version length length data

16 / 41

Record processing

seq#, header SDU MAC SDU MAC tag padding encrypt ciphertext header Data may be fragmented into multiple records.

17 / 41

Example handshake

Goals

◮ DH key agreement with server authentication ◮ establish session keys

Approach

• 1. exchange random values
• 2. DH exchange
• 3. server signs its DH and the random values
• 4. use DH result and random values to:

◮ authenticate handshake ◮ derive session keys, IVs

18 / 41

Conceptual view

random random DH verify certificate verify signature DH compute DH compute auth compute DH verify auth compute auth verify auth r a n d

• m

r a n d

• m

, c e r t , D H , s i g n a t u r e ( D H , r n d s ) D H , a u t h e n t i c a t

• r

a u t h e n t i c a t

• r

master_secret ≈ PRF(DH_result, random_values) authenticator ≈ PRF(master_secret, Hash(handshake_msgs))

19 / 41

TLS handshake (PFS with server authentication)

C l i e n t H e l l

• S

e r v e r H e l l

• C

e r t i fi c a t e S e r v e r K e y E x c h a n g e S e r v e r H e l l

• D
• n

e C l i e n t K e y E x c h a n g e C h a n g e C i p h e r S p e c F i n i s h e d C h a n g e C i p h e r S p e c F i n i s h e d

• 1. DH results: “pre master secret” (PMS)
• 2. use PMS and random values to generate “master secret” (MS)
• 3. MS and random values used to:

◮ authenticate handshake ◮ derive session keys

20 / 41

Observations

◮ old, not cleanly designed (MtE, CBC. . . ) ◮ rather well studied ◮ libraries hard to use ◮ tons of options, e.g. session resumption ◮ confidentiality and integrity optional ◮ “Cloudflare problem” ◮ good for centralized authority control ◮ bad for decentralized caching ◮ we don’t know how to retire broken old versions 21 / 41

Problems

◮ “security devices”, corporate “firewalls”, “virus scanners”

◮ hold back phase out of broken version ◮ hold back modernization (TLS 1.3)

◮ warnings ineffective and useless for humans ◮ plus all the CA problems 22 / 41

23 / 41

Recommendations

◮ don’t go home-brewed ◮ keep your library up to date. . . ◮ offer v1.2 ◮ HSTS ◮ switch off compression ◮ ECDHE for fast forward security ◮ only AES cipher suites ◮ prefer AES-GCM

Only TLS 1.2 with GCM is cryptographically secure.

24 / 41

Outline

Trust Transport Layer Security Packet filter Netfilter

25 / 41

Network access control

Establish requirements, formulate security policy, enforce them with security mechanisms. Examples:

◮ link layer

◮ MAC filter ◮ 802.1X authentication

◮ network/transport layer

◮ packet filter

◮ application layer

◮ URL filtering HTTP proxy

26 / 41

Basic strategies

◮ default deny: whitelisting

◮ more secure

◮ default permit: blacklisting

◮ more convenient

27 / 41

Simple example

◮ packet traverses rules ◮ traffic from 2001:db8::/32 is only allowed on HTTPS ◮ permit other incoming ◮ permit outgoing 28 / 41

Simple example

◮ packet traverses rules ◮ traffic from 2001:db8::/32 is only allowed on HTTPS ◮ permit other incoming ◮ permit outgoing

rule src dst proto src port dst port action

• utside

inside TCP any 443 accept 1 2001:db8::/32 inside deny 2

• utside

inside accept 3 inside

• utside

accept

◮ rules are matched sequentially ◮ make IPv4 and IPv6 consistent 28 / 41

Flow

5-tuple

◮ src IP ◮ dst IP ◮ layer 4 protocol ◮ src port ◮ dst port 29 / 41

Packet filtering

• 1. stateless

◮ look only at packets ◮ fast, little memory access ◮ use for IP filters or to handle many addresses

30 / 41

Packet filtering

• 1. stateless

◮ look only at packets ◮ fast, little memory access ◮ use for IP filters or to handle many addresses

• 2. stateful

◮ look at flows ◮ packets may generate state ◮ smarter, e. g.: ◮ only allow incoming UDP packets when matching previous

• utgoing packet to corresponding 5-tuple

◮ match ICMP port unreachable with the corresponding TCP

stream

◮ need to protect against DoS, e. g. with connection rate limiting

30 / 41

Architecture: simple packet filter

Internet router local network

31 / 41

Architecture: screened subnet

Internet ext int local network DMZ bastion host

32 / 41

Must have

◮ use a packet filter to implement ingress filtering (BCP 38) ◮ remember DoS using DNS spoofing/amplification! 33 / 41

Limitations

Packet filters do not protect against:

◮ attacks from inside (caused by phishing, drive-by) ◮ connections not going through it (WLAN, UMTS) ◮ higher-layer attacks ◮ wrong configuration 34 / 41

Outline

Trust Transport Layer Security Packet filter Netfilter

35 / 41

nftables

◮ packet traverses rules ◮ rule: match header and take action ◮ modules provide wide variety of matching options ◮ actions: go to other chain, drop, accept, reject, SNAT. . . ◮ rules added to empty predefined and custom chains ◮ chains organized in tables

Implications on performance?

36 / 41

Jan Engelhardt, CC-BY-SA

37 / 41

Example ruleset (incomplete)

nft add rule ip6 filter input icmpv6 type echo-request accept nft add rule ip6 filter input tcp dport 443 accept

38 / 41

Example ruleset (incomplete)

table ip6 filter { chain input { type filter hook input priority 0; policy drop; iifname lo accept ct state established accept tcp dport 22 ct state new accept } } States are: invalid, new, established, related, untracked, (snat, dnat)

39 / 41

Chain design

• 1. coarse match, jump into chain
• 2. there: fine grained matches

generally:

◮ optimize for number of matches of most packets ◮ no rejects redundant with policy ◮ ESTABLISHED only needed once 40 / 41

Recommended sources

◮ Engelhardt: Towards the perfect ruleset ◮ Engelhardt: packet flow diagramme ◮ man 8 nftables ◮ wiki.nftables.org 41 / 41