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 – 18ss

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

I secure endpoints
I insecure network

I parties have public-key pairs

I 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

I public key
I entity name
I validity period CA signs with its private key
I signer information
+ signature over all these fields

6 / 41
Certification process

I issued by CA
I prove control over domain to CA
I CA signs with its private key: your public key, other certificate
information
I certificate is sent to you

I CAs bind names to keys

I Browser/OS come with a list of trusted CA certificates.

7 / 41
Revocation

I e. g. when private key is compromised

I collected in a signed certificate revocation list (CRL)
I query the CA with the online certificate status protocol (OCSP)
I essentially unsolved right now

8 / 41
Certificate verification

I trusted CA
I name correct
I validity period
I valid signature
I 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

I voluntary association
I negotiate the rules and controls for issuance
I different levels of assurance without security benefit

10 / 41
Problems

I many trusted CAs

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

11 / 41
Certificate transparency
Idea
I irrevocably publish issuances
I enable everybody to check if presented certificate was published
I no hiding of misissuances anymore

I open and public

I multiple logs
I efficient check if certificate is in log
I efficient check if only append operations have been done in this
log

I Chrome demanded CT starting April 2018

I Safari will demand CT starting October 2018
I Firefox: unclear, some work has been done
12 / 41
Outline

Trust

Transport Layer Security

Packet filter

Netfilter

13 / 41
Transport Layer Security

application
I confidentiality and data integrity
(not signed artifacts)
TLS
I peer authentication
I client-server
TCP
I transparent for applications e. g.,
IMAPS, HTTPS
I 1996: SSL 3.0, 2008: TLS 1.2 IP
I TLS 1.3 spec finished in March
2018 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
I DH key agreement with server authentication
I 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:
I authenticate handshake
I derive session keys, IVs

18 / 41
Conceptual view
random random
random
s)
random, cert, DH, signature(DH, rnd DH
verify certificate
verify signature
DH
compute DH
compute auth DH, authenticator
compute DH
verify auth
compute auth
authenticator
verify auth

master _secret ≈ PRF (DH_result, random_values)

authenticator ≈ PRF (master _secret, Hash(handshake_msgs))
19 / 41
TLS handshake (PFS with server authentication)

ClientHello

ServerHelloDone
ServerHello Certificate ServerKeyExchange

ClientKeyExchange ChangeCipherSpec Finished

ChangeCipherSpec Finished

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:
I authenticate handshake
I derive session keys
20 / 41
Observations

I old, not cleanly designed (MtE, CBC. . . )

I rather well studied
I libraries hard to use
I tons of options, e.g. session resumption
I confidentiality and integrity optional
I “Cloudflare problem”
I good for centralized authority control
I bad for decentralized caching
I we don’t know how to retire broken old versions

21 / 41
Problems

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

I hold back phase out of broken version
I hold back modernization (TLS 1.3)
I warnings ineffective and useless for humans
I plus all the CA problems

22 / 41
23 / 41
Recommendations

I don’t go home-brewed
I keep your library up to date. . .
I offer v1.2
I HSTS
I switch off compression
I ECDHE for fast forward security
I only AES cipher suites
I prefer AES-GCM
Only TLS 1.2 with GCM (and 1.3) 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:
I link layer
I MAC filter
I 802.1X authentication
I network/transport layer
I packet filter
I application layer
I URL filtering HTTP proxy

26 / 41
Basic strategies

I default deny: whitelisting

I more secure
I default permit: blacklisting
I more convenient

27 / 41
Simple example

I packet traverses rules

I traffic from 2001:db8::/32 is only allowed on HTTPS
I permit other incoming
I permit outgoing

28 / 41
Simple example

I packet traverses rules

I traffic from 2001:db8::/32 is only allowed on HTTPS
I permit other incoming
I 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

I rules are matched sequentially

I make IPv4 and IPv6 consistent

28 / 41
Flow

5-tuple
I src IP
I dst IP
I layer 4 protocol
I src port
I dst port

29 / 41
Packet filtering

1. stateless
I look only at packets
I fast, little memory access
I use for IP filters or to handle many addresses

30 / 41
Packet filtering

1. stateless
I look only at packets
I fast, little memory access
I use for IP filters or to handle many addresses
2. stateful
I packets may generate state
I look at flows
I smarter, e. g.:
I only allow incoming UDP packets when matching previous
outgoing packet to corresponding 5-tuple
I match ICMP port unreachable with the corresponding TCP
stream
I 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

DMZ
Internet ext int local network

bastion host

32 / 41
Must have

I use a packet filter to implement ingress filtering (BCP 38)

I remember DoS using DNS spoofing/amplification!

33 / 41
Limitations

Packet filters do not protect against:

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

34 / 41
Outline

Trust

Transport Layer Security

Packet filter

Netfilter

35 / 41
nftables

I packet traverses rules

I rule: match header and take action
I modules provide wide variety of matching options
I actions: go to other chain, drop, accept, reject, SNAT. . .
I rules added to empty predefined and custom chains
I 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:
I optimize for number of matches of most packets
I no rejects redundant with policy
I ESTABLISHED only needed once

40 / 41
Recommended sources

I Engelhardt: Towards the perfect ruleset

I Engelhardt: packet flow diagramme
I man 8 nftables
I wiki.nftables.org

41 / 41