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 CA signs with its private key ◮ signer information + signature over all these fields 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 application ◮ confidentiality and data integrity (not signed artifacts) TLS ◮ peer authentication ◮ client-server TCP ◮ transparent for applications e. g., IMAPS, HTTPS IP ◮ 1996: SSL 3.0, 2008: TLS 1.2 ◮ TLS 1.3 in development link layer 14 / 41

Subprotocols change application handshake alert cipher spec data record 15 / 41

Record protocol 0 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 header ciphertext 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 r a n d o m random n d s ) ( D H , r n a t u r e D H , s i g DH c e r t , n d o m , r a verify certificate verify signature DH compute DH compute auth D H , a u t h e n t i c a t o r compute DH verify auth compute auth o r e n t i c a t a u t h verify auth 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 o o n e e r H e l l o D g e S e r v y E x c h a n e r v e r K e fi c a t e S l l o C e r t i S e r v e r H 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 i n i s h e d e r S p e c F n g e C i p h C h a 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 0 outside inside TCP any 443 accept 1 2001:db8::/32 inside deny 2 outside inside accept 3 inside outside 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 outgoing 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 router Internet local network 31 / 41

Architecture: screened subnet DMZ ext Internet int local network 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