Secure Network Protocols
Nadhem J. AlFardan
Thesis submitted to
Royal Holloway, University of London for the degree of
Doctor of Philosophy
I, Nadhem J. AlFardan, hereby declare that this thesis and the work presented in it is entirely my own. Where I have consulted the work of others, this is always clearly stated.
Signed: . . . . (Nadhem J. AlFardan)
all the difference.” Robert Frost
This doctoral thesis is lovingly dedicated to: My parents, Jawad and Alawia, may their souls rest in peace. To my sisters, Zoya and Zahra. To my brothers, Mahmoud, Monther and Hussain. There is no doubt in my mind that without their prayers,
First and foremost, I would like to acknowledge my PhD supervisor, Prof. Kenny Paterson, who made this journey worth taking. Throughout my research period, he provided me with encouragement, sound advice, good teaching, and lots of good ideas. His enthusiasm and engagement in my area of research kept me motivated in every stage of my PhD journey. This thesis would not have been possible without his help, support and patience. Thank you.
I wish to thank my extended family, especially Firas, Ghaida and Hassan, who have been supporting me and believing in me all the way.
I would like to thank my friends, especially Salman and Ahmad, who have been the best of friends to me over the years.
Special thanks to David McGrew, David Williamson, Eric Vyncke and my other colleagues at Cisco, for their support and encouragement throughout this experience.
I would like to acknowledge the ISG IT support staff, especially Jon Hart, for providing all what I needed to carry out my laboratory work.
Network Protocols are critical to the operation of the Internet and hence the se-curity of these protocols is paramount. Our work covers the sese-curity of three widely deployed protocols: Domain Name System (DNS), Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Our work shows that the design or implementation of some variants of these protocols are vulnerable to attacks that com-promise their fundamental security features. In all of the cases we include experimental results demonstrating the feasibility of our attacks in realistic network environments. We propose a number of countermeasures for the attacks, some of which have already been implemented in practice.
We start by describing the structure of DNS and present a number of existing DNS security protocols. We then focus on DepenDNS, a security protocol that is intended to protect DNS clients against cache poisoning attacks. We demonstrate that DepenDNS suffers from operational deficiencies, and is vulnerable to cache poisoning and denial of service attacks.
We then give an overview of Transport Layer Security (TLS) and Datagram Trans-port Layer Security (DTLS), and draw the similarities and differences between the two protocols. We describe the padding oracle concept and present a number of recent attacks against TLS.
We then present new techniques to conduct a full plaintext recovery attack against the OpenSSL implementation of DTLS, and a partial plaintext recovery attack against the GnuTLS implementation of TLS and DTLS. Our attacks exploit timing-based side channels that would not have been exploitable without our new techniques. We also describe countermeasures for the attacks.
We then present new distinguishing and plaintext recovery attacks against all ver-sions of TLS and DTLS and in almost all implementations of the two protocols. Our attacks are based on timing-based side channels and exploit TLS and DTLS design and implementation decisions. We describe how to conduct a full plaintext recovery attack against implementations that follow the standard, and a partial plaintext recovery at-tack against implementations that do not. We discuss a number of countermeasures for the attacks, and describe their practicality and effectiveness.
We conclude the thesis by discussing the wider implications of our work on the design and implementation of secure network protocols.
1 Introduction 19
1.1 Context . . . 19
1.2 Contributions . . . 20
1.3 Publications . . . 20
1.4 Thesis Outline . . . 21
2 The Domain Name System 23 2.1 Introduction. . . 23
2.2 Introduction to the Domain Name System . . . 23
2.2.1 DNS and Content Delivery Networks . . . 26
2.3 Security of DNS . . . 28
2.3.1 DNS Cache Poisoning . . . 28
2.3.2 DNS Cache Poisoning and the Birthday Paradox . . . 32
2.3.3 Kaminsky Attack Against DNS . . . 34
2.4 Securing DNS Against Cache Poisoning Attacks. . . 35
2.4.1 Domain Name Cross Referencing . . . 35
2.4.2 0x20-Bit Encoding . . . 36 2.4.3 WSEC DNS . . . 39 2.4.4 DNSSEC . . . 40 2.5 DepenDNS . . . 42 2.5.1 Introduction to DepenDNS . . . 42 2.5.2 DepenDNS Algorithm π . . . 45 2.5.3 Protocol Review . . . 47 2.5.4 Attacking DepenDNS . . . 49 2.5.5 Experimental Results . . . 55 2.6 Chapter Conclusion . . . 72
3 TLS and DTLS 73
3.1 Introduction. . . 73
3.2 The TCP/IP Protocol Suite . . . 73
3.2.1 The Internet Protocol . . . 74
3.2.2 The Transmission Control Protocol . . . 75
3.2.3 The User Datagram Protocol . . . 77
3.2.4 Implementing the TCP/IP Protocol Suite . . . 78
3.3 Cryptographic Primitives . . . 78
3.3.1 Hash Functions . . . 79
3.3.2 Message Authentication Codes . . . 79
3.4 Introduction to Transport Layer Security . . . 80
3.4.1 Pseudo Random Functions in TLS . . . 82
3.4.2 TLS Key Derivation . . . 82
3.4.3 The TLS Handshake Protocol . . . 83
3.4.4 TLS Session Renegotiation . . . 86
3.4.5 TLS Session Resumption . . . 86
3.4.6 The TLS Record Protocol . . . 87
3.4.7 Modes of Operation . . . 88
3.4.8 The TLS Alert Protocol . . . 89
3.5 Introduction to Datagram Transport Layer Security . . . 90
3.6 Heartbeat Extension for (D)TLS . . . 93
3.7 Implementations of (D)TLS . . . 94
3.8 Side Channel Attacks . . . 94
3.8.1 Timing Side Channel Attacks . . . 95
3.9 Padding Oracles . . . 95
3.9.1 Using a Padding Oracle to Attack TLS . . . 98
3.9.2 Canvelet al. Timing Attack Against TLS . . . 99
3.10 The BEAST Attack . . . 101
3.10.1 Countermeasures . . . 103
3.11 Other Attacks Against TLS . . . 104
3.11.1 Distinguishing Attack Against TLS with Short MACs . . . 104
3.11.2 The CRIME Attack . . . 105
3.11.3 The BREACH Attack . . . 105
3.11.4 RC4 Attack . . . 106
3.12 Attacks Against DTLS . . . 106
4 Attacks Against DTLS 108
4.1 Introduction. . . 108
4.2 Building a Padding Oracle for OpenSSL . . . 110
4.2.1 Using the Heartbeat Extension . . . 110
4.2.2 Assumptions on the Adversary . . . 111
4.2.3 Building a Padding Oracle for the OpenSSL Implementation of DTLS . . . 111
4.3 Practical Considerations . . . 114
4.3.1 Timing and OpenSSL Cryptographic Operations . . . 114
4.3.2 Timing and Packet Processing . . . 115
4.3.3 System Profiling . . . 117
4.3.4 An Attack without System Profiling . . . 117
4.3.5 Measuring Success Under Budgetary Constraints . . . 118
4.3.6 Attacks with Anti-Replay Enabled . . . 119
4.4 Implementation and Results for OpenSSL . . . 120
4.4.1 Implementation . . . 120
4.4.2 Results . . . 120
4.5 Attacking the GnuTLS Implementation of DTLS . . . 122
4.6 Disclosure . . . 127 4.7 Chapter Conclusion . . . 127 5 Lucky Thirteen 140 5.1 Introduction. . . 140 5.2 Details of HMAC . . . 144 5.3 A Distinguishing Attack . . . 145 5.3.1 Practical Considerations . . . 146
5.4 Plaintext Recovery Attacks . . . 147
5.4.1 General Approach . . . 147
5.4.2 Full Plaintext Recovery . . . 148
5.4.3 Plaintext Recovery for Other MAC Algorithms . . . 152
5.4.4 Applying the Attacks to DTLS . . . 153
5.5 Experimental Results for OpenSSL . . . 153
5.5.1 Experimental Setup . . . 153
5.5.2 Statistical Analysis . . . 154
5.5.3 Distinguishing Attack for OpenSSL TLS . . . 154
5.5.4 Plaintext Recovery Attacks for OpenSSL TLS. . . 155
5.5.6 More Challenging Network Environments . . . 159 5.6 Other Implementations of TLS . . . 160 5.6.1 GnuTLS . . . 160 5.6.2 Further Implementations . . . 168 5.7 Countermeasures . . . 172 5.7.1 Disclosure . . . 176 5.8 Chapter Conclusion . . . 177 6 Conclusion 181 6.1 Themes . . . 181
6.2 Areas of Further Research . . . 183
2.1 Resource Record structure. The structure shows the fields in a RR that are explained in Section 2.2. . . 24 2.2 DNS look-up showing two CNAME RRs being served for the host name
“www.gov.uk”. . . 25 2.3 The Domain Name System structure. The figure shows the DNS root
domain (“.”) in the top of the hierarchy. The figure also show two TLDs, “.com” and “.uk” and sample levels that exist under the “.uk” TLD. . . 26 2.4 Birthday attack success probability with variable doutstanding queries
and when relying on a random TXID only. The figure shows that the attacker can achieve a success probability of 0.5 with only 300 outstand-ing queries and matchoutstand-ing spoofed responses, and 0.99 with only 776 outstanding queries and matching spoofed replies . . . 33 2.5 Birthday attack success probability with only one outstanding query and
when relying on a random TXID only. The reader would compare this to Figure 2.4, which shows the birthday attack success probability with variabledoutstanding queries and when relying on a random TXID only 34 2.6 TXTRRs added for WSEC DNS. . . 39 2.7 CNAMERRs added for WSEC DNS. . . 39 2.8 Value ofN over time for “www.live.com”. The reader would notice that
the shows that the average value of N for “www.live.com” is 13.5. As described in Section 2.5.4, the condition thatN ≥9 will guarantee that
IPbogus achieves the passing grade, allowing DNS cache poisoning to
succeed. . . 51 2.9 Number of IP addresses accepted over time for “www.live.com”. With an
average value ofN for “www.live.com” is 3.5, means that the conditions for the DoS attack to succeed are met. The figure shows that no IP addresses for “www.live.com” were accepted during the vast majority of runs. . . 53
2.10 Results of the attack against “www.youtube.com”. After injecting a number of valid IP addresses as per the technique described in this section we found that algorithm π starts rejecting all the IP addresses received from the 20 resolvers. The two figures show the number of accepted and rejected IP addresses during the six runs.. . . 58 2.11 Sample HTML code that employs JavaScript and could be downloaded
and executed by the client’s browser, resulting potentially in a DNS amplification attack, when DepenDNS is deployed. . . 59 2.12 Results for “www.live.com” starting without existing history information. 60 2.13 Results for “maps.live.com” starting without existing history information. 61 2.14 Results for “www.youtube.com” starting without existing history
infor-mation. . . 62 2.15 Results for “www.vmware.com” starting without existing history
infor-mation. . . 63 2.16 Results for “www.hsbc.com” starting without existing history information. 64 2.17 Results for “www.live.com” with existing history information. . . 67 2.18 Results for “maps.live.com” with existing history information. . . 68 2.19 Results for “www.youtube.com” with existing history information. . . . 69 2.20 Results for “www.vmware.com” with existing history information. . . . 70 2.21 Results for “www.hsbc.com” with existing history information. . . 71 3.1 Structure of the IPv4 header as per RFC 791. The structure shows the
different fields that are available in an IPv4 packet. We descricbe some of these fields in 3.2.1 . . . 74 3.2 Relationships between protocols. The figure shows the construct in
which protocols operate. . . 76 3.3 Structure of the TCP header as per RFC 793. A number of TCP header
fields shown in this figure, such asSequence Number,Acknowledgement Number, Window and Checksum, and described in Section 3.2.2, are re-quired to achieve the TLS reliability feature that upper layer protocols such as TLS rely on. We describe the relationship between TCP and TLS later in this chapter. . . 77 3.4 Structure of the UDP header as per RFC 768.. . . 78
3.5 Sample TLS Handshake Protocol sequence of messages. The figure shows the messages exchanged between the TLS client and the TLS server in the scenario discussed in Section 3.4.3. In this scenario, we assume that RSA is used for key establishment. In this scenario, the pre master secret, which is a 48-byte key, is generated by the client and shared, securely, with the server in the third step in theClientKeyExchange message. The master secret, master secret, that gets associated with a TLS session and is used to generate the required keying material for the TLS connection, is computed frompre master secret. The keying material that is generated will include encryption and MAC keys used by the clinet and the server for a particular TLS connection. . . 84 3.6 CBC-mode decryption. In this figure, C is the concatenation of the
ciphertext blocks Ci (including or excluding the IV depending on the
particular SSL or TLS version), whileP is the decrypted ciphertext and
K is the key used for decryption. . . 90 3.7 Startup of DTLS Handshake Protocol. . . 93 3.8 In this example, where CBC-mode encryption is used,Ct−1[b−1]⊕∆[b−
1] has the same effect ofPt[b−1]⊕∆[b−1]. The other bytes ofPt are
not affected. In CBC-mode encryption, modifying the value of a byte of
Ct−1 by XORing it with ∆ has the effect of modifying Pt in the same
byte by XORing it with the same ∆. . . 97 4.1 Timing of cryptographic operations for DTLS payloads of sizes between
64 and 1456 bytes. With AES-256, the processing time rapidly drops from about 50 µsto about 20 µs when the DTLS payload size reaches 512 bytes. One possible explanation for this behaviour is that a switch to a more efficient AES implementation is made once the payload is sufficiently large. . . 130 4.2 Packet processing time-line – valid padding: ti,0 is the time at which
packet i arrives in the OpenSSL buffer, ti,1 is the time at which the decryption and padding check are completed for packet i, ti,2 is the time at which the MAC check is completed for packet i, ti,3 is the time at which OpenSSL is ready to process the next DTLS packet, packet
i+ 1, and OSt is any additional time spent by the operating system in
relation to the processing of the packet (we assume this to be a constant, independent ofi).. . . 131
4.3 Packet processing time-line – invalid padding. In the case of a packet with invalid padding, the MAC verification is not performed and hence we have ti,2=ti,1. . . 131 4.4 Time-line for a train with n= 2 (not to scale). . . 131 4.5 Time-line for packet train with valid padding and packet buffering. . . . 132 4.6 Time-line for packet train with invalid padding and packet buffering. . . 132 4.7 Value ofδ, the difference in RTTs for valid and invalid padding, against
artificial delay. The figure confirms that injecting artificial delays in between packets from the train as they leave the adversary’s machine, results in the value ofδsteadily decreasing and eventually reaching zero as the size of the artificial delay increases. . . 132 4.8 3DES – PDFs for n = 10 and varying l (packet size), with outliers
removed. In this figure we show two PDFs, PDF1 (in red) and PDF2 (in blue), that correspond to having valid and invalid padding in the packets in the trains, respectively. In the case of 3DES, we can easily distinguish between the two PDFs. . . 133 4.9 AES-256 – PDFs for n = 10 and varying l (packet size), with outliers
removed. In this figure we show two PDFs, PDF1 (in red) and PDF2 (in blue), that correspond to having valid and invalid padding in the packets in the trains, respectively. In the case of AES-256, It is harder, but possible, to distinguish between the two PDFs, when compared to 3DES shown in Figure 4.8.. . . 134 4.10 3DES – PDFs for l= 1024 (packet size) and varying n(train size). . . . 135 4.11 AES-256 – PDFs for l= 1024 (packet size) and varyingn(train size). . 136 4.12 AES-256 – PDFs for l= 256 (packet size) and varyingn(train size). . . 137 4.13 Snapshot from GnuTLS code (gnutls cipher.c), version 3.0.0.. . . 138 4.14 PDFs for AES-256 with HMAC-SHA256, l = 176 (packet size), n = 5
(train size), based on 1000 trials, with outliers removed. . . 139 5.1 D(TLS) encryption process. The figure shows how CBC-mode
encryp-tion is applied in TLS and which we refer to as MEE-TLS-CBC in this chapter. . . 141 5.2 Distribution of timing values (outliers removed) for distinguishing attack
on OpenSSL TLS, showing faster processing time in the case of M0 (in
5.3 OpenSSL TLS median server timings (in hardware cycles) whenP∗[14] = 0x01 and P∗[15] = 0xFF. As expected, ∆[15] = 0xFE leads to faster processing time.. . . 157 5.4 OpenSSL TLS median network timings in terms of hardware cycles when
P∗[14] =0x01 and P∗[15] =0xFF. As expected ∆[15] =0xFE leads to faster processing time. . . 158 5.5 OpenSSL TLS partial plaintext recovery: percentile-based success
prob-abilities for recovering P∗[15] assumingP∗[14] is known. . . 159 5.6 OpenSSL DTLS partial plaintext recovery: percentile-based success
prob-abilities for recovering P∗[15] assumingP∗[14] is known,n= 10. . . 160 5.7 OpenSSL DTLS 2-byte recovery: percentile-based success probabilities
for recovering P∗[14] andP∗[15], n= 10.. . . 161 5.8 OpenSSL DTLS 2-byte recovery: percentile-based success probabilities
for recovering P∗[14] andP∗[15], n= 1. . . 162 5.9 GnuTLS TLS median server timings (in hardware cycles) for varying
values of ∆[15] and P∗[15] =0x00. . . 166 5.10 GnuTLS TLS median network timings (in hardware cycles) for varying
values of ∆[15] and P∗[15] =0x00. . . 167 5.11 Zoomed view of GnuTLS TLS network timings. . . 168 5.12 Zoomed view of GnuTLS TLS network timings for each of the 4 blocks. 179 5.13 Distribution of timing values (outliers removed) for distinguishing attack
2.1 DNS root servers. . . 27 2.2 Percentage of runs withN ≥9. . . 52 2.3 Summary results for all host names without existing history information. 56 2.4 Summary results for all host names with existing history information. . 65 4.1 Success probabilities per byte for AES, for various attack parameters. . 123 4.2 Success probabilities per byte for 3DES, for various attack parameters. . 124 4.3 Success probabilities per byte for AES-256, for l = 192, based on 1000
trials. . . 125 5.1 OpenSSL TLS distinguishing attack success probabilities. . . 156 5.2 GnuTLS success probabilities for recovering the four MSBs ofP∗[15]. . 169
1 DoX Consistency Check Algorithm. . . 37 2 Decrypting a block using a padding oracle,PO, with block-mode
encryp-tion. . . 98 3 Padding Oracle for OpenSSL implementation of DTLS . . . 113
We list here notations and symbols that will be consistently used throughout this thesis. All other symbols or notations will be introduced when they are first used.
π The algorithm used by DepenDNS to accept or reject an IP address.
Gi The grade of an IP address calculated by the DepenDNS algorithm.
P A Plaintext message.
R A Plaintext record.
T The MAC tag.
b The block-size of the selected block cipher in bytes.
Ci A ciphertext blocki. Pi A plaintext blocki.
B[i] Byte at positioniin block B.
D A decryption algorithm of a block cipher.
E An encryption algorithm of a block cipher.
Kd The block cipher decryption key. Ke The block cipher encryption key. HDR The (D)TLS header.
We list here abbreviations that will be used throughout this thesis. All other abbrevi-ations will be introduced when they are first used.
AE Authenticated Encryption
AES Advanced Encryption Standard ANS Authoritative Name Server
CBC Cipher Block Chaining
CDN Content Delivery Network DES Data Encryption Standard
DNS Domain Name System
DNSSEC DNS Security Extensions
DOS Denial of Service
DTLS Datagram Transport Layer Security
IP Internet Protocol
MITM Man-In-The-Middle
RDNS Recursive Domain Name System
RFC Request for Comment
RR Resource Record
RTP Real Time Protocol
SSL Secure Socket Layer
TCP Transport Control Protocol
TLD Top-Level Domains
TLS Transport Layer Security TXID Transaction Identifier
Introduction
1.1
Context
The evolution of secure network protocols has been largely driven by the discovery and the successful exploitation of weaknesses in either the design or the implementation of these protocols. The Domain Name System (DNS) and Transport Layer Security (TLS) provide good examples that demonstrate thisbrokenreactive model of evolution. Maintaining the security of DNS has been a continues challenge with high-profile and high-impact attacks frequently emerging (for example, Kaminsky’s cache poisoning attack against DNS), which are usually followed by the development ofad hoc security protocols that try to protect DNS from these attacks. In most cases, attacks against DNS have exploited trivial, and on occasion known, weaknesses. Most of these attacks would have been prevented if the basic DNS security mechanisms had been deployed.
TLS, on the other hand, is by far the most widely deployed secure network protocol today, and which best show-cases the failure of this ad hoc approach of designing and implementing secure network protocols. Attacks of different severity and practicality levels have been published against TLS (and its predecessor, Secure Socket Layer), triggering ad hoc and non-coordinated responses from the Internet Engineering Task Force (IETF) who maintain the protocol specification, and the TLS open and closed source code development community. Alarmingly, the number of attacks against TLS has recently been on the rise including, for example, BEAST, CRIME, Lucky 13 (our attack discussed in Chapter 5) and BREACH.
Our work takes advantage of previously unknown weaknesses introduced by this ad hoc approach to develop attacks that exploit the above mentioned protocols using basic, but novel, techniques.
1.2
Contributions
The work presented in this thesis reflects our analysis of three secure network protocols: DepenDNS (a DNS security protocol), TLS and Datagram TLS (DTLS). We describe a number of weaknesses in the design and implementation of these protocols that could be exploited by an adversary to conduct various, and in many cases severe, attacks that undermine their fundamental security goals. The impact and applicability of our work goes beyond academia and extends to cover the larger community of secure network protocol researchers, designers and software implementers. Our work demonstrates again the (in)security of the MAC-then-Encode-then-Encrypt (MEE) construction for TLS and DTLS, using new techniques to exploit design and implementation decisions made for the two protocols to build attacks. We describe how to use these new tech-niques to recover TLS and DTLS-protected plaintext. In addition, we demonstrate that a number of DNS security protocol implementations are impractical and, in the case of DepenDNS, are ineffective.
We took the route of: identifying and verifying potential design or implementation weaknesses, practically exploiting these weaknesses, and then responsibly disclosing our research results. We responsibly disclosed our findings, working closely with the (D)TLS standards’ design and development community to address the newly discovered weaknesses; a large number of open source software developers and vendors had to modify their code in response to our attacks. During our research, we collaborated with the authors of the IETF (D)TLS standards, various vendors such as Google and Microsoft, and open source software developers maintaining cryptographic libraries such as OpenSSL and GnuTLS.
Our work promotes further the use of secure TLS modes of operation such as authen-ticated encryption (AE) and the proper implementation of secure network protocols, while considering clarity, effectiveness, practicality and ease of deployment.
Secure network protocols are implemented as part of a system. The interaction between the secure network protocols and the other components of the system, espe-cially their upper and lower-layers, plays a critical role in defining the system’s overall security. We demonstrate this in the different chapters of this thesis. For example, we demonstrate how to use application layer messages to construct a new realisation of Vaudenay’s padding oracle [102] in the context of DTLS in Chapter 4.
1.3
Publications
An Analysis of DepenDNS [7]: Published in the 13th Information Security Con-ference (ISC), and forming the basis of Chapter2.
Plaintext-Recovery Attacks Against Datagram TLS [5]: Published in the 19th
Network and Distributed System Security (NDSS) Symposium, where we received one of the two distinguished paper awards1. The work in [5] forms the basis of Chapter 4.
Lucky Thirteen: Breaking the TLS and DTLS Record Protocols [6]:
Pub-lished in the 34th IEEE Security and Privacy (IEEE S&P) Symposium, and forming the basis of Chapter5.
1.4
Thesis Outline
In Chapter2, we give an introduction to DNS, the services it provides and the standard security mechanisms available to protect DNS from denial of service and cache poisoning attacks. We then describe a number of security protocols that have been proposed to further secure DNS and give an overview of their current deployment status. We analyse a particular protocol, DepenDNS, in detail and demonstrate that the protocol is vulnerable to a number of attacks despite the protocol designers’ claims. We also describe a number of issues that make DepenDNS impractical to deploy. We conclude the chapter by summarising our findings and giving our perspective on the ongoing efforts to secure DNS.
In Chapter 3, we provide the necessary background information and prerequisite material that are needed to establish an understanding of the TLS and DTLS pro-tocols. We provide background information about the TCP/IP protocol suite and describe three fundamental networking protocols: IP, TCP and UDP. We then in-troduce Transport Layer Security (TLS), describe how the protocol is structured and discuss its modes of operation. We also introduce Datagram Transport Layer Security (DTLS) and describe the differences between TLS and DTLS. We then present in detail the padding oracle concept and describe how an attack can be theoretically mounted against TLS using the oracle. Finally, we present a number of recent attacks against the two protocols, serving as a forerunner to our attacks on DTLS and TLS, which we present in Chapters4 and5.
In Chapter4, we present our attacks against the OpenSSL implementation of DTLS with the MAC-then-Encode-then-Encrypt construction. We report our experimental results demonstrating efficient and reliable recovery of full DTLS plaintexts in the OpenSSL case. We then discusses how similar attacks can recover partial plaintexts in
the GnuTLS implementation of TLS and DTLS.
In Chapter5, we present a family of attacks that apply to the MAC-then-Encode-then-Encrypt construction in all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. Our attacks also apply to implementa-tions of SSL 3.0 and TLS 1.0 that incorporate padding oracle attack countermeasures. We first provide further background on the HMAC calculation. We then present the basic distinguishing attack against RFC-compliant implementations of TLS and DTLS, followed by a description of our plaintext recovery attacks in the context of TLS. We ex-plain how to modify them to apply to DTLS. We report on the experimental validation of our attacks for the OpenSSL implementation. We then describe the modifications needed to make our attacks applicable to other implementations. We finally give guid-ance on how to implement the MAC-then-Encode-then-Encrypt construction so as to avoid the attacks.
We conclude the thesis by discussing the wider implications of our work on the design and implementation of secure network protocols.
The Domain Name System
2.1
Introduction
We start the chapter by giving an introduction to the Domain Name System (DNS), the services it provides and the standard security mechanisms available to secure DNS against denial of service and cache poisoning attacks. We then describe a number of security protocols that have been proposed to further secure DNS and give an overview of their current deployment status. We analyse a particular protocol, DepenDNS, in detail and show that the protocol is vulnerable to a number of attacks despite the protocol designers’ claims. We also describe a number of issues that make DepenDNS impractical to deploy. We conclude the chapter by summarising our findings and giving our perspective on the ongoing efforts to secure DNS.
2.2
Introduction to the Domain Name System
The Domain Name System (DNS) [65,66] is a fundamental service that is critical to the proper operation of the Internet. While people are quite good at remembering names, they are not good at remembering IP addresses and hence the need for DNS to help translate names to IP addresses that the Internet can route. The most common service that DNS provides is mapping names to IP addresses (for example, translating “www.example.com” to 192.0.43.10). In addition to mapping names to IP addresses, DNS provides other services such as mapping IP addresses to names (commonly referred to as reverse DNS) and assigning aliases to domain names.
Domain names, IP addresses and other information are maintained on DNS servers in the form of persistent or cached entries referred to as Resource Records (RRs). RRs share the structure described in RFC 1035 [66] and shown in Figure2.1.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2.1: Resource Record structure. The structure shows the fields in a RR that are explained in Section 2.2.
The 2-byte TYPE field shown in Figure 2.1contains the RR type code. Examples of commonly used types include:
• A: The address record used for serving IPv4 host addresses.
• AAAA: The address record for serving IPv6 host addresses.
• CNAME: The canonical name record used for serving an alias of a host name. MultipleCNAMEs can be created such that the same host name that a user queries would resolve to multiple canonical names pointing to different IP addresses, hosted on different servers that could be geographically distributed. Figure2.2 shows an example where twoCNAMEs are created to serve “www.gov.uk”1.
• MX: The mail exchange record used for serving the mail server host name.
• NS: The name server record used to identify the authoritative name server hosting the domain.
• PTR: The pointer record used in reverse DNS look-ups to map an IP address to a host name.
1
www.gov.uk canonical name = www.gov.uk.edgekey.net.
www.gov.uk.edgekey.net canonical name = e6452.b.akamaiedge.net. Name: e6452.b.akamaiedge.net
Address: 23.14.4.23
Figure 2.2: DNS look-up showing two CNAME RRs being served for the host name “www.gov.uk”.
The time-to-live (TTL) value associated with an RR specifies how long, in seconds, should DNS clients or resolvers cache an RR. For example, a TTL value of 3600 indicates that the RR should be cached for only an hour, while a TTL value of 0 indicates that the RR should not be cached. The receiver of an RR can choose to ignore the TTL value it receives and assign a value of its choice.
The other fields that make up an RR include:
• NAME: The domain name that owns the RR.
• CLASS: The CLASS code. The reader may think of this field as the category of the record and is typically set to 1 for an Internet CLASS.
• RDLENGTH: The length of the RDATA field in octets (bytes).
• RDATA: A variable length string that describes the RR. The format of this record varies according to the TYPE and CLASS of the RR. For example, the RDATA field may contain a host name and an IPv4 address in case it was for anARR. DNS can be thought of as a distributed database with a hierarchical structure that is made up of name servers hosting the database and serving RRs. This hierarchy is shown in Figure 2.3. The root domain (“.”) is at the top of the hierarchy and is served presently by thirteen root operators with servers distributed around the world2. The list of the current root servers is shown in Table 2.1. Typically, DNS server packages (for example, ISC BIND3and Microsoft DNS4) would embed this information in their code. This clearly makes changing the IP address of a root server a daunting task. The second level in the hierarchy contains top-level domains (TLDs) that can be classified as generic (gTLD) such as “.com”, or country code (ccTLD) such as “.uk”. Multiple levels exist underneath the TLDs. The domain names located in the lower levels are generally served by their corresponding organisations. For example, the Internet Assigned Numbers Authority (IANA)5 hosts the domain “example.com” [3].
2http://www.root-servers.org 3 http://www.isc.org/downloads/BIND 4 http://technet.microsoft.com/en-US/network/bb629410.asp 5 http://www.iana.org
root(.) .uk .ac .rhul www .isg www . . . mail . . . . . . . . . .com .example www .yahoo www . . . . . .
Figure 2.3: The Domain Name System structure. The figure shows the DNS root domain (“.”) in the top of the hierarchy. The figure also show two TLDs, “.com” and “.uk” and sample levels that exist under the “.uk” TLD.
The operation of DNS is based on queries (requests) and responses (replies). A client initiates the process by sending a DNS resolution query for a host name (for example, “www.example.com”) to its DNS resolver which in return searches its cache entries for the name being requested. If an entry does not exist, resolvers may go through a recursive DNS look-up process that starts from the root servers and continues all the way down to the authoritative name servers (ANSs) responsible for hosting the domain being requested (for example “example.com”). Resolvers capable of performing this recursive DNS look-up are referred to as recursive DNS (RDNS) resolvers; we refer to them in this chapter as resolvers in short. A resolver can also be configured to forward DNS queries to other resolvers (referred to as upstream resolvers) to perform recursive DNS look-ups on its behalf.
Information about domains and their records are contained within DNS zones. An ANS maintains the zone’s database and responds to DNS queries for hosts that exist in the zone. Upon receiving an answer from an ANS, a resolver caches and forwards the answer to the requesting client.
2.2.1 DNS and Content Delivery Networks
Root Server Host Name IP Address Operator a.root-servers.net 198.41.0.4 VeriSign, Inc.
b.root-servers.net 192.228.79.201 University of Southern California (ISI) c.root-servers.net 192.33.4.12 Cogent Communications d.root-servers.net 199.7.91.13 University of Maryland e.root-servers.net 192.203.230.10 NASA (Ames Research Center) f.root-servers.net 192.5.5.241 Internet Systems Consortium, Inc. g.root-servers.net 192.112.36.4 US Department of Defence (NIC) h.root-servers.net 128.63.2.53 US Army (Research Lab)
i.root-servers.net 192.36.148.17 Netnod j.root-servers.net 192.58.128.30 VeriSign, Inc.
k.root-servers.net 193.0.14.129 RIPE NCC
l.root-servers.net 199.7.83.42 ICANN
m.root-servers.net 202.12.27.33 WIDE Project
Table 2.1: DNS root servers.
consists of a set of surrogate servers distributed around the world. The surrogate servers are deployed in multiple locations in order to optimise the end user experience by choosing the nearest surrogate server to the user [101]. For example, web requests generated by a UK-based end user for a website hosted by a CDN will generally be served by a surrogate server that is located in the UK. Most CDN providers deploy DNS redirection to forward the client’s request to the closest server containing the resource being requested. One of the characteristics of DNS records served by CDNs is that they have a low TTL value. Serving a low TTL value causes more frequent DNS look-ups for the same host name, allowing the DNS server hosting the DNS entry to possibly serve different IP addresses, based on factors such as the availability of the surrogate servers or the client’s proximity to the surrogate servers. By way of example, the following shows the TTL value for “134.g.akamai.net”, which is theCNAMERR corresponding to “www.live.com”. It can be seen that the TTL value is set to only 20 seconds.
$ dig www.live.com ...
www.live.com. 1216 IN CNAME search.msn.com.edgesuite.net. search.msn.com.edgesuite.net. 2382 IN CNAME a134.g.akamai.net. a134.g.akamai.net. 20 IN A 88.221.94.72
a134.g.akamai.net. 20 IN A 88.221.94.34 ...
CDNs have proven lately to be a very attractive option for hosting rich web content such as video. In fact, high profile websites such as YouTube, CNN and BBC commonly make use of commercial CDNs such as Akamai and Limelight [96].
2.3
Security of DNS
Threats targeting DNS and DNS caches in particular are not new. They have existed since the day DNS was introduced. However, the topic gained significant visibility and attention after a number of high-profile attacks such as Kaminsky’s DNS cache poisoning attack [50], described in Section2.3.3. Kaminsky discovered a fundamental flaw within DNS implementations that could allow remote attackers to corrupt the cache of a DNS server within a matter of seconds, exploiting a combination of old (known) and new (previously unknown) vulnerabilities.
Attacks against DNS can be classified as denial of service (DoS) or cache poisoning attacks. The former targets the availability of the DNS service or data, while the latter targets the integrity of the DNS data. Typically, denial of service attacks target ANSs while cache poisoning attacks target resolvers. DNS information served over the Internet is considered public. Guaranteeing the integrity and authenticity of the Internet DNS data are of top concern. Although confidentiality is generally not a concern, keeping DNS information confidential might be required in private networks (for example, networks serving internal corporate users). A good description of threats against DNS is given in RFC 3833 [13].
2.3.1 DNS Cache Poisoning
Cache poisoning, in the context of DNS, refers to act of intentionally corrupting the data contained in DNS caches. DNS messages, including queries and responses, are communicated in clear using User Datagram Protocol (UDP) [77], and possibly Trans-mission Control Protocol (TCP) [79,18], with no integrity check mechanisms in place [66], other than the basic, non-cryptographically generated, UDP and TCP checksums that are mainly targeted to detect network errors. We provide further background in-formation on UDP and TCP in Chapter3of this thesis. The lack of a proper integrity check mechanism makes DNS vulnerable to attacks involving unauthorised data mod-ification, in which an attacker may alter the data in various ways, with an ultimate objective of poisoning the content of a resolver’s cache, or possibly a DNS client’s cache. Such attacks are referred to as DNS cache poisoning and they present potential security threats to users. For example, a user can unknowing be redirected to a malicious web site, which mimics the actual one in attempt to harvest the user’s personal information;
all as a result of receiving a poisoned DNS RR pointing to the malicious web server IP address.
DNS cache poisoning is commonly achieved throughblind injection of spoofed DNS replies, where the attacker has no access to the information contained in the original DNS query. This becomes a trivial attack in the man-in-the-middle (MITM) setting, in which the attacker has visibility of all DNS data and hence can respond to DNS queries using information of his choice.
In a cache poisoning attack, the attacker may target:
• Resolvers: These servers contain cached entries and generally serve a large number of users. An attacker may try to poison the resolver’s cache for a domain or a number of domains, or even try to gain control of the underlying system running the DNS service.
• Clients: Although spoofing DNS responses from a resolver to a particular DNS client is possible, this might not be a cost effective attack, unless the client under attack is of high-value to the attacker.
The attacker can also target ANSs. These servers contain persistent DNS entries for zones. An attacker may try to control a zone (for example, “.rhul.ac.uk”) by controlling the underlying system running the DNS service. An attacker gaining control of a server acting as an ANS would have full control over the DNS zone. Attackers taking control of ANSs that are high in the DNS hierarchy (for example “.com”) can cause major Internet service disruption. However, an attack of this type does not fall under the cache poisoning category. In the next sections, we further describe the cache poisoning attack in the context of resolvers.
To successfully poison the cache of a DNS server, an attacker may spoof a DNS response and deliver it to the requester ahead of the legitimate one. Subsequent re-sponses for the same DNS query should be ignored by the requester as per RFC 1034 [65]. To be accepted by the requester, the spoofed response must also pass the standard security controls incorporated within DNS. These include comparing the DNS 16-bit transaction identifier (TXID) and the randomised UDP source port in queries and re-sponses [46]. The value of TXID is assigned by the program running the DNS service while the UDP source port assignment is handled by the underlying operating system. In RFC 6335 [27], IANA divides port numbers into three ranges:
• 0 - 1023: Well known ports;
• 49152 - 65535: Ephemeral ports.
Operating systems are expected to use the ephemeral port range when assigning random UDP source ports for DNS queries. However, operating system developers can choose to ignore this and use a smaller pool of ports for UDP source assignment or even assign sequential UDP source ports. For example, Windows Server 2008 assigns a random source UDP port numbered 49152 or above6, while earlier versions of Microsoft Windows assign it from a much smaller range of ports7, only 1024 to 5000. The Linux 2.4 kernel is configured by default to assign a port from the range 32768 to 61000. This clearly shows that DNS heavily relies on the specific implementation of the underlying operating system for the UDP source port assignment. Operating systems not properly randomising the UDP source port was one of the weaknesses that Kaminsky exploited in his attack [50].
Using a random TXID value introduces 16 bits of entropy, while using a random UDP source port adds a variable amount of entropy that depends on the operating system configuration and the number of already used UDP ports. This added entropy makes it harder to perform blind injection.
The following are definitions for some of DNS related concepts that we will use in the coming sections.
Definition 2.1. Window of opportunity: The moment right after sending a DNS
query to the moment right before the arrival of the (first) valid response. This applies to queries and responses between a resolver and an ANS or between a resolver and its upstream resolver, if it was configured with one. This also applies to queries and responses between a client and its resolver. This definition assumes that the domain name being requested is not in the cache of the resolver or the client. Responses received outside the window of opportunity should be rejected by the DNS query initiator [66].
Definition 2.2. Outstanding DNS query: A DNS query that has been sent by a
resolver or a client and is waiting for a response.
Definition 2.3. Valid DNS Response: A DNS response that meets the security
re-quirements enforced by the initiator of the DNS query.
For example, the security requirements could be matching the TXID and the UDP source port contained in the original query.
Definition 2.4. Collision: Having two or more valid DNS responses for the same
query.
6
In the case of a collision, typically, one of the responses will be spoofed by the attacker and the other will be the legitimate response.
Definition 2.5. DNS blind injection: An injection of a DNS response by an attacker
with the goal of causing a collision and ultimately poisoning the DNS cache.
There are cases, as we see later, in which the attacker has partial information about the legitimate DNS response (for example, the domain name being requested). We refer to this type of injection aspartially sighted injection.
RFC 5452 [46] gives an overview of the success probability of DNS cache poisoning attacks. The success probability, P, of an attacker poisoning the cache of a resolver after n spoofed DNS responses that arrive within the window of opportunity is equal ton divided by the size of the DNS problem space, i.e. the number of possible TXID and UDP port combinations. This assumes that the query is for a host name that is not in the resolver’s cache. The value ofP is calculated as:
P = n
N·U·T, (2.1)
where N is the number of ANSs serving the domain name being requested, with an average value of around 2.4 according to [46],U is the number of available UDP ports to choose from, and T is the number of TXIDs available (maximum of 216). Here, we assume that the TXID and UDP source port are randomly selected.
The attacker can initiate queries for domain names that are not in the cache of a resolver and follow that with spoofed responses in a partially sighted injection mode, in which the attacker has information about the domain name being requested. We would expect that the attacker can increase the number of concurrent queries for the same domain to increase the success probability. If this is the case, then for dsimultaneous outstanding queries, the success probability,Pd, is calculated as:
Pd=
n·d
N ·U ·T. (2.2)
Equation (2.2) applies when the value ofdis small, relative to the amount of entropy available. As the value ofd increases, the attacker can start exploiting the “birthday paradox”8, significantly raising the chance of success. Therefore, fordincoming queries to the same domain name, DNS resolvers are expected to rate-limit the number of requests they send to the same ANS hosting the domain name being queried [46]. This is to thwart the birthday paradox attack, which we further discuss in Section2.3.2.
If we assume that the window of opportunity is W seconds in size and that the
8
attacker can send r spoofed responses per second, all arriving within the window of opportunity, then the success probability can be calculated as:
P = W ·r
N·U·T, (2.3)
where we assume d= 1.
Some resolver implementations contained flaws in the TXID or the source UDP port randomisation processes, resulting in an insufficient amount of entropy in DNS queries and making it easier for an attacker to predict the values of the TXID or the source UDP port [50]. Other situations include the implementation of Network Address Translation (NAT) in front of DNS resolvers. A NAT device may replace the original random source port with a sequential one of its choice, also causing a reduction in the unpredictability of the UDP source port. We assume that the attacker has no access to the DNS query and hence must guess the two random variables, the TXID and the UDP source port. A more severe scenario is when the attacker acts as a MITM. In this case, attackers have visibility of all DNS data and hence can respond to DNS queries using information of their choice.
2.3.2 DNS Cache Poisoning and the Birthday Paradox
Some implementations of DNS such as old versions of ISC BIND (version 9.2.8 and earlier9) send simultaneous DNS requests to the same ANS for the same domain name. An attacker can take advantage of this behaviour by sending d DNS queries followed by an equal or higher number of spoofed DNS responses, arriving within the window of opportunity, to exploit the “birthday paradox”. The attack was first published in 200210 and gives the attacker an opportunity to match a valid response using fewer spoofed DNS responses, hoping for a collision. The more DNS queries the attacker sends, accompanied with an equal or higher number of spoofed responses that arrive within the window of opportunity, the greater the probability of collision.
If the attacker issues dDNS queries for the same domain name served by the same ANS, and sends d spoofed responses, then the probability of a collision (having two or more valid DNS responses for the same query) in the DNS responses which would result in successfully poisoning the DNS cache can be calculated using the following lower bound formula:
P = 1− 1− 1 U·T d(d−1)/2 . (2.4) 9 http://www.isc.org/downloads/BIND
The attack becomes more serious when an implementation fails to properly ran-domise the values of the TXID or the UDP source port. To protect against the birth-day attack, resolvers should be configured to limit the number of requests they send for a domain name. For example, Google Public DNS11, a free global DNS resolution service, never allows more than a single outstanding query on one of its resolvers, for the same domain name, query type, and ANS IP address.
To demonstrate the effect of exploiting the birthday paradox, let us take the case when an implementation fails to randomise the UDP source port, leaving TXID as the only source of entropy. Figure 2.4 shows the success probability, calculated using equation (2.4), as the value of the number of outstanding queries, d, increases. The attacker can achieve a success probability of 0.5 with only 300 outstanding queries and matching spoofed responses, and 0.99 with only 776 outstanding queries and matching spoofed replies; compare this to Figure 2.5, when only one query is sent from the resolver to the ANS. In both cases, we assume that the value of the 16-bit TXID has been randomly assigned.
Success Probability 0 500 1000 1500 0.0 0.2 0.4 0.6 0.8 1.0
Number of Outstanding Queries
Figure 2.4: Birthday attack success probability with variabledoutstanding queries and when relying on a random TXID only. The figure shows that the attacker can achieve a success probability of 0.5 with only 300 outstanding queries and matching spoofed responses, and 0.99 with only 776 outstanding queries and matching spoofed replies
2.3.3 Kaminsky Attack Against DNS
In this section, we give a short overview of Kaminsky’s attack [50], one of the most high-profile attacks against DNS. Kaminsky’s cache poisoning attack against DNS exploited two basic vulnerabilities in a number of DNS implementations. Not properly randomis-ing the source UDP port is a known weaknesses that Kaminsky exploited in his attack,
11
Success Probability 0 500 1000 1500 0.0 0.2 0.4 0.6 0.8 1.0
Number of Spoofed Replies with d=1
Figure 2.5: Birthday attack success probability with only one outstanding query and when relying on a random TXID only. The reader would compare this to Figure 2.4, which shows the birthday attack success probability with variabledoutstanding queries and when relying on a random TXID only
taking advantage of the fact that many implementations have ignored randomising the source UDP port. He also exploited a previously unknown vulnerability that allows an attacker to overwrite a cached DNS RR, even if the RR’s TTL has not expired. Let us assume that the attacker tries to poison a resolver’s cacheNSentry for the domain name “foo.com”. If successful, then the attacker can serve DNS queries generated by this resolver for any host name under “foo.com” (for example “www.foo.com”) using data of his choice. This will impact all the clients that are configured to use the targeted resolver. The attack proceeds as follows.
The attacker sends DNS queries for different random host names under “foo.com”, which are unlikely to be in the resolver’s cache (for example “123456.foo.com”), forcing the resolver to query the ANS serving “foo.com” for every queried host name. The attacker simultaneously floods the resolver with spoofed DNS responses, but with DNS delegation information that contains a forgedNSRR pointing to a DNS server controlled by the attacker. A vulnerability existed in many DNS implementations which allowed the overwrite of cached RRs using delegation information contained in DNS responses, and which the resolver will happily accept. Kaminsky demonstrated that combining lack of proper UDP source port randomisation and this vulnerability results in a severe attack against DNS, allowing an attacker to poison a resolver’s cache in a very short period of time, in matter of seconds in some cases. The reader can refer to [39] for greater detail on the attack.
2.4
Securing DNS Against Cache Poisoning Attacks
The amount of entropy introduced by using random TXID and random UDP source port has proven to be insufficient to protect against cache poisoning attacks, mostly be-cause of implementation issues12,13,14,15. This has resulted in various security protocols being proposed to add further controls to secure DNS from cache poisoning attacks. These protocols do not eliminate the use of a random TXID and a random UDP source port; they build on-top of these basic DNS security controls and are executed only when the standard DNS security checks pass. These protocols use techniques that can be implemented in clients, resolvers, ANSs, or a combination of them. Examples of such protocols include Domain Name Cross Referencing (DoX) [108], 0x20-Bit encod-ing [29], ConfiDNS [76], WSEC DNS [75] and DNS Security Extensions (DNSSEC) [1]. In this section, we give an overview for some of these protocols before focusing on DepenDNS [97], the protocol that we analyse in more detail in Section2.5.
2.4.1 Domain Name Cross Referencing
Domain Name Cross Referencing (DoX) [108] is a resolver-based protocol that forms peer-to-peer networks of resolvers. Resolvers in a DoX peer-to-peer network establish and maintain verification channels. A resolver joins a verification channel and gets assigned k random peers, where a peer is just another participating resolver in the same peer-to-peer verification channel. The exact process of how a resolver joins a verification channel is described in [108].
In DoX, each resolver maintains its own verification cache, vCache, which contains record entries that have been previously verified by DoX. The vCache is kept sepa-rate from the standard DNS cache that is maintained by the DNS program running on the system. DNS response messages received from ANSs are evaluated by DoX’s consistency check shown in Algorithm 1. A resolver running DoX accepts a DNS re-sponse,Rd, if an entry for the domain name being queried exists in its vCache,Rv, and Rv =Rd, else the resolver checks if Rdis consistent with what its kpeers have in their vCaches. It does this by sending Rv and Rd to its kpeers. Every peer is expected to compareRd with its vCache entry for the domain name inRd or with a fresh response
from the ANS hosting the domain name in question. Every peer would then reply back to the resolver withAgree,Disagree orDiffView:
• AnAgreereply indicates to the resolver that the peer foundRd to be legitimate,
12http://www.cert.org/advisories/CA-1997-22.html 13 http://www.kb.cert.org/vuls/id/457875 14 http://www.cvedetails.com/cve/CVE-2008-1447 15 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2926
either by finding a similar entry in its vCache or after contacting the ANS serving the domain name contained in Rd and receiving a response, Ra, that is similar toRd.
• A Disagree reply indicates that the peer found Rd to be different from the
version it has in its vCache and different from the response it received from the ANS serving the domain name,Ra.
• A DiffView reply indicates that the peer found Rv, which it received from the resolver, to be different from the entry it has in its vCache. However, it found
Ra=Rd.
A threshold value, thresh, is maintained by the resolver and is used to accept or rejectRd. If no peer replies withDisagreethen the record is accepted by DoX. Else, the resolver issues a fresh query to the ANS serving the domain name being requested. The DNS response is then saved to Ra. Rd is accepted and the resolver’s vCache is updated, when Ra = Rd and the number of received Agree replies is higher than
thresh. Else Rd is rejected by the resolver and is assumed to be the result of a cache poisoning attempt.
An issue that DoX must address is how to populate an empty vCache on start-up. The authors of [108] propose a safe start-up phase for resolvers to build up their vCache. However, they do not give details on how to implement this safe start-up phase. We are not aware of practical DNS implementations that have made use of DoX.
2.4.2 0x20-Bit Encoding
0x20-Bit encoding [29] is another resolver-based protocol that tries to increase the entropy size beyond what the random TXID and the UDP source port provide. It achieves this by encoding DNS queries using a combination of lower and upper case characters, i.e randomising the case pattern in name requests for the ranges (A..Z) and (a..z), (0x41..0x5A) and (0x61..0x7A) respectively. The protocol’s encoding relies on ANSs retaining the original string in their response and ANSs replying to any case pattern, i.e. it is required that DNS queries are case-insensitive. For example, DNS queries for “Www.rHul.AC.uk” and “www.rhul.ac.uk” would resolve to the same IP addresses, while preserving the case pattern in the responses. This behaviour follows the standard, RFC 1034 [65], which states that no significance should be attached to the case of domain names, i.e. two names with the same spelling but different case pattern are to be treated as if identical.
-Algorithm 1: DoX Consistency Check Algorithm
input : DNS query received from the DNS client, Q
input :kDoX peers received after joining a verification channel
input :thresh
output: Poison Detected, OK or WARNING
Rd←DNS Lookup(Q);
Rv ←vCache Lookup(Q);
if Rd=Rv then
return OK;
else
Send (Rv, Rd) to kpeers and get the firstm results; If #Disagree = 0return OK;
else
Ra← ANS Lookup(Q);
if Ra6=Rd then
Poison Detected;
else if Ra=Rd and #Agree> thresh then
returnOK;
else
returnWARNING;
1. The resolver normalises the DNS query, or response, field by converting each letter in the domain name to lower case.
2. The resolver encrypts the normalised version using some algorithm such as AES. 3. The resolver uses the output of Step2 to encode the domain name such that:
(a) if theith bit of the encrypted output is 0, then make the ith letter in the queried domain name upper case, i.e. perform an OR operation between the character and0x20, hence the name of the protocol.
(b) else make the ith letter in the queried domain name lower case.
The resolver then sends the encoded version of the query to the ANS hosting the domain name or to its upstream resolver if it was configured with one. Upon receiving the DNS response, the resolver applies the same algorithm to the DNS response and compares the newly produced encoded version with the name contained in the DNS response it received. The resolver rejects the response if the two do not match and
considers it a cache poisoning attempt. This assumes that the same key was used when encrypting the normalised version of the query and response messages.
Clearly, the additional entropy introduced by this encoding technique depends on the number of letters contained in the domain name being queried. For example,0x20 -Bit encoding would add only three more bits of entropy to DNS queries for “123.net”. The following shows the success probability of poisoning the cache of a resolver when implementing the protocol:
P = n
N ·U ·T·B, (2.5)
where B is the number of characters in the domain name being queried. The other symbols are the same ones used in equation (2.1). According to [29], the protocol adds an average of 12 additional bits of entropy. The authors of [29] also claim that over 99.7% of all DNS servers they have analysed could support0x20-Bit encoding.
Google Public DNS resolution service implements 0x20-Bit encoding. In a report published by Google16, two major issues have been identified when implementing the protocol:
• Some ANSs would respond with different character cases than the ones in the DNS query.
• Some ANSs are case sensitive and would respond with NXDOMAIN due to case mismatch. Receiving a NXDOMAIN RR indicates to the resolver that the name being queried does not exist in the DNS zone served by the queried ANS. To overcome these issues, Google created a whitelist containing ANSs that would support 0x20-Bit encoding. Only queries to ANSs in this whitelist are encoded. Ac-cording to Google, the whitelisted ANSs account for more than 70% of Google’s DNS traffic.
2.4.3 WSEC DNS
Wildcard secure (WSEC) DNS increases the entropy of DNS queries by randomising names contained in newly introduced TXT and CNAME RR queries. These queries are sent by resolvers to ANSs that support the protocol. Additional TXTand CNAME RRs are created in DNS zones served by ANSs to support WSEC DNS. The administrator of an ANS is expected to perform the following tasks to make use of WSEC DNS:
• Add two specific TXT RRs to the configuration of the DNS zone to indicate to resolvers that WSEC DNS is supported by this ANS for this zone. Figure 2.6
;; Respond to DNS TXT queries and indicate that WSEC DNS is supported ;; for this zone.
* 86400 IN TXT |wsecdns=enabled|
_test_._wsecdns_ 86400 IN TXT |wsecdns=enabled|
Figure 2.6: TXTRRs added for WSEC DNS.
;; Respond with a CNAME RRs to requests coming from WSEC-capable resolvers
*._wsecdns_.www IN CNAME www
*._test_.wsecdns_.www IN CNAME _test_.wsecdns_
Figure 2.7: CNAMERRs added for WSEC DNS.
shows examples of RRs added to a zone’s configuration file. The use of “*” indicates that this is a wildcard entry and hence the name of the protocol,wildcard secure DNS. An ANS responds to TXT queries, covered by this wildcard, with
|wsecdns=enabled|.
• Add twoCNAMERRs foreach WSEC-protected host name. An example is shown in Figure2.7.
WSEC DNS Process
Let us take the example when the host name being queried is “www.example.com” and when WSEC DNS is being used. The client sends a DNS query to its WSEC-capable resolver. Upon receiving this request, the resolver sends a specially formatted discovery DNS TXT RR query to the ANS serving the host name being queried. The query is in the form ofhrandi. test . wsecdns .www.example.com, where hrandi is a random alphanumeric string generated by the resolver. The ANS replies with a TXT
RR containing|wsecdns=enabled|if it was configured for WSEC DNS.
The resolver now knows whether this ANS supports WSEC DNS for the host name being queried or not. If it does, then the resolver sends a specially craftedARR query in the form ofhrandi. wsecdns .www.example.com, where hrandi is another random alphanumeric string generated by the resolver and is the source of the added entropy. The ANS responds with aCNAME RR containing “www.example.com”, an alias for the name being requested, hrandi. wsecdns .www.example.com. It also attaches the A
RR for “www.example.com” to the same response.
There are a couple of reasons why WSEC DNS is unattractive. First, changes are required on every participating ANS and DNS resolver. The large number of DNS servers and the fact that ANSs are decoupled from resolvers make this a very
difficult task to accomplish. Second, a WSEC DNS look-up would require two round trips instead of one, with larger query and response message sizes when compared to standard DNS query and response messages, increasing the amount of DNS traffic generated by ANSs and resolvers. We are not aware of practical DNS implementations that make use of WSEC DNS.
2.4.4 DNSSEC
The protocols we have described so far, other than 0x20-Bit encoding that can use AES to randomise the case pattern, do not deploy cryptographic controls to secure DNS. Examples of DNS security protocols that make significant use of cryptography include DNSSEC [1], Transaction SIGnature (TSIG) [103] and DNSCurve17 . Out of the three protocols, DNSSEC is by far the most prominent in terms of acceptance, industry support and deployment. The use of DNSSEC requires changes to resolvers and ANSs. DNSSEC provides data origin authentication and integrity services to DNS using digital signatures [10]. It also provides means of public key distribution needed for the operation of the protocol. DNSSEC relies on resolvers verifying the authenticity of responses received from ANSs to counter DNS poisoning attacks. DNSSEC is supported by most of today’s commercial and open source DNS implementations. For example, in Google Public DNS, a free Internet-based DNS service, support for DNSSEC came in January 2013.
Enabling DNSSEC on resolvers requires assigning an initial DNSSEC trust anchor. This is generally performed outside DNSSEC. DNSSEC Look-aside Validation (DLV), a protocol implemented today by a number of DNS packages, can be used for this purpose.
Definition 2.6. A DNSSEC trust anchor is a public key that acts as the entry point
for a chain of authority.
The signed DNS root would make an ideal trust anchor to consider since it gives the receiver access to all possible chains of trust used when validating a DNSSEC response. DNSSEC deploys cryptographic measures to ensure the authenticity of the DNS data exchanged by digitally signing the DNS records. RSA and SHA-1 are to be used to sign the DNS records [12, 89]. When an ANS hosting a signed zone receives a DNS query, it responses with two RRs: the RR being queried and an RR for the digital signature associated with queried RR. DNSSEC introduces a number of new RRs to contain digital signatures, public keys and key hashes [10]:
17
• DNSKEY: A record containing the public key for the zone. DNSKEY can contain either a Zone Signing Key (ZSK) or a Key Signing Key (KSK). The ZSK is used to sign the RRs in a zone, while the KSK is only used to sign theDNSKEYRR.
• Resource record signature (RRSIG): A record holding the signatures for a specific record type.
• Delegation signer (DS): A record that is submitted to the zone’s parent. DS RRs are included only in the parent’s zone, and correspond toNSRRs providing a link between the parent and the zone. DSRRs are part of the chain of trust from the zone’s parent to the zone.
• Next secure (NSEC): A record used to provide proof of non-existence of a RR. Each name in a zone has anNSEC RR added when signed to allow both positive answers and negative answers to queries to be cryptographically secure.
• Next secure version 3 (NSEC3): This record is used in negative answers to prove that a name does not exist. It is similar in function to the NSEC record, but has some advantages in certain situations. Zones signed with NSEC are “walkable.” This means that the entire contents of a zone can be retrieved simply by following theNSEC chain. Also, every name within a zone must be signed and have NSEC
records. NSEC3uses cryptographic hashes to prevent zone walking while retaining the ability to prove negative answers.
The DNSSEC specifications were first published in 1999 in RFC 2535 [1]. This RFC was then obsoleted by RFC 4033 [10] in 2005. A number of supporting RFCs such as [12,11,34,59,45,89] have also been published for DNSSEC.
Eleven years after the release of RFC 2535, in June 2010, the Internet Corporation for Assigned Names and Numbers (ICANN)18 held the first Key Signing Key (KSK) ceremony event for the root’s zone. DNSSEC for the root zone is a joint effort between ICANN and VeriSign, with support from the U.S. Department of Commerce. ICANN, a non-profit corporation, maintains an updated database19 about the global deployment of DNSSEC. As of 15th of July 2013, there were:
• 317 TLDs in the root zone in total, 111 of which have been signed. Examples of signed TLDs include “.uk”, “.com” and “.org”.
• 107 TLDs having trust anchors published as DSrecords in the root zone.
18http://www.icann.org 19
• Only 3 TLDs having trust anchors published in the Internet Systems Consortium (ISC) DNSSEC Look-aside Validation (DLV) repository.
Despite the fact that the DNS root, “.”, was signed in 2010, DNSSEC has not gained the expected momentum or adoption levels, at least in the last three years. This is clearly reflected in the numbers published on ICANN’s web site20, where for example only three TLDs have trust anchors published in the ISC DLV repository. An Asia-Pacific Network Information Centre (APNIC) report21 shows that in February 2013, around 3.3% of users had DNSSEC validating resolvers. In May 2013, this value rose to 8.1%, a 4.8% increase. This increase has been mainly attributed to the Google Public DNS service fully enabling DNSSEC. According to the APNIC report: “Of the 2.34M unique IP addresses of clients who ran this experiment, we saw 174,082 clients use Google Public DNS servers, or 7.4% of all tested clients”. These numbers relate to DNSSEC on resolvers; they do not provide an overview of how many ANSs and zones have DNSSEC configured. Although DNSSEC has had a slow start, we believe that the adoption level will pick up over time. The adoption of DNSSEC by the Google Public DNS servers and other major Internet service providers will further push in this direction. The adoption of DNSSEC is being tracked by SecSpider22, a DNSSEC monitoring project that is sponsored by VeriSign.
2.5
DepenDNS
2.5.1 Introduction to DepenDNS
DepenDNS [97] is proposed as a client-based DNS implementation designed to protect clients from cache poisoning attacks. The fundamental concept behind DepnDNS is sending the same DNS query to multiple resolvers and then evaluating the responses. The evaluation is based on an algorithm referred to asπ in [97]. DepenDNS is supposed to be practical, efficient and secure, according to [97].
The authors of [97] position DepenDNS as a comprehensive solution against cache poisoning attacks. Therefore, the protocol should be able to protect clients from vari-ous DNS cache poisoning attacks including the following three generic spoofing attack scenarios:
• Scenario 1: A spoofing attack against a client in which the attacker sends
spoofed DNS replies to the client. We assume that the attacker has no access to
20 http://stats.research.icann.org/dns/tld_report 21 http://labs.apnic.net/blabs/?p=368 22 http://secspider.cs.ucla.edu/growth.html
