Cache Poisoning in DNS over HTTPS clientsCache-förgiftning hos DNS över HTTPS klienter

(1)

INOM

EXAMENSARBETE DATATEKNIK, GRUNDNIVÅ, 15 HP

STOCKHOLM SVERIGE 2020,

Cache Poisoning in DNS over HTTPS clients

Cache-förgiftning hos DNS över HTTPS klienter

EMILIA BLIDBORG

CAROLINE GUNNARSSON

KTH

SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA

(2)

(3)

Cache Poisoning

in DNS over HTTPS clients Cache-förgiftning

hos DNS över HTTPS klienter

Emilia Blidborg Caroline Gunnarsson

Examensarbete inom Datateknik Grundnivå, 15 hp

Handledare på KTH: Martin Jacobsson Examinator: Ibrahim Orhan

TRITA-CBH-GRU-2020:047 KTH

Skolan för kemi, bioteknologi och hälsa 141 52 Huddinge, Sverige

(4)

(5)

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

(6)

(7)

Sammanfattning

DNS över HTTPS (DoH) är ett protokoll som används för att skicka traditionell DNS trafik över HTTPS. Detta medför att trafiken blir krypterad och sänds över samma port som vanlig HTTPS trafik. Denna rapport kartlägger ett antal tidigare sårbarheter i DNS och jämför dessa risker med DoH protokollet och dess implementation, främst med fokus på cache-förgiftning. Ett antal attacker från en DoH server till en DoH klient tillämpas.

Resultatet visar att det är möjligt att injicera felaktig data i DoH klientens cacheminne.

Konsekvenser av detta kan bli omfattande, ett exempel kan vara en omdirigering till en skadlig webbsida, vilket vid användning av DoH kan vara svårupptäckt på grund av att DNS traffiken är krypterad. Vidare arbete krävs för att förmildra de säkerhetshål som upptäcks, samt att ytterligare identifiera potentiella hot.

Nyckelord

DNS över HTTPs, DoH, cache-förgiftning, RFC 8484, DNS säkerhet, DANE

(8)

(9)

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.

(10)

(11)

Glossary

CA Certificate Authority.

DANE DNS-based Authentication of Named Entities.

DDOS Distributed Denial of Service.

DNS Domain Name System.

DNSSEC Domain Name System Security Extension.

DoH DNS over HTTPS.

HTTP Hypertext Transfer Protocol.

HTTP/2 Hyper Transfer Protocol Version 2.

HTTPS Hypertext Transfer Protocol Secure.

IDS Intruder Detection System.

IPSEC Internet Protocol Security.

ISP Internet Service Provider.

MITM Man-in-the-middle.

PKI Public key infrastructure.

RFC Request for Comments.

RR Resource Record.

SNI Server Name Indication.

TLS Transport Layer Security.

TRR Trusted Recursive Resolver.

(12)

(13)

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 vulnerabilities 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 examined 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.

(16)

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.

(17)

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].

(18)

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

(19)

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 implement 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 request www.example.com:

(20)

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.

(21)

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 protocol 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

(22)

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

(23)

(ICANN) has been at the forefront when it comes to developing the DoH-protocol.

Mozilla supports DoH in the Firefox browser [7]. Currently, Cloudflare, which is the default trusted resolver when using DoH resolution in Firefox, performs validation with DNSSEC on the queries sent to their DoH resolver. Mozilla started working on DoH in 2017, with the intention of securing the use of DNS for their users. They considered that the original approach for DNS no longer was a fit for the modern Internet. On February 25 in 2020, they began standardizing DoH for US-based users [7, 16, 17].

Firefox uses what they call Trusted Recursive Resolver (TRR) provided by, for instance, Cloudflare for handling the DoH requests as a default. Cloudflare has committed to “throw- ing away all identifiable data after 24 hours, and also to never pass data along to third parties” [18]. Cloudflare’s resolvers also use one of their own IP addresses located near the user to make requests and therefore can reduce the information collected about the user.

This also improves the election of a content delivery network close to the user. Also DNS Query Name Minimisation is implemented by Cloudflare to reduce potential data collec- tion [19], at the root and Top Level Domain (TLD) name servers. Firefox users can also use the resolver provided by NextDNS, which also has agreed on the policy requirements specified for the resolver to be a TRR [17].

On November 17, 2019, Microsoft posted an announcement on their Networking blog about integrate native support for DoH in the company’s Windows 10 operating system [microsoft blog]. Their future goal is to make DoH configuration user-friendly, in order to provide the ability to select which DoH server to use.

Google launched DoH as an experimental service in 2016 [20]. On June 26, 2019 they announced that their standard DoH service now has general availability. According to an article written by nccgroup [21] Google Chrome only has support for using one of the 7 default providers of DoH-servers. No information regarding support for DoH in Apple Safari was found.

2.5 Weaknesses of DoH

The first malware found to abuse the DoH protocol was a malware named Godlua Back- door. The malware was discovered by security researchers at the Network Security Research Lab of Qihoo 360 on April 24, 2019 [22]. And was initially used to attack unpatched Linux servers, and acts as a backdoor. The security company is not sure how the malware exactly infects the targeted victim, but they pronounce that it works as a Distributed Denial of Service (DDoS) bot. They say that they have found two versions of Godlua so far, which both work in a similar way. Godlua uses the DoH protocol to obtain a text record for a specific domain name.

PsiXBot is another malware that abuses the DoH protocol [23]. In this case, Google’s DoH service is the target, and PsiXBot is a Windows malware. PsiXBot can be used for multiple attacks, including keylogging and cookie/password theft. The use of DoH makes it more difficult to detect running infections.

(24)

2.5.1 User privacy and parental control

One of the main reasons for developing DoH was to improve the privacy of users. And even if the protocol covers many of the vulnerabilities DNS holds, it also has some weaknesses.

It is not completely private, in order for the resolver to do the lookup, it needs to know the query and the source IP address.

Firefox has prioritized encryption for securing user’s privacy, but has not yet implemented DNSSEC [14]. They believe that users do not have enough knowledge in the role of DNS when using the Internet [24]. Therefore, they are enabling DoH as a default for all US-users in order to improve privacy. These users will be warned with a pop-up, which will not disappear until they approve or reject the change [14]. Mozilla states that the usage of DoH in Firefox does not interfere with any parental control [24].

Chrome’s idea is to simply check if the user’s DNS provider is included in their list of DoH providers, and if that is the case, DoH will be enabled for the user [25]. With DoH enabled, existing content controls will remain active, according to Chrome.

Firefox and Chrome both direct DoH-based DNS traffic to a few servers that support DoH. This is believed to result in greater centralization of DNS [26]. So far, most users themselves have to configure DoH to access the service. Firefox believes that enabling DoH will result in less centralization “because it shifts traffic away from large ISPs, and provides users with more choice, while respecting enterprise DNS configurations” [24].

Content controls are often implemented by matching responses with blocked sites, if the servers that perform this function are bypassed to centralized DoH servers then the content control will not be performed. This information was published in an Internet-Draft about implementation issues and risks with DoH [26]. The draft expired in September 2019 but the ideas that were raised are still relevant for this study. People may not want centralized DoH providers to perform this function. If the user has configured his own DNS resolver to perform content controls, some software may override these configurations and use a centralized DoH server instead.

2.5.2 Security view

When implementing DoH some security aspects should be kept in mind. For example, DoH could help intruders to by-pass the organization’s security controls, like firewalls.

There is also a loss of visibility when using DoH, which could cause a problem for logging systems but advantages for the attacker. This could also cause DoH to be used for malware command and control [26].

As mentioned in the previous section, there is a belief that DoH will contribute to greater centralization of DNS. This would lead to fewer points of failure, which would make DNS more vulnerable. For example, by only attacking a few platform providers the entire Internet can be disrupted [26].

DoH makes it hard for the Intruder Detection System (IDS) to control incoming and outgoing traffic in the network. Partly because the traffic is encrypted but also the fact that it is inseparable from HTTPS traffic, on the well-known port 443.

(25)

Due to possible centralization of DNS, queries may not reach servers that perform monitoring. DoH can thus contribute to creating blind spots with security in mind. This also creates problems with the implementation of split-horizon DNS [5], which intends to split access into internal and external networks. Security and privacy is something you want to achieve with this. When using a centralized DoH server, the domain names in the internal network, will not be able to be resolved [26] by the server. This because these domain names are only stored on a local resolver, with a local IP address, and thus is only reachable from the local network. Moreover, there is a risk that the internal names will leak. For Chrome, split-horizon DNS implementations will probably not be affected by enabling DoH. This because, as mentioned earlier, Chrome only uses DoH if the system resolver has support. In other words, they do not change the configured resolver [27]. If you have ordinary DNS configured as a fall back for DoH in Firefox, the domain will be resolved when DoH fails. If the domain happens to be publicly resolvable to the enterprise has to disable DoH for the lookup to work [14].

2.6 Previous work regarding DoH

Since DoH is a new and hence quite unexplored area there are not many published studies.

No previous work, related exactly to the area of this study was found. Studies in the adjacent area are presented in this section.

In a study from July 2019 regarding the padding strategy for DNS over TLS/DNS over HTTPS and its impact on privacy the encrypted TLS/HTTPS communication between a client and a resolver is observed [28]. This study examines if padded and encrypted DNS increases anonymity when users visit websites. The “eavesdropper” in this study can only investigate the traffic between the client and the resolver. The result of the test shows that 93.3% of the websites could be partially deanonymized and 78.1% of the DNS sequences could be correctly classified. When the study was released in July 2019 they were according to the authors themselves, the first to show that “passive adversaries can inspect sequences instead of just single DNS transactions to break widely deployed best practice of DNS message padding.”

Tor [29] is a service that enables anonymous communication over the Internet. And may, according to a study made in 2019 about encrypted DNS, be good together with DoH to protect against traffic analysis [30]. The study is investigating how effective traffic analysis attacks are to reveal the user’s browser habits on encrypted traffic. EDNS0 is observed with the conclusion that the padding does not work as well as expected.

In January 2019 a study regarding Exfiltration in DoH queries was developed as a part of the “2019 IEEE 12th International Conference on Global Security, Safety and Sustainability (ICGS3)” [31]. Difficulties were discovered in detecting the abuse of DoH in a case of DNS tunneling where the attacker already succeed in gaining access. Another conclusion mentioned in this study is that DoH may seem to be a major advantage for privacy in the browser, but puts network security at risk.

In March 2020 Roger Meyer from nccgroup posted an article regarding the “impact of DNS over HTTPS (DoH) on DNS rebinding Attacks” [21]. They tested several DoH

(26)

services with their DNS rebinding framework “Singularity of Origin” to see the impacts of DNS rebinding attacks. The result shows that DoH did not resist the rebind “attacks”

implemented in Singularity. This including the “fast multiple answer strategy” that in just a few seconds can allow rebinding. The DoH providers: Cloudflare, Google, and OpenDNS was tested on both Chrome and Firefox, and the attack were successful on all combinations.

Several studies on cost, performance, and similar have been made about DoH. These do not affect the area of this study and will, therefore, be excluded.

2.7 Previous known attacks and vulnerabilities in DNS

DNS is, as previously mentioned, necessary for the functionality of the Internet. Over the years there have been some attacks and vulnerabilities on DNS, the most common are listed below. These attacks will later be evaluated continuously throughout the study.

2.7.1 Attacks against resolvers

An eavesdropper can sniff traditional DNS traffic that is not encrypted, depending on where the resolver is located, the “attack surface” varies [32]. For example if the resolver is located somewhere in the local network, the attack surface is the local network. What DoH does is to minimize this “attack surface” by encrypting queries and thus make it difficult for an eavesdropper to capture its content.

A recursive resolver sees all DNS queries and therefore knows a lot about the user.

There are public resolvers, like google’s 8.8.8.8 that gains a huge amount of data from its users. The use of a local resolver has its pros and cons. Since communication takes place locally, the risk of eavesdropping is reduced, but at the same time the privacy becomes lower as the server can map an IP address to the end client. The attack surface becomes larger with the use of a public resolver since the query has to leave the local network.

The source address sent between the recursive resolver and the authoritative nameserver is the address of the resolver, thus maintaining anonymity for the user [32]. This can however cause a problem if the user has an own recursive resolver on its machine. Unlike an HTTP connection where the source address points directly to the user.

2.7.2 Man-in-the-middle attack

A man-in-the-middle (MITM) attack involves modify or intercept communication between two devices [33]. In a DNS case it could be a resolver returning false information directly to the client or an attacker altering and modifying records on the way back to the client.

A man-in-the-middle attack can occur anyway along the path the DNS package travels.

2.7.3 Cache attacks

Cache poisoning or DNS spoofing is when the attacker attempts to inject incorrect DNS records into the cache memory. The “chain of trust”, that is used by DNSSEC can help verify that the data is correct, and thus mitigate the risk for cache poisoning. The Kaminsky

(27)

bug [34] is an example of a cache poisoning attack applicable to a non-verifying resolver.

The Kaminsky bug was discovered in 2008, by Dan Kaminsky and could be applied to badly updated resolvers. Before DNSSEC, the only verification of authenticity required was that the DNS response ID matched with the DNS query ID. The ID is a number between 0-65535. Shortly, if a malicious source could guess the correct ID-number to an answer, the resolver would then cache the answer and move on with its work. The correct answer from the actual source would just be thrown away by the resolver. This can also happen to mail servers, to spoof emails.

Tracking is another cache attack. To reveal information about the client using the recursive resolver by sending queries with the recursion desired flag set to 0. By doing this cached data can be revealed.

2.7.4 Other attacks

DNS hijacking, also called redirection, is the result of incorrect resolved DNS queries [35].

This means that an IP address received from the DNS server points to a different server than expected. And redirect the user to a possibly malicious site.

DNS rebinding is an attack that deviates from the security mechanism “same-origin policy” which is a set of rules about how to different domains may interact with each other. This including malicious resources like documents or script loaded from the other domain [36]. Same-origin means identical scheme, host, and port components for the web documents. The following is an example of such an attack:

The target is a private IP address inside the network and can not be reached by the attacker [37]. The attacker owns a domain and has a web page for it and somehow gets a user to connect to it. When a user asks for a connection, an A record with the correct IP address is returned.

Javascript code runs continuously in the browser. When the TTL expires, a new query must be made in the same origin. This time another response is received, the IP address of the target which is a private IP address (127.0.0.1 or similar). Since we are still in the same origin, this is allowed. This results in the attacker being able to read the HTTP responses. The attack in short, involves sending a further query within the same origin and thus avoiding the firewall. One problem with this attack is that the attack can legitimately sign all the DNS records for his domain because he owns the domain. DNS servers along the way can filter out a private IP address, in the method section of this paper an attempt to add a private IP in the last server in the transport chain before reaching the browser will be made.

In April 2018, Louis Poinsignon made a post on a blog on Cloudflare [38] about an incident affecting the site for MyEtherWallet, a wallet for cryptocurrency. A Border Gateway Protocol (BGP) leak had redirect traffic, using a poisoned resolver, to the wrong IP address.

(28)

Users with HTTPS did though, get a warning that this site had a self-signed certificate.

But the malicious site was just a click away and if the user accepts the certificate the attack could get the user’s login information to steal their Ethereum. Since there were so many actors involved, find someone to blame for this mistake was hard. The discussion of whether BGP needs securing or not arose. The post included a few things to mitigate attacks like this, DNSSEC, DANE, DNS over HTTPS, and HTTPS for example. The more of these included the less the risks. DNS over HTTPS was brought up as a way to guarantee the identity of the resolver. The attack resulted in 150 000 $ [39] stolen from users and this sum could probably be even higher.

2.8 DNS-based Authentication of Named Entities

DNS-based Authentication of Named Entities (DANE) is a protocol that uses DNSSEC and its infrastructure to manage certificates [40]. DANE can bind public keys to DNS names using DNSSEC, without a Certificate Authority (CA) being involved to sign the certificate. To do this, it uses DANE TLS Authentication (TLSA) records. A DANE record is added to the zone file, this can authenticate the web server using the DANE record and its own certificate [41]. This means that the owner of the web server creates their own certificate with corresponding DANE entries in the zone file.

In March 2018, a draft was published [42] to use DANE in combination with TLS.

This draft is no longer active and expired on September 22, 2018. The idea behind this was to allow TLS clients to authenticate a TLS server using DANE, without delay and additional DNS lookups. To replace the use of trusted public Certification Authorities and the traditional Web public key infrastructure (PKI) and let DNSSEC validate the DANE TLSA records. The publisher of the TLSA record in the zone will be the customer itself if the domain is not outsourced i.e.

In a post from July 2017 from the Asia Pacific Community (apnic) blog page, Shumon Huque, one of the authors of the RFC draft, describes one of the reasons why DANE has not had a breakthrough in the web industry [43]. The reason is that DANE is not considered an improvement over Web-PKI, one reason might be that DNSSEC often only signs with 1024-bit RSA keys. One method mentioned for proposed usage was that web clients would remember if a server has offered DANE authentication before, and if so require it. Except if the server could prove the removal of DANE. He also mentions that the prospect for DANE authentication solution in the web “are quite bleak”, due to fundamental disagreements between actors involved. For the future of the TLS DNSSEC Chain Extension he thinks that the first use case will be for DoT servers (DNS over TLS).

Another post, written by Geoff Huston also on the apnic blog page in May 2019 [44]

also discusses DANE and possible security improvement. According to Huston, Mozilla had an implementation funded and planned for the draft discussed above. But later the draft was abandoned, due to what he cites Shumon was a “huge fight”. Even Huston, like Huque, points out the dark future of DANE at the moment.

(29)

METHODOLOGY AND RESULTS | 15

3 Methodology and Results

Considerations made to achieve the objectives of this study are presented further in this section. First, the chosen methods will be presented and discussed. Then the lab environment is presented, including the configuration of the selected server and client. Subsequently, the modifications made to carry out selected attacks are presented, with associated results.

Finally, the attacks carried out and their results are compiled.

3.1 Research methodology

The first phase of the execution was to perform a literature study. Considering DoH is such a new protocol, there are not many previous relevant studies in the area. The main purpose of the literature study was to gather as much information as possible, the result of this is presented in Chapter 2, in order to be able to design the tests presented in section 3.5.

Since this study examines vulnerabilities in the protocol, a lot of time were put into the preparation part of this report which has involved testing of unsuccessful attacks and searching for potential threats. This has been done by studying different parts of the protocol very closely and examining if other known attacks or vulnerabilities are applicable to it. This makes the study quite extensive, especially in the pre-study phase, but some areas have been excluded due to lack of time.

The choice of execution is based on that DoH, as previously mentioned, is such a new protocol. Therefore, the literature study needed to be included throughout the study.

This because new information and new studies are constantly being published. During the performance of the tests the results are only based on observations of the client’s behavior and the client’s DNS cache.

The approach chosen to inject incorrect data into the client’s cache was to modify the source code in the DoH server. This to see if it is possible to deceive the client that correct data has been received. There are deficiencies to the method, these are presented in section 4.4.

3.2 Argument for choice of client

The Firefox browser was chosen as the client for this study, the reason for this was partly that the configuration of DoH in Firefox was very easy. Firefox has also, as previously discussed, been at the forefront when it comes to pushing for DoH and that makes a good reason to further investigate if security risks have been kept in mind.

There are also other popular browsers on the market that would have been interesting in this study, such as Google’s Chrome. However, it was excluded because of the non- existent support of configuring a custom DoH provider. As earlier mentioned in section 2.4, Chrome only supports 7 default providers of DoH servers. There seems to be no support for configuring an own DoH server at this time.

(30)

16 | METHODOLOGY AND RESULTS

3.3 Lab enviroment

The DoH client used in this study was the Firefox browser. An Ubuntu machine with version 18.04.4 LTS was configured as the DoH server, this machine is the most recent long-term release [45]. The main goal is to test whether the client responds to data that has not been requested. The choice of lab environment is discussed further in section 4.4.

The following shows an interaction chart of the lab environment.

Figure 5: Interaction chart of the lab environment.

3.3.1 DoH server

An application named “DoH proxy” [46] was cloned to the server from the GitHub repository in order for it to handle the DoH queries over HTTPS. This application is licensed with a BSD-3-Clause license, which means that the source code is permitted to be used with or without modification [47], it was therefore well suited for this purpose. There were only a few applications that seemed enough developed when looking for DoH servers. The final choice stod between two applications, one which was written in the programming language GO, which was not a well-known language to the group. Therefore, the "DoH proxy" by facebookexperimental was chosen. The DoH proxy source code was modified to be able to perform the cache poisoning attempt to the client. This was done with a DNS toolkit for Python, called dnspython [48].

The DoH-server can answer DoH requests, it does not act as a resolver. A recursive resolver is selected at startup so that the proxy can forward the received queries for resolving. In this study Cloudflare’s resolver, with IP address 1.1.1.1, was used. The DoH server does not implement any form of cache, for every request a query is redirected to the defined resolver and the response sent back to the requesting client.

In order to get the DoH proxy running a certificate was obtained from Let’s Encrypt using Certbot, for the domain dohtest.wisser.se used in this study. The certificate was saved at /etc/letsencrypt/live/dohtest.wisser.se/ and must be specified when starting the proxy. The following command is used for the startup:

(31)

doh-proxy --upstream-resolver=1.1.1.1 --certfile=/etc/letsencrypt/live/doht est.wisser.se/fullchain.pem --keyfile=/etc/letsencrypt/live/dohtest.wisser.

se/privkey.pem --listen-address 0.0.0.0 ::0

As soon as the proxy was up and running, requests could be sent to it.

3.3.2 DoH client

The client, in this case, a Firefox version 75.0 browser, was configured via the configuration panel “about:config”. The following three settings were modified [49].

• The “network.trr.mode” supports four values:

0 : Off. This is the default value, which means that DoH is disabled.

1 : Reserved. This used to mean that DoH is enabled and that Firefox picks eighter DOH or regular DNS based on which returns faster query responses.

2 : First. This also means that DoH is enabled, but now regular DNS only works as a backup.

3 : Only. This also means that DoH is enabled, but now regular DNS is disabled.

4 : Reserved. This used to mean that DoH is performed parallel with regular DNS, for measurements.

5 : Off by choice. This has the same meaning as ‘0’, but means that DoH is explicitly disabled.

The selected value for the attribute was number 3, this to ensure that only look-ups over HTTPS occur. The server also prints when a request takes place.

• The “network.trr.uri” attribute was set to https://dohtest.wisser.se/dns-query which is the URI of the DoH server.

• The optional “network.trr.bootstrapAddress” attribute was set to the IP address of the DoH server. This attribute works as a back-up for “network.trr.uri” if there is a problem with the domain.

A client written in Python code was also used during testing, for sending test-queries to the server. This to avoid additional queries, which makes it easier to study how the server behaves and to test the code properly before it was applied to the browser. The client was cloned from the same repository as the DoH proxy. The following command is used for starting the client:

doh-client --domain dohtest.wisser.se --remote-address ::1 --qname domain --qtype query

• "domain" is the specified domain name to lookup information for.

• "query" is the desirable record type to receive.

(32)

3.3.3 Webserver

An Apache webserver configured with a self-signed certificate was set up. The certificate was crucial to enable an HTTPS session between the client and the server. This webserver was used for one of the tests, to see if a redirect can succeed over HTTPS. The idea of including the webserver was to succeed with the following attack:

Figure 6: Interaction chart of lab environment with malicious web server.

3.4 Choice for modification of code

This section aims to explain why modification was done at the selected places in the code.

When the server has an open stream with a client there are a few states this stream can have. The goal was to modify the code at the point where the stream was ended directly afterward, this to interfere with the existing code as little as possible. The following events were found for the server, in file “proxy.py”.

• Request received: the server has received headers from a client.

• Data received: some data was received on the stream.

• Stream ended: the stream was ended and the server now can send the response.

• Connection terminated: the connection was ended and is now closed.

At the event “stream ended” the response is sent, hence it is where the code should be modified. By following the calls from this event, the following code snippet was found at row 188:

r e s p o n s e _ h e a d e r s . a p p e n d (( ’ content - l e n g t h ’ , str ( len ( body ) ) ) ) self . conn . s e n d _ h e a d e r s ( s t r e a m _ i d , r e s p o n s e _ h e a d e r s )

self . conn . s e n d _ d a t a ( s t r e a m _ i d , body , e n d _ s t r e a m = True ) self . t r a n s p o r t . w r i t e ( self . conn . d a t a _ t o _ s e n d () )

(33)

Modifications were chosen to be placed directly over this code, before the DNS response was converted to standard DNS wire format with the following: body = dnsr.to_wire().

In order to otherwise have a working look-up in the browser, modifications were made only for a specific domain name. In the following section, which describes the tests, this domain name is presented as example.se. This is to get a comprehensive review of the tests since they were done on more than one domain.

3.5 Injection tests

In this subsection the tests, which outcome have value for the study, are presented. The modifications made to carry out the attacks are presented together with the results.

The following tests aim to inject additional or modify data in a DNS response to see how the client, the web browser, handles the data. The data might be saved in the web browser’s cache memory and used for a connection. This was done by modifying the source code in the file “proxy.py”, as discussed in the previous section. The additions are listed below. During the tests, observation of the DNS cache in the Firefox client took place.

An A record is a DNS record of type ”A”, i.e. a DNS record holding an IPv4 address.

1. The IPv4 address in the DNS response was modified, with the AD-flag set. This indicates that the data is signed with DNSSEC, which is incorrect but set to trick the client into thinking that data is verified. The following code was added:

r r s e t = dns . r r s e t . f r o m _ t e x t ( ’ e x a m p l e . se . ’ , 60 , dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . A )

r d a t a = dns . r d a t a . f r o m _ t e x t ( dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . A , ’ 0 . 0 . 0 . 0 ’ )

r r s e t . add ( r d a t a ) dnsr . a n s w e r . c l e a r ()

dnsr . a n s w e r . a p p e n d ( r r s e t ) dnsr . f l a g s += dns . f l a g s . AD

Figure 7: Response when Python client requesting an A record for example.se.

(34)

When the proxy was modified in this way, the browser attempted to connect to the modified address. This only worked for connections made with HTTP connections.

The Firefox DNS cache was examined under “about:networkingdns” giving the following:

Hostname Family TRR Addresses Expires(seconds)

example.se ipv4 true 0.0.0.0 55

TRR indicated that DoH was used for DNS resolution. This test was also done without the AD-flag set, this also resulted in a successful injection. In the Firefox browser under “about:cache” the “network.stricttransportsecurity.preloadlist”

attribute was set to false, this to allow self-signed certificates. The test was then performed with the injection of the IP address of the configured web server, presented in section 3.3.3. This to see how the client manages the self-signed certificate obtained by the webserver. With these changes, the attack also worked over HTTPS. Sometimes the attacked domain name was seen in the search field when a certificate error message was presented. Why this only applied to certain domains could not be mapped.

2. An A record was added to the additional field of the DNS response, by adding the following code.

r r s e t = dns . r r s e t . f r o m _ t e x t ( ’ test . e x a m p l e . se . ’ , 60 , dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . A )

r r s e t . add ( r d a t a )

dnsr . f l a g s += dns . f l a g s . AD dnsr . a d d i t i o n a l . a p p e n d ( r r s e t )

(35)

This injection had no effect on the browser’s cache, this was confirmed by observing the browsers DNS cache at “about:networkingdns”.

3. An A record was added to the authority field of the DNS response, by adding the following code.

r r s e t = dns . r r s e t . f r o m _ t e x t ( ’ test . e x a m p l e . se . ’ , 60 , dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . A )

dnsr . f l a g s += dns . f l a g s . AD dnsr . a u t h o r i t y . a p p e n d ( r r s e t )

Figure 9: Response when Python client requesting A-post for example.se.

This injection resulted in the same outcome as the previous test, i.e. no effect on the client.

The same test with the AA-flag set was performed, indicating that the answer is from an authoritative server. Which is incorrect but set to trick the client into thinking that data is verified. This was done by adding the following line to the code snippet above:

dnsr . f l a g s += dns . f l a g s . AA

This resulted in the same outcome. Even when an A record was added that belongs to another domain, this resulted in the same outcome.

4. The response was exchanged before it was sent back to client. For this modification the “dns.query” library had to be imported. The following modifications was done:

dnsq = dns . m e s s a g e . m a k e _ q u e r y ( ’ test . e x a m p l e . se ’ , dns . r d a t a t y p e . A )

dnsr = dns . q u e r y . udp ( dnsq , ’ 1 . 1 . 1 . 1 ’ )

(36)

This resulted in the same error page as if the proxy had been inactive. Which says that “We were unable to connect to the server at example.se.”.

5. The IP-address field in the response DNS-package was modified to a private IP address. This was done with the same code as for injection number 1.

This resulted in that the private IP address was cached by the client and hence used to try to connect. Firefox DNS was examined under “about:networkingdns” giving the following:

Hostname Family TRR Addresses Expires(seconds)

example.se ipv4 true 127.0.0.1 55

(37)

6. The RCODE in the response was set to NXDOMAIN, indicating that the domain name does not exist. The authority section of the DNS response was also modified.

r r s e t = dns . r r s e t . f r o m _ t e x t ( ’ e x a m p l e . se . ’ , 60 , dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . A )

dnsr . f l a g s ^= dns . f l a g s . RA dnsr . f l a g s ^= dns . f l a g s . RD dnsr . f l a g s += dns . f l a g s . AA dnsr . a n s w e r . c l e a r ()

dnsr . s e t _ r c o d e ( dns . r c o d e . N X D O M A I N ) dnsr . a u t h o r i t y . a p p e n d ( r r s e t )

This resulted in the same error page as if the proxy had been inactive.

7. A NS record was added to the authority section of the packet and an A record was added to the additional section. This was done by adding the following code:

r r s e t = dns . r r s e t . f r o m _ t e x t ( ’ ns . e x a m p l e . se . ’ , 60 , dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . A )

r d a t a 2 = dns . r d a t a . f r o m _ t e x t ( dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . NS , ’ ns . nic . se . ’ )

r r s e t 2 = dns . r r s e t . f r o m _ t e x t ( ’ e x a m p l e . se . ’ ,60 , dns . r d a t a c l a s s . IN , dns . r d a t a t y p e . NS )

r r s e t 2 . add ( r d a t a 2 )

dnsr . f l a g s ^= dns . f l a g s . RA

(38)

dnsr . f l a g s ^= dns . f l a g s . RD dnsr . f l a g s += dns . f l a g s . AA dnsr . a n s w e r . c l e a r ()

dnsr . a d d i t i o n a l . a p p e n d ( r r s e t ) dnsr . a u t h o r i t y . a p p e n d ( r r s e t 2 )

This resulted in the same error page as if the proxy had been inactive.

3.6 Compilation of results

The following is a summary of the results of the injections above. When the Firefox client receives

• data sent in additional or authority section it is ignored

• package with a modified IP address, the browser attempted to connect to the IP address and caches it

• a completely different package than requested, the browser ignores the package and does not caches the IP address

• a package with the AD-flag set, it does not affect the browser

• a package with a modified IP address to a local IP address, the browser attempted to connect to the IP address and caches it.

(39)

ANALYSIS AND DISCUSSION | 25

4 Analysis and discussion

This chapter analyzes the result and puts it in a larger context. Economic, social, ethical, and environmental aspects will be investigated, and any consequences that the result may have on security for users. Error margins will also be explained in this chapter.

4.1 Analysis of results

The following section describes what can be interpreted by the result of the execution in the method part. The first test that was conducted was to change the IP address in the answer section of the response. This resulted in the client sometimes trying to connect to the IP address, as well as the IP address is stored in the browser’s cache.

When trying to send a private local IP address in the answer section, it was seen that this was also cached by the client. This applies to both responses sent with the AD-flag set as well as to the responses sent without the AD-flag set. AD-flag indicates, as presented in section 2.1.1, that the response is validated by DNSSEC. And it is up to the client how to use DNSSEC to verify a DNS response. Since Firefox does not implement DNSSEC, it is desirable that they verify the AD flag for a DNS response. Thus, this is recommended in RFC 8484, but this is not the case. If Firefox had followed the recommendations for implementation of DoH, injection of incorrect IP address without the AD flag set would not have been succeeded. Browsers who commit to resolve should implement some form of DNSSEC.

Initially, the test with the injection of incorrect IP address only had an effect on web pages without HTTPS extension. By changing one attribute in the about:config section in Firefox, the browser allows self-signed certificates. With this simple setting, the browser accepted incorrect IP addresses over HTTPS. The attribute, as later discussed in section 4.3, may be set by malware. The only thing required for the connection to succeed is that the user accepts the self-signed certificate. Since many just want the lookup to work, and the fact that many are not aware of security risks on the Internet, it is likely that the majority will accept this certificate and the connection will succeed. In the attack against Myetherwallet, presented in section 2.7.4, users with HTTPS connection had to accept a certificate error message. Which obviously many did, due to the fact that the attack generated a total of 179 traceable transactions and keep in mind that only a few resolvers around the world were infected. As seen in the test with the injection of incorrect IP address, the correct URL on a few occasions remained in the browsers search bar when the certificate error site occurs. This even though the user was connected to the wrong web server. This can deceive many users if the browser is complaining about a certificate error, but the URL is still correct.

As earlier mentioned, one of the problems that occur when using DoH is that the traffic is camouflaged with other encrypted HTTPS traffic. For example, an incorrectly resolved query returned to the user is then very difficult to detect. And this is a huge difference compared to earlier when DNS had a standard port 53 only for DNS-traffic, but also was sent in clear-text. This means that lists of known malicious websites are not applicable to

(40)

26 | ANALYSIS AND DISCUSSION

the local firewall when using DoH.

4.2 Conclusion of the goal

At the beginning of the report, three main goals were presented, these were as follows:

• 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.

For the protocol, none unknown vulnerabilities were found, however, it was seen that the vulnerabilities that exist are not highlighted by the actors that have chosen to implement the protocol. DoH protects against the following known DNS vulnerabilities:

• A traditional man-in-the-middle interaction attack where DNS responses are modified along the path between client and resolver is prevented because the channel is encrypted. However, the path between a resolver and nameserver is not encrypted and DNSSEC should be applied to verify responses.

• Eavesdropping, also a man-in-the-middle interception attack but the attacker only listens to the traffic and does not interact.

• The user can secure the identity of their resolver.

In the tests performed in this study, data that has not been requested is ignored by the DoH client, in this case the Firefox browser. However, the requested data is not verified with DNSSEC. The client caches and connects to a modified IP address for a requested domain name, as discussed in the previous section. Further tests regarding none requested data will be discussed later in section 5.1.

4.3 Consequences

The attacks presented under the method section of this paper are only one step that completes an attack. Successfully redirecting the user to the wrong web server is vital for some attacks. In order to get the user to leave information, the user must believe that the page can be trusted. As earlier mentioned, the DNS part of a complete attack has already succeeded when the browser attempts to connect to the wrong web server.

Although it seems like a non-existent risk that a user accidentally sets a malicious DoH server as default. There is a risk that a malicious software gaining access to a user’s computer can make these changes in the settings. This could in theory be a malware spread by downloading a file, via a USB-stick or clicking a link in an email. During one of the tests in this report a setting that allows self-signed certificates where activated. This

(41)

ANALYSIS AND DISCUSSION | 27

resulted in a successful redirection of a requested HTTPS site to the webserver used in the lab environment. This can be very difficult to detect for a regular user. Most often, only certain domains are affected and modified, which means that other resolving works as usual. Since the DoH traffic is camouflaged with other HTTPS traffic, it might be harder to detect malicious software for intrusion detection systems or similar.

By returning an incorrect IP address, many dangerous attacks can be made. The reason why they are extra dangerous is that the attack can be performed when the user is browsing as usual and not when downloading a suspect file or click on a link in an email. It is a situation that otherwise seems harmless. This makes it even more difficult to detect. When users are searching for a website that they often visit it is difficult, sometimes impossible, for the user to detect that the page returned is not authentic. The page can sometimes be very similar to the original. Therefore, it is a very dangerous attack that can result in users giving away sensitive data, like credit card details or similar. In one of the tests where an incorrect IP address was returned to the browser, you could see that the correct URL was displayed in the URL field, while the user was connected to the wrong web server. The padlock could also be seen, indicating an encrypted connection.

Traditional attacks were using Dynamic Host Configuration Protocol (DHCP) to set default DNS resolver may become a threat for DoH in the future. If support for using DoH as a system resolver implemented in the operating system that might also be a risk for DoH.

The attack against Myetherwallet is a typical attack that uses DNS to redirect traffic to malicious pages. Like the attack presented above, users had to accept a self-signed certificate to continue and unfortunately, it is not unusual for users to do so. The attack is an example of the consequences that may occur when redirecting IP addresses to malicious web servers. The attack cost was $ 150 000 and would not have succeeded if users had been more aware of their Internet use.

As mentioned in section 2.5.2, DoH could make it difficult for enterprises to implement split-horizon DNS, which makes it important for those to disable DoH when the protocol becomes a standard for the browser used by the enterprise. This does only apply to those who use Firefox and those that uses internal domain names that can be resolved publicly as well.

4.4 Error margins

This subsection will focus on pointing out potential error margins in the execution of the study, due to time constraints, as well as how these could be eliminated.

The study only covers tests on Firefox. It would have been desirable to test the protocol DoH on more clients, such as Chrome, to get a more overall result. However, since this has no effect on the protocol’s function, this is not a margin of error that affected the results.

The tests were also performed only on a few domains because it was not considered to have a significant impact on the result. It was therefore chosen not to waste time on further investigations on more domains.

During the test when an A record was added to the authority section, different results

(42)

28 | ANALYSIS AND DISCUSSION

were seen. The first time the attack was tested, Firefox seemed to store the IP address in the cache. Because this address could be used for lookup when the proxy was turned off.

And since the browser was configured not to use regular DNS as a fallback, this proved that the IP address for the domain name was fetched from the cache memory. Later in the execution when the same attack was tested again, the browser did not cache the IP address added in the authority section. The reason why the attack worked the first time and not later in the execution could not be found, and hence it was chosen to present the attack with the latter result.

Cloudflare’s resolver is used for all tests in this study, performing the tests on other actors had produced the same result and was therefore not considered necessary. The resolver is only used to generate a DNS response which is then modified, and has no crucial role in the attack. This DNS response could as well have been created from scratch.

At the start of the study, there was no knowledge of the program language Python in the group. However, the group had programming experience in similar object-oriented languages like Java and C. This resulted in a great deal of time spent studying the language Python and that some errors or poor choice of solutions in the own written code may occur.

There is therefore room for further development of the ideas raised in the study and further testing on these. Studies could also have been made on the source code of the client, to try to understand its behavior, but such time was not available.

Only a few domains where tested when performing the “injection tests” in the method part of this study. The only variation in results when testing different domains that could be found was regarding the certificates that were used by the different web servers. As managing certificates is another part of a completed attack, the focus was not on studying variances in certificates. An attack/test was considered successful already when the browser tried to connect to the wrong web server, even if a warning/error page was shown. And no reason could be found for the fact that the web browser’s attempts to connect would differ for different domains.

4.5 Economic, social, ethical and environmental aspects

In this section economic, social, and ethical aspects will be discussed. The study has no impact on the environment, and therefore this aspect will not be discussed.

There are ideas that DoH will centralize DNS data to a few “public” resolvers. This means that they have a great deal of power in the market when it comes to data from users that are valuable for advertising or similar. This has also become a discussion about ownership, who owns the data? What kind of data do they collect and does it compromise the user’s privacy and can we trust these public resolvers? From an economic point of view, there is a lot of money behind the data regarding users’ Internet use. Firefox has chosen to partner with Cloudflare and NextDNS, two American companies. The user’s data is thus sent to a country that does not have the same responsibility against GDPR as EU countries, if the users are browsing within the country. For users in a country that is member of EU, it might feel safe to use one’s current ISP and still be protected by GDPR rather than to enable DoH in Firefox.