DNSSEC Applying cryptography to the Domain Name System

Transcription

1 DNSSEC Applying cryptography to the Domain Name System Gijs van den Broek Graduate Intern at SURFnet

2 Overview First half: Introduction to DNS Attacks on DNS Second half: DNSSEC Questions: please ask! DNSSEC 2

3 Resolving IP Address (1/2).nl, then surfnet.nl Client At your ISP DNS resolver Root & TLD servers ns1.surfnet.nl; At SURFnet Authoritative server DNSSEC 3

4 Resolving IP Address (2/2) A. Resolving.nl B. Resolving surfnet.nl C. Resolving DNSSEC 4

5 Record Types A AAAA CNAME NS MX TXT SRV PTR SOA IPv4 address IPv6 address Alias record Name server host Mail delivery host Text record Service directive Pointer (reverse lookup) Start of Authority (zone info) DNSSEC 5

6 Example DNS Response IP headers & stuff src IP = (ns1.surfnet.nl) dst IP = ( UDP src port = 53 dst port = 4321 headers & stuff DNS QID = 1201 some flags Question# = 1 Answer# = 1 Authority# = 3 Add. record# = 3 Q? A record for Ans. = Aut. surfnet.nl = ns1.surfnet.nl Aut. surfnet.nl = ns2.surfnet.nl Aut. surfnet.nl = ns3.surfnet.nl Add. ns1.surfnet.nl = Add. ns2.surfnet.nl = Add. ns3.surfnet.nl = DNSSEC 6

7 DNS: insecurity by design? DNS was designed in the early Internet era Everybody more or less knew everybody else And everybody trusted everybody else Bottom line: Security was not a design criterion DNSSEC 7

8 Threats to DNS Availability If DNS is not available, the internet is broken (users think) A typical DNS resolver services end users Some authoritative servers host over 8 million zones Exploitation On an exploited server availability and integrity are broken Plus the attacker can gain access to all other software on the same server/client DNSSEC 8

9 Why attack DNS? DNS is everywhere: In your phone, in your laptop, in your PC But also in your car, in an ATM, in your elevator, It is very hard to protect DNS against attacks (currently) It is very easy to attack a lot of users DNSSEC 9

10 Let s start simple A? Referral to auth. DNS resolver Root & TLD servers A? A: Authoritative server Client Man-in-the-Middle Attacks possible DNSSEC 10

11 Beyond M-i-t-M: spoofing IP headers & stuff src IP = (ns1.surfnet.nl) dst IP = ( UDP src port = 53 dst port = 4321 headers & stuff DNS QID = 1201 some flags Question# = 1 Answer# = 1 Authority# = 3 Add. record# = 3 Q? A record for Ans. = Aut. surfnet.nl = ns1.surfnet.nl Aut. surfnet.nl = ns2.surfnet.nl Aut. surfnet.nl = ns3.surfnet.nl Add. ns1.surfnet.nl = Add. ns2.surfnet.nl = Add. ns3.surfnet.nl =

12 Cache poisoning A? Referral to auth. DNS resolver Root & TLD servers A? A: Authoritative server Client Use rogue client for targeting a specific name Rogue responder

13 Is it really a threat? Yes because: Source port randomisation was not common practice before the Kaminsky attack of 2008 Query ID randomisation wasn t common practice either No because: You can only attempt to poison a name a few times per day (why?) DNSSEC 13

14 Cache poisoning++ Dan Kaminsky published an attack in 2008 No need to wait for a resolver to take initiative, no need to wait for TTL expiry DNSSEC 14

15 Preparing for Kaminsky IP headers & stuff src IP = (ns1.surfnet.nl) dst IP = ( UDP src port = 53 dst port = 4321 headers & stuff DNS QID = 1201 some flags Question# = 1 Answer# = 1 Authority# = 3 Add. record# = 3 Q? A record for Ans. = Aut. surfnet.nl = ns1.surfnet.nl Aut. surfnet.nl = ns2.surfnet.nl Aut. surfnet.nl = ns3.surfnet.nl Add. ns1.surfnet.nl = Add. ns2.surfnet.nl = Add. ns3.surfnet.nl =

16 Attack in action QID= piggybank.dom A??? DNS resolver go to piggybank auth. Root & TLD servers piggybank.dom A??? piggybank.dom A??? QID=1235 A: QID=1234 QID=1233 QID=1235 Success! Rogue responder Additional: NS piggybank.dom Authoritative server Rogue authoritative

17 Spoofed additional section ;; QUESTION SECTION: ;abcde.piggybank.dom. IN A ;; ANSWER SECTION: abcde.piggybank.dom. 582 IN A ;; AUTHORITY SECTION: piggybank.dom IN NS ns1.piggybank.dom. piggybank.dom IN NS ns2.piggybank.dom. ;; ADDITIONAL SECTION: ns1.piggybank.dom IN A ns2.piggybank.dom IN A DNSSEC

18 Attack in action DNS resolver Root & TLD servers A? A? A: A: Authoritative server Vulnerable end user Rogue authoritative

19 DNSSEC So it s even worse!

20 Impact on threat level (1/2) Kaminsky is happening (we think, but is damn hard to detect): Wide-scale patching has been rolled out But research shows: Poisoning unpatched BIND: ±3 seconds Poisoning patched BIND: 1-11 hours (source: NIC.cz) 20

21 Impact on threat level (2/2) Kaminsky is happening on our network! 21

22 Summary Zone file dynamic updates Stub resolver queries Caching resolver queries queries Master zone transfers Slaves Man in the middle Cache poisoning Data modification Master spoofing Spoofed updates Corrupt data DNSSEC 22

23 Part 2: The solution DNSSEC! DNSSEC 23

24 What is DNSSEC? (1/2) DNSSEC is an extension to DNS specified by the IETF in a number of RFCs Actively developed since 1997 According to RFC 4033: The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. DNSSEC

25 What is DNSSEC? (2/2) DNSSEC makes it possible to check the authenticity of DNS records This is accomplished using public key cryptography What DNSSEC does not do: Provide confidentiality Protect against threats to the name server (DDoS, etc.) Guarantee correctness of the DNS data (only authenticity) Protect against phishing, typosquatting, etc. DNSSEC

26 Public Key Cryptography (1/2) Symmetrical encryption (e.g., AES): using the same key to encrypt and decrypt Public Key Crypto: Two keys, forming a key-pair Encryptions with the private key can only be decrypted with the public key and vice versa DNSSEC 26

27 Public Key Cryptography (2/2) Signing: Message = A-record = Hash(Message) => Digest 2. Encrypt Digest with private key => Encrypted Digest Validation of Signature: 1. Decrypt Encrypted Digest with public key => Digest 2. Hash(Message) => Same digest means -> validated signature! DNSSEC 27

28 Cryptography in DNSSEC (1/2) Public key cryptography RSA, DSA, (Elliptic Curve) Private Key is used to sign records well protected, hidden from outsiders Public Key is used to verify must be widely published DNSSEC

29 Cryptography in DNSSEC (2/2) Signing takes place at zone level Two types of keys per zone: Key Signing Key (KSK) Large key size ( 2048 bits RSA) Long validity ( 1 year) Used to sign Zone Signing Key Zone Signing Key (ZSK) Smaller key size ( 1024 bits RSA) (less expensive in time and data) Short validity (± 1 month) Used to sign the zone (resource records) DNSSEC

30 Comparing Zones Traditional Zone DNSSEC Signed Zone surfnet.nl SOA surfnet.nl NS surfnet.nl NS surfnet.nl NS surfnet.nl MX ns1 hostmaster ns1.surfnet.nl ns2.surfnet.nl ns3.surfnet.nl mx-a.surfnet.nl surfnet.nl SOA surfnet.nl RRSIG surfnet.nl NS surfnet.nl NS surfnet.nl NS surfnet.nl RRSIG surfnet.nl MX surfnet.nl RRSIG surfnet.nl DNSKEY KSK ns1 hostmaster SOA signature ns1.surfnet.nl ns2.surfnet.nl ns3.surfnet.nl NS signature mx-a.surfnet.nl MX signature surfnet.nl DNSKEY ZSK surfnet.nl RRSIG DNSKEY signature surfnet.nl NSEC NSEC data DNSSEC 30

31 DNSSEC Record Types RRSIG: signature for similar RRs (e.g., one signature for all NS records in a zone) DS: Delegation Signer (holds a hash of a child s zone public key, and is signed with the zone private key of the parent) DNSKEY: Public key for a zone (one of the keys used for this zone, possibly more than one per zone) NSEC/NSEC3: prove non-existence of labels, to avoid zone walking DNSSEC 31

32 NSEC - prove of non-existence (1/2) Request charlie gives: beta.example.net. NSEC delta.example.net. A RRSIG NSEC Label charlie does not exist, but we now know delta exists and that beta only has an A RRSIG and NSEC record DNSSEC 32

33 NSEC3 - prove of non-existence (2/2) Request charlie gives: Hash of charlie is a10c Salt 810c.example.net. NSEC A17 c73a A RRSIG Hashes between 810c and c73a do not exist -> Label charlie does not exist and we do not know the next label DNSSEC 33

34 Signatures (RRSIG) in DNSSEC Signatures are mostly signed SHA-hashes in DNSSEC Signatures have a limited validity period Period defined in Zulu time, not time-to-live (TTL) like in resource records Expired signatures may result in unreachable zones Hence, accurate system time at signer and resolver are required DNSSEC 34

35 Validating a Signature Query IN A IN RRSIG A10 623C49E8D53CF7E6046E F signature! - Validate this signature against the nist.gov zone public zone signing key - It s the resolver s job to do this! - How do I find and trust the nist.gov key? DNSSEC

36 Trust chain for (1/3). (root) KSK ZSK Signed w/ nl DS record Signed w/ DNSSEC 36

37 Trust chain for (2/3).nl (NL-zone) KSK ZSK Signed w/ surfnet.nl DS record Signed w/ DNSSEC 37

38 Trust chain for (3/3) surfnet.nl KSK ZSK Signed w/ A- and AAAA-record for Signed w/ DNSSEC 38

39 Why another DNSKEY? DNSSEC 39

40 Key management (1/2) Key Signing Key and Zone Signing Key have a limited validity; this requires regular roll-overs: Rollover #1 Key #1 Rollover #2 Key #2 Rollover #3 Key #3 Key #4 Key is used for signing Key has been announced but is not yet valid Key is still valid but no longer used for signing DNSSEC

41 Key management (2/2) Keys need to be stored securely off-line, smart card, Hardware Security Module (HSM),... Administrators need to plan for emergency key roll-over The parent has to be notified of new keys for a domain (this needs to be automated) DNSSEC

42 Criticism on DNSSEC The Top-10 Reasons Why DNSSEC Is the String Theory of the Internet -10. Even Adds many the new critics dimensions agree to an already that complex DNSSEC problem is the only 9. Hogs all the research funds available solution at the moment 8. Has many careers riding on it 7. Widely hailed by expert and layman alike as the next big thing -6. That Responds doesn t to shortcomings mean by reinventing that DNSSEC itself and doubling is perfect its complexity far from 5. On its third iteration to succes it 4. Attracts the brightest minds of the industry 3. Cult-like following among believers -2. DNSSEC Always on the verge is hard of solving (especially a real world problem compared to ordinary DNS, which is very forgiving) 1. Will be ready in 6 months! Bert Hubert (PowerDNS) - The (un)availability of easy-to-use tools is hindering deployment of signed zones DNSSEC

43 Current situation DNSSEC implemented in the most prevalent name servers: BIND, Unbound, NSD, PowerDNS, Microsoft DNS Server Internet root is signed ~30% of all generic and country-code top-level domains signed 0,01%.com-domains 0,019%.net-domains 0,95%.edu-domains Improving Response Deliverability in DNSSEC 43

44 What have we done? SURFnet s resolvers perform DNSSEC validation: DNSSEC

45 Other use of DNSSEC DNS-based Authentication of Named Entities (DANE) Deliver TLS certificate that currently uses PKI X.509 Benefits: TLS key materials can now be delivered via DNS, a lighter protocol than HTTPS key exchange The material can be cached in recursive DNS servers The need for a Certificate Authority (CA) is obsolete DNSSEC 45

46 Summary What does DNSSEC do for you? You can prove the authenticity of the records in your domain You can check the authenticity of the records of others You effectively protect yourself against attacks like Kaminsky s DNSSEC

47 W dnssec.surfnet.nl Creative Commons Attribution license: