[PDF] [PDF] Cache Poisoning in DNS over HTTPS clients Cache-förgiftning hos

[PDF] DoH Insight: Detecting DNS over HTTPS by Machine Learning

25 août 2020 · It provides an open-source DoH client that can be easily used as a DNS-to-DoH proxy for a local network Additionally, in the time of writing of 

[PDF] DoT or DoH: Intro to DNS Privacy - PacNOG

Encryption – DNS over TLS – DNS over DTLS – DNS over HTTPS au edu au example edu au local dns INFO[0000] Starting DNS over HTTPS proxy server

[PDF] Cache Poisoning in DNS over HTTPS clients Cache-förgiftning hos

DNS over HTTPS (DoH) is a protocol used to send traditional DNS traffic over HTTPS This causes the DNS name resolving traffic to be encrypted and transmitted over the same port as regular HTTPS traffic A number of attacks from a DoH server to a DoH client are applied

[PDF] DNS-over-HTTPS and the Rise of OTT DNS - Open-Xchange

The recently released DNS over HTTPS (DoH) protocol allows DNS queries to be encrypted and unique DNS proxy and load-balancer called DNSdist

[PDF] Éléments danalyse de DNS-over-HTTPS dans les navigateurs

Architecture classique avec des services internes ▷ le trafic HTTP(S) passe par un proxy F Contat, O Levillain Éléments d'analyse de DNS-over-HTTPS dans 

[PDF] An End-to-End, Large-Scale Measurement of DNS-over-Encryption

are proposed, including DNS-over-TLS (DoT), DNS-over-HTTPS (DoH) how to perform a Performance test on query latency using proxy networks, without 

Investigating Data Exfiltration in DNS Over HTTPS Queries

This records an enquiry to Cloudflare (see figure below) but not to dnsexfiltratingtesting com (the proxy server cannot see the destination because that is encrypted 

[PDF] dns over https router

[PDF] dns over https vs vpn

[PDF] dns server recursive query cache poisoning weakness exploit

[PDF] dns server recursive query cache poisoning weakness nmap

[PDF] dns sinkhole

[PDF] dns sinkhole list

[PDF] dns sinkhole software

[PDF] dns sinkhole windows

[PDF] dns spoof script

[PDF] do 2011 jeep grand cherokees have easter eggs

[PDF] do 2d shapes have faces

[PDF] do all companies need to be audited

[PDF] do all laptops have cancer warning

[PDF] do amines react with hcl

[PDF] do apa references end with a period

INOM EXAMENSARBETE DATATEKNIK,

GRUNDNIVÅ, 15 HP

, STOCKHOLMSVERIGE2020

Cache Poisoning in DNS over

HTTPS clients

HTTPS klienter

EMILIA BLIDBORG

CAROLINE GUNNARSSON

KTH

SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA

Cache Poisoning

in DNS over HTTPS clients

Emilia Blidborg

Caroline Gunnarsson

Examensarbete inom Datateknik

Grundnivå, 15 hp

Handledare på KTH: Martin Jacobsson

Examinator: Ibrahim Orhan

TRITA-CBH-GRU-2020:047

KTH

141 52 Huddinge, Sverige

Abstract

DNS over HTTPS (DoH) is a protocol used to send traditional DNS traffic over HTTPS. This causes the DNS name resolving traffic to be encrypted and transmitted over the same port as regular HTTPS traffic. This thesis maps a number of previous vulnerabilities in DNS and compares those risks with the DoH protocol and its implementation, mainly focusing on cache poisoning. A number of attacks from a DoH server to a DoH client are applied. The results show that it is possible to inject incorrect data into the DoH client"s cache. The consequences of this can be extensive, an example of this is a redirect to a malicious web page, which when using DoH can be difficult to detect because the DNS traffic is encrypted. Further work is needed to mitigate the security holes discovered, as well as to further identify potential threats.

Keywords

DNS over HTTPS, DoH, cache poisoning, RFC 8484, DNS security, DANE

Sammanfattning

Konsekvenser av detta kan bli omfattande, ett exempel kan vara en omdirigering till en

Nyckelord

Acknowledgements

We want to thank Internetstiftelsen for this opportunity and provision of equipment needed to carry out this study. We want to give an extra thanks to Ulrich Wisser at Internetstif- telsen for all the support and guidance during the study. We also want to thank Martin Jacobsson, who has been our mentor at KTH throughout this study.

Glossary

CACertificate Authority.

DANEDNS-based Authentication of Named Entities.

DDOSDistributed Denial of Service.

DNSDomain Name System.

DNSSECDomain Name System Security Extension.

DoHDNS over HTTPS.

HTTPHypertext Transfer Protocol.

HTTP/2Hyper Transfer Protocol Version 2.

HTTPSHypertext Transfer Protocol Secure.

IDSIntruder Detection System.

IPSECInternet Protocol Security.

ISPInternet Service Provider.

MITMMan-in-the-middle.

PKIPublic key infrastructure.

RFCRequest for Comments.

RRResource Record.

SNIServer Name Indication.

TLSTransport Layer Security.

TRRTrusted Recursive Resolver.

Contents

1 Introduction 1

1.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Goals of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Scope of the project and delimitations . . . . . . . . . . . . . . . . . . . . 2

2 Theory and background 3

2.1 A brief introduction to DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 DNS flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 DNS message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.3 DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 DNS over HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 The DoH package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Hyper Transfer Protocol Version 2 . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Streams & Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.2 Server push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.3 Initialization phase . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 DoH and browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Weaknesses of DoH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1 User privacy and parental control . . . . . . . . . . . . . . . . . . . 10

2.5.2 Security view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Previous work regarding DoH . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7 Previous known attacks and vulnerabilities in DNS . . . . . . . . . . . . . 12

2.7.1 Attacks against resolvers . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7.2 Man-in-the-middle attack . . . . . . . . . . . . . . . . . . . . . . . 12

2.7.3 Cache attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7.4 Other attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.8 DNS-based Authentication of Named Entities . . . . . . . . . . . . . . . . 14

3 Methodology and Results 15

3.1 Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Argument for choice of client . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Lab enviroment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.1 DoH server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.2 DoH client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.3 Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Choice for modification of code . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Injection tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6 Compilation of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Analysis and discussion 25

4.1 Analysis of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Conclusion of the goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Error margins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Economic, social, ethical and environmental aspects . . . . . . . . . . . . . 28

4.6 Other aspects and solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Conclusions 31

5.1 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 References 35

INTRODUCTION | 1

1 Introduction

The Domain Name System (DNS) is a vital part of the Internet and a requirement for its full functionality. Almost all services available on the Internet rely on and start with a DNS query, which has the main task of translating domain names into IP addresses. DNS was developed in 1984 by Paul Mockapetris [1]. When building its structure, the security was not the main consideration. Due to that they did not think there would be a matter of integrity. At the same time, the protocol is constantly evolving to make the name translation more efficient and secure. DNS over HTTPS (DoH) [2] is one of the protocols that has been developed to meet these vulnerabilities. The protocol establishes encrypted connections to send DNS queries and responses through. Firefox already supports this technology and their browser will be used as a DoH client for this study.

1.1 Problem statement

DoH is a relatively new technique for managing DNS queries. As popular web browsers have begun to implement the technology, an examination of the protocol is important. The protocol is based on HTTP/2 [3], and the main goal is to achieve integrity by encrypting the communication between client and resolver. This means that the DNS queries are encrypted and not sent in plaintext as previously, and also sent over the well-known port

443 and thus inseparable from regular HTTPS traffic. Is this a problem or is it only an

advantage for privacy? There is a lot of ongoing discussions about the protocol, including privacy and who owns the huge amount of DNS data being transported. This data may contain sensitive information about users, such as IP address and browsing habits. Since queries are only encrypted part of the transport route, these data are also visible to some extent for certain nodes in the chain. Is it possible to apply known DNS vulnerabilities to DoH? Does DoH prevent Internet Service Providers (ISPs) from tracking user data? Or does this only centralize the DNS traffic?

1.2 Goals of the project

As this is such a new area, this study will examine any possible exploits or security vul- nerabilities that the protocol or its implementation may cause users. Both from the user"s expectation of the protocol but also flaws in the design. The main area that will be ex- amined is the possibility to inject false information into a web browser"s cache memory and thus send the wrong IP address to the clients and redirect them to the wrong website. This study will also examine the lack of integrity in the protocol.

2 | INTRODUCTION

The goals of this study were presented by Internetstiftelsen. And three main goals were developed: Examine if there is any unknown vulnerability regarding the protocol DoH, with focus on cache poisoning attacks. Analyze which known DNS vulnerabilities the protocol DoH is able to protect against. Investigate how a typical DoH client handles data that has not been requested. In addition to these main goals, the following sub-goals were formulated:

Study the structure of DoH packages.

Study the DNS name resolve cache of the web browser. Investigate who has access to sensitive user data. Map what users of the protocol expect, and what they actually get. Develop a DoH server that intends to provide client with manipulated DNS data.

1.3 Scope of the project and delimitations

This project only covers the evaluation of the protocol DoH. Other protocols, also designed to make DNS lookup safer, is only taken into consideration when discussing future work. Due to time limitations, only a few of the potential threats found were tested in the lab environment, and others are only discussed in a later chapter.

THEORY AND BACKGROUND | 3

2 Theory and background

This chapter covers the presentation of previous work in the field, as well as the underlying theory. The DNS over HTTPS (DoH) protocol is reviewed and implementations that support the protocol are presented. Previously known vulnerabilities with regular DNS are studied, in order to be able to evaluate the protocol DoH easier later in the study.

2.1 A brief introduction to DNS

The purpose of this section is to introduce DNS and its functions on the internet and is aimed for readers who do not have enough knowledge in the field. With the help of DNS, the user does not need to remember the IP address of the web server to which the connection is to be made, the user can instead remember an alias name. The Domain Name System (DNS) is a distributed system [1], it is hierarchical and structured as a tree to facilitate the search. Part of the domain namespace represents a zone, this zone can be managed by, for example, a person or an organization. Each zone includes one zone file, also called a "master file" [4] which includes a number of entries specific for that zone. A resource record (RR), like an IPv4 or IPv6 address, that is included in the domain can take 2 different forms:

OWNER-NAME TTL class type RDATA

OWNER-NAME class TTL type RDATA

OWNER-NAME: Specifies the name of the resource record. TTL: "time-to-live", an integer indicating how long the resource record should be cached before it should be fetched again. class: Class code for the resource record, the by far most common is IN that represents "the Internet". type: Specifies the type of RDATA in the record, such as IPv4 address. RDATA: Contains the values of the resource record, the format of this field varies depending on TYPE and CLASS, for example if TYPE = A and CLASS = IN, the RDATA field is a "4 octet ARPA Internet address" [4], i.e. an IPv4 address. A set of Resource Records with the same owner name, class, and type are grouped together and are referred to as an RRset [5, see section 5].

2.1.1 DNS flags

To understand the DNS responses in the execution of the study, relevant DNS flags are presented below [1].

4 | THEORY AND BACKGROUND

AD: Authenticated Data. If the AD bit is set, it means that the answer is validated. Allows resolvers that cannot verify DNSSEC themselves to instead study the AD flag in the received response from the name server. The resolver should then only trust the AD bit if the communication channel is secured, like for example Internet Protocol Security (IPSEC). Which is the case for DNS over HTTPS, as the channel is encrypted. AA: Authoritative Answer. If the query goes to an authoritative server, the AA flag is set in the response. RD: Recursion Desired. It indicates that the client wants the nameserver to act resolver if possible. RA: Recursion Available. It is set in the response if the server was able to perform recursion. QR: If set, the package is a response, otherwise a query.

2.1.2 DNS message

For the domain protocol, the standard format is called a message. The message contains

5 sections.Figure 1: Example of a DNS Message [4].

2.1.3 DNSSEC

Domain Name System Security Extensions (DNSSEC) is a mechanism for verifying records in DNS [6]. The "Authentication Chain", is built on public-key cryptography and can prove the authenticity of a DNS response. Cryptographic signatures of DNS records are stored in RRSIG records. A private key is used to create the signature, and its public key is stored in DNSKEY records, which can be used for validation. DS records are used to create a

THEORY AND BACKGROUND | 5

chain of trust between the zone and its parent zone. The Delegation Signer (DS) RRset includes a hash of a particular DNSKEY. Each DNSSEC signed zone can be associated with an key pair [1]. The RRset Signature (RRSIG) records stores the digital signature for an RRsets private key and is used to sign that particular RRset. DNSSEC also provides a guarantee that the content had not been modified along the way. DNSSEC does not encrypt DNS-packages in the sense of maintaining the confiden- tiality of the content.

2.2 DNS over HTTPS

DNS over HTTPS (DoH) is a protocol for handling DNS queries over HTTPS. The main goal when developing DoH was to increase integrity. This could be done by encrypting the data transported between the client and the server. The protocol is published as a proposed standard in RFC 8484 [2]. There are different ways to apply DoH to the client in need of resolving. For example: DoH support can be implemented in the web browser, like the Mozilla firefox web browser [7]. DoH support can be implemented in the operating system, like Microsoft Windows [8]. RFC 8484 defines a proposed standard for DNS queries over HTTPS. The protocol is only defined for HTTPS, which denotes that DNS queries always are encrypted and resolvers are always authenticated. HTTP/2 is the minimum recommended version of HTTP to utilize together with DoH, this protocol is presented in section 2.3. A client and a server that support this protocol are called a "DoH client" and a "DoH server" respectively. The DoH server is separated from the DNS servers and must im- plement both POST and GET methods. Section 2.2.1 describes the structure of the two packages. A DoH client must configure which DoH server to use for resolution, this is done by specifying the URI of the DoH server.

2.2.1 The DoH package

The DoH package is a standard DNS wire format inside an HTTPS payload [2]. One HTTP exchange consists of a request-response pair mapped to it. The protocol defines an HTTP request and an HTTP response layout. The following is an example of a request which uses POST to requestwww.example.com:

6 | THEORY AND BACKGROUND

Figure 2: DNS query using POST [2, see section 4.1]. The DNS query is inside the message body, and the "content-type" field indicates that the

media type of the message is DNS. The same request which uses GET would look like:Figure 3: DNS query using GET [2, see section 4.1].

The data payload must be encoded with base64url for GET methods, this does not apply to POST methods. The DNS query is in a GET parameter. From the HTTP cache point of view the GET method is easier to use. To further facilitate HTTP cache, DoH clients should set the DNS ID to zero if they include fields such as "application/dns-message". In case of varying the DNS ID, equivalent DNS queries may be cached separately.

2.2.2 Errors

A DoH server will produce a successful HTTP response for all valid DNS responses [2, see section 4.2.1], including SERVFAIL and NXDOMAIN. SERVFAIL may indicate that the server is misconfigured or that there was a problem retrieving the data, and NXDOMAIN indicates that the domain name does not exist. Even though the DNS response indicates failure, the DoH server will produce a 2xx HTTP status code.

2.2.3 Cache

During an exchange between a DoH server and a DoH client, the packages can pass through a series of different caches that can be both HTTP and DNS specific [2]. These caches can be placed at different locations, such as between the server and the client or at the client. The RFC 8484 does not present that the protocol itself implements any cache.

THEORY AND BACKGROUND | 7

To make sure that clients are using the latest DNS data the DoH server can delegate a special HTTP value to indicate its freshness. This is specified with the attribute "Cache- Control", and help make sure that expired RRsets is not used from an HTTP cache.

2.2.4 Security

The DoH protocol only provides security in the connection between the DoH server and the DoH client [2]. Thus, traffic is only encrypted during part of the total route. This means that the server and possibly any resolvers involved can see the DNS content. Once the client has resolved the DNS query, an HTTPS connection to the webserver is still needed where information such as IP address and also Server Name Identifier is visible to others in the network during the initialization phase [9]. DNSSEC and DoH are two separate protocols, with different security-related goals [2]. Thus, they can be combined. The DoH protocol can not guarantee valid data without DNSSEC enabled. DoH and HTTPS share the same well-known port 443. One connection can mix both DoH and other HTTPS traffic. The HTTP transport is responsible for security when running DoH. In the "security considerations" section, in the RFC 8484 [2, see section 9] it says that it is up to the client whether the verification should take place as a full DNSSEC validation or just trust the DoH server to do the verification and just check the AD flag, to determine if the answer was authentic.

2.3 Hyper Transfer Protocol Version 2

The Hyper Transfer Protocol Version 2 (HTTP/2) [3] is an enhancement of the HTTP pro- tocol in terms of efficiency, performance, and security. Most of the protocol has remained unchanged to achieve compatibility with the current use of HTTP.

2.3.1 Streams & Multiplexing

An HTTP/2 stream is a sequence of frames sent by either client or server [3, see section

5]. An HTTP/2 connection can contain multiple open streams. The streams are identified

by an unsigned 31-bit integer that is assigned by the initiating side. When the stream is in the "open" state, frames can be sent by both sides and the stream can be terminated by both endpoints. This enables sending requests and responses over the same connection, and this increases efficiency.

2.3.2 Server push

Server push is a mechanism for pushing assets to the client without the client requesting it [3, section 8.2]. A server push is equivalent to a response generated by a server at the request of a client, without the client requesting it. This enables the server to send information that it believes the client will ask for in the near future, which can increase

8 | THEORY AND BACKGROUND

performance. With this feature, the server must be sure that the client would have directed the same query to the pushed URI if the client would have sent the request.

2.3.3 Initialization phase

The Transport Layer Security (TLS) handshake protocol is for negotiating parameters necessary for the session, including things like peer certificate X.509v3 digital certificates. TLS 1.2 or higher is a requirement for HTTP/2 [3, section 9.2]. An established connection

example for TLS 1.2 is stated below.Indicates optional or situation-dependent messages that are not always sent.

Figure 4: "Message flow for a full handshake" [10, section 7.3]. There has been a discussion about whether DoH really protects the user"s integrity when, for example, certificates and Server Name Indication (SNI) are visible when establishing a connection to a web server. In TLS 1.3 all the messages included in the handshake protocol sent after ServerHello, is encrypted [11]. This means that the server certificate is encrypted, but the SNI in the Hello-phase is still in cleartext. A draft in Internet Engineering Task Force (IETF) for TLS 1.3 [12] presents a mechanism for encrypting the SNI, and is already tested on the market. On the 24th of September 2018 Cloudflare wrote a post on their blog announcing they were the first to support Encrypted Server Name Indication (ESNI) [13]. Firefox has also started working on this [14].

2.4 DoH and browsers

By studying the Internet-Drafts published by the Internet Engineering Task Force (IETF) [15] it appears that Mozilla and Internet Corporation for Assigned Names and Numbers

THEORY AND BACKGROUND | 9

quotesdbs_dbs14.pdfusesText_20