DOCSLIB.ORG

Bachelor Thesis Computing Science

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Bachelor Thesis Computing Science Bachelor thesis Computing Science Radboud University Performance comparison of DNS over HTTPS to unencrypted DNS Author: First supervisor/assessor: Jeroen Wijenbergh Dr. Veelasha Moonsamy s4792459 [email protected] Daily supervisor: Dr. Roland van Rijsdijk-Deij [email protected] Second assessor: ir. D.W.C. Dani¨elKuijsters [email protected] October 3, 2019 Abstract To encrypt DNS, DNS over HTTPS has been proposed. This protocol has additional overhead that can not be found in DNS over UDP. In this study, we will analyze the performance impact of this extra overhead. To do this, we have extended the established DNS measurement tool Flamethrower with DNS over HTTPS capability. This imple- mentation is used to query a server that we have set up. This server runs Dnsdist and Unbound to provide DNS and DNS over HTTPS on a single host. We will query two of these servers with a different number of concurrent TCP and HTTP/2 streams and analyze the results. These results will help us in answering what performance impact DNS over HTTPS has as compared to unencrypted DNS. The results that we will obtain in this research is that for all of our tests DNS over HTTPS has worse performance as compared to UDP. The performance difference is less noticeable when caching is disabled. Contents 1 Introduction 4 1.1 Motivation . .5 1.2 Overview of thesis . .6 2 Preliminaries 7 2.1 Network Stack . .7 2.1.1 Application layer . .8 2.1.2 Transport layer . .8 2.1.3 Network layer . .8 2.1.4 Data Link layer . .8 2.1.5 Physical layer . .9 2.1.6 Layer encapsulation/decapsulation . .9 2.1.6.1 Importance of encapsulation/decapsulation . .9 2.2 Transport layer protocols . .9 2.2.1 Transmission Control Protocol (TCP) . 10 2.2.1.1 Structure . 10 2.2.1.2 Handshake . 12 2.2.1.3 Message exchange . 12 2.2.1.4 Positives and drawbacks . 13 2.2.2 User Datagram Protocol (UDP) . 13 2.2.2.1 Structure . 13 2.2.2.2 Differences between UDP and TCP . 14 2.3 Application Layer protocols . 14 2.3.1 Hypertext Transfer Protocol (HTTP) . 14 2.3.1.1 Structure . 15 2.3.1.2 Encryption . 16 2.3.1.3 HTTP standards . 16 2.3.2 Transport Layer Security (TLS) . 16 2.3.2.1 Goals of TLS . 16 2.3.2.2 Encryption . 17 2.3.2.3 Authentication . 17 2.4 DNS . 19 1 2.4.1 Distributed system . 19 2.4.1.1 Stub resolver . 19 2.4.1.2 Recursive resolver . 20 2.4.1.3 Authoritative servers . 20 2.4.2 Structure . 20 2.4.3 Recent work in encrypting DNS . 24 2.4.3.1 DNS over HTTPS (DoH) . 24 3 Research 28 3.1 Scope . 28 3.2 Methodology . 29 3.2.1 Software . 29 3.2.1.1 Client . 29 3.2.1.2 Resolver . 40 3.2.2 Hardware . 44 3.2.2.1 Client . 44 3.2.2.2 Server . 44 3.2.3 Performance measurement . 45 3.2.3.1 Dataset . 45 3.2.3.2 Tests . 45 3.2.3.3 Running the tests . 46 3.2.3.4 Analyzing the output . 48 3.2.3.5 Overview . 49 3.3 Results . 50 3.3.1 TCP connection delay . 50 3.3.1.1 Caching enabled . 50 3.3.1.2 Caching disabled . 51 3.3.2 TLS connection delay . 51 3.3.2.1 Caching enabled . 52 3.3.2.2 Caching disabled . 53 3.3.3 Round-trip time of DNS and DoH . 53 3.3.3.1 Caching enabled . 54 3.3.3.2 Caching disabled . 59 3.4 Reflecting on the results and limitations . 65 4 Related Work 66 4.1 DNS Caching . 66 4.2 Mozilla DoH measurements . 67 4.3 DNS, DoT and DoH page load time and resolution times . 68 4.4 Methodology for testing DNS in a lab environment . 69 5 Conclusions 70 5.1 Future work . 70 2 Bibliography 71 A Appendix 75 A.1 TCP connection delay measurements . 76 A.1.1 Caching enabled . 76 A.1.2 Caching disabled . 78 A.2 TLS connection delay measurements . 80 A.2.1 Caching enabled . 80 A.2.2 Caching disabled . 81 A.3 Round-trip time measurements . 82 A.3.1 Caching enabled . 82 A.3.2 Caching disabled . 88 3 Chapter 1 Introduction When you want to visit a website on the internet, your browser needs to know the IP address of that website. These IP addresses are hard to remember. To address this prob- lem, two researchers (Paul Mockapetris and Jon Postel) introduced the Domain Name System (DNS). This architecture maps hostnames (e.g. google.com) to an IP address (e.g. 216.58.211.110 ), which makes it so that you only have to enter the hostname into your browser to gain access to the website. This is the main benefit of DNS, but there are more; an important one is that DNS also allows a website to easily transfer their hostname to another server by changing the DNS settings. Furthermore, while we gave the example of using DNS to obtain the IP address for a website, DNS is also used for email. The DNS architecture was introduced in 1983 [41] [43] and has seen little change since then. As a result, this architecture has a few problems. One of these problems is that the DNS messages are unencrypted. To add encryption to DNS, extensions have been proposed, for example: • DNS over HTTPS (DoH) [35] • DNS over TLS (DoT) [38] • DNSCURVE [16] • DNSCrypt [4] In this thesis, we want to focus on the DNS over HTTPS protocol and how it compares to regular DNS. The reason why we chose to study this protocol will be discussed in section 1.1. As the title of this thesis already suggests, we want to explicitly focus on the per- formance impact of using DNS over HTTPS. What we exactly mean with performance will be discussed in chapter 3. 4 The following will be our research question: How much performance impact does DNS over HTTPS have as compared to using unencrypted DNS? We also have the following sub-research questions: • How do the HTTP methods POST and GET compare with regards to perfor- mance? • To what extent do TCP connections impact the performance of DNS over HTTPS? • To what extent do HTTP/2 streams impact the performance of DNS over HTTPS? • To what extent does caching impact the performance of DNS over HTTPS? To get help with this thesis, we have interned at the NLnet Labs foundation. They helped us with deciding on a scope for this thesis. This scope will be defined in section 3.1 and there we will discuss our research questions in more detail. The methodology we used for testing this performance has also been discussed with NLnet Labs and can be found in section 3.2. To get a better idea of why we chose to research this topic, we will now discuss our motivation. 1.1 Motivation As stated before, DNS messages are still unencrypted. To understand why this is a problem, we need to look at a possible attack scenario. DNS messages (on top of the hostname) provide information about the client that is sending the message (e.g. your browser). A third-party that listens for traffic between you and the DNS server can see any DNS message. This means that this third-party can see what websites you are visiting on the internet. This problem not only exists in theory, it is actively abused in practice [34]. When you encrypt these DNS messages, the content of them can not be seen by parties that are not involved in the DNS hierarchy. This includes eavesdroppers on a network. One of the most popular and newest protocols to achieve this encryption is the DNS over HTTPS protocol. The protocol was first published in May 2017 [36], and was subse- quently standardized by the Internet Engineering Task Force in August 2018 [35]. Even though this protocol is new, it is already being used in the DNS resolvers from Cloud- flare [26] and Google [33]. Firefox, a popular internet browser, is also testing DNS over HTTPS support [44] [45] [46]. Because the adoption of this protocol moves quicker than the other protocols that were mentioned (DNS over TLS, DNSCURVE, DNSCrypt), we have decided to focus this thesis on this protocol. Due to the recency of this protocol, we must investigate if it can replace unencrypted DNS. To achieve this, as we have pre- 5 viously alluded to in our research questions, we will investigate the performance of DNS over HTTPS as compared to unencrypted DNS. See the next subsection for an overview of the thesis. 1.2 Overview of thesis In this thesis, we will first describe the different topics that are needed to follow this thesis. This is defined in the Preliminaries section (chapter 2). After this we will describe our Research and the results (chapter 3). We will also discuss Related Work (chapter 4) and finally give a Conclusion (chapter 5). 6 Chapter 2 Preliminaries In this section we will give a brief overview of the preliminaries that are needed to read this thesis. We will first give a broad overview of the network stack. Understanding this network stack helps in understanding the basics of networking. After this, we will go into more detail of the protocols that are important to know. At last, we will describe DNS and DNS encryption.
Load more

Recommended publications
  • Uila Supported Apps
    Uila Supported Applications and Protocols updated Oct 2020 Application/Protocol Name Full Description 01net.com 01net website, a French high-tech news site. 050 plus is a Japanese embedded smartphone application dedicated to 050 plus audio-conferencing. 0zz0.com 0zz0 is an online solution to store, send and share files 10050.net China Railcom group web portal. This protocol plug-in classifies the http traffic to the host 10086.cn. It also 10086.cn classifies the ssl traffic to the Common Name 10086.cn. 104.com Web site dedicated to job research. 1111.com.tw Website dedicated to job research in Taiwan. 114la.com Chinese web portal operated by YLMF Computer Technology Co. Chinese cloud storing system of the 115 website. It is operated by YLMF 115.com Computer Technology Co. 118114.cn Chinese booking and reservation portal. 11st.co.kr Korean shopping website 11st. It is operated by SK Planet Co. 1337x.org Bittorrent tracker search engine 139mail 139mail is a chinese webmail powered by China Mobile. 15min.lt Lithuanian news portal Chinese web portal 163. It is operated by NetEase, a company which 163.com pioneered the development of Internet in China. 17173.com Website distributing Chinese games. 17u.com Chinese online travel booking website. 20 minutes is a free, daily newspaper available in France, Spain and 20minutes Switzerland. This plugin classifies websites. 24h.com.vn Vietnamese news portal 24ora.com Aruban news portal 24sata.hr Croatian news portal 24SevenOffice 24SevenOffice is a web-based Enterprise resource planning (ERP) systems. 24ur.com Slovenian news portal 2ch.net Japanese adult videos web site 2Shared 2shared is an online space for sharing and storage.
    [Show full text]
  • Privacy in the Domain Name System (DNS): DNS Privacy in Practice
    Privacy in the Domain Name System (DNS): DNS Privacy in Practice Sara Dickinson [email protected] https://sinodun.com @SinodunCom TMA Jun 2019 DNS Privacy https://github.com/Sinodun/tma_phd_school Overview • First - lets look at your DNS queries! • Desktop DoT stub resolvers (client) (Stubby) • Set up your own DoT recursive (Unbound) - decrypt DoT • DoH - Clients & Browsers (Firefox) - decrypt DoH Firefox DoH Decryption is • Mobile Apps easier…. • DNS Libraries (getdns) • Routers TMA, Jun 2019 2 DNS Privacy dnsprivacy.org • DNS Privacy Clients • DNS Privacy Servers setup guides Reference material here • DNS Privacy Test and Public resolvers for most setups and recursive resolvers • DNS Privacy Monitoring • DNS Privacy Current work TMA, Jun 2019 3 DNS Privacy DNS Basics TMA, Jun 2019 4 DNS Privacy DNS Basics - A UDP query ‘dig’ is available on most *nix systems (or ‘drill’) TMA, Jun 2019 5 DNS Privacy DNS Basics - A UDP query ‘dig’ is available on most *nix systems (or ‘drill’) TMA, Jun 2019 5 DNS Privacy DNS Basics - A UDP query ‘dig’ is available on most *nix systems (or ‘drill’) TMA, Jun 2019 5 DNS Privacy DNS Basics - A UDP query ‘dig’ is available on most *nix systems (or ‘drill’) TMA, Jun 2019 5 DNS Privacy DNS Basics - A UDP query ‘dig’ is available on most *nix systems (or ‘drill’) TMA, Jun 2019 5 DNS Privacy DNS Basics - A UDP query ‘dig’ is available on most *nix systems (or ‘drill’) TMA, Jun 2019 5 DNS Privacy DNS Basics - A UDP query ‘nslookup’ is available on Windows order is important! TMA, Jun 2019 6 DNS Privacy DNS Basics
    [Show full text]
  • M3AAWG Tutorial on Third Party Recursive Resolvers and Encrypting DNS Stub Resolver-To-Recursive Resolver Traffic Version 1.0 September 2019
    Messaging, Malware and Mobile Anti-Abuse Working Group M3AAWG Tutorial on Third Party Recursive Resolvers and Encrypting DNS Stub Resolver-to-Recursive Resolver Traffic Version 1.0 September 2019 The direct URL to this paper is: www.m3aawg.org/dns-crypto-tutorial Document 1 of 2: This document is intended to be accompanied by the paper “M3AAWG Companion Document: Recipes for Encrypting DNS Stub Resolver-to-Recursive Resolver Traffic (www.m3aawg.org/dns-crypto-recipes),” which provides detailed instructions and processes. This document was produced by the M3AAWG Data and Identity Protection Committee. Table of Content Executive Summary 3 Introduction 4 Recommendations for M3AAWG and Its Audiences 7 I. Is the Use of Alternative Third Party Recursive Resolvers and Encryption of Stub Resolver-to- Recursive Resolver Traffic “In-Scope" for M3AAWG Remit? 9 1. DNS Is an Operationally Critical Core Internet Protocol 9 2. DNS and Messaging/Anti-Abuse Work 9 3. User Privacy and Opposition to Pervasive Monitoring 10 4. M3AAWG Membership – Many M3AAWG Members Have a Keen Interest in This Topic 10 II. Recursive Resolvers (Default ISP, Third Party Alternatives and Dedicated Personal Recursive Resolvers) 11 5. How Do Recursive Resolvers Normally Work in an ISP Environment Today? 11 6. A Typical Day in a Typical User's Life Online: Many Different Internet Service Providers, Many Different Recursive Resolvers 12 7. How Can I Even Tell What Name Servers I Am Actually Using Right Now?" 13 8. Intentionally Configuring an Alternative Third Party Recursive Resolver 15 9. Well-Known Third Party Recursive Resolver Providers 16 10. Picking the Right Third Party Recursive Resolver Service 17 11.
    [Show full text]
  • Adopting Encrypted DNS in Enterprise Environments
    National Security Agency | Cybersecurity Information Adopting Encrypted DNS in Enterprise Environments Executive summary Use of the Internet relies on translating domain names (like “nsa.gov”) to Internet Protocol addresses. This is the job of the Domain Name System (DNS). In the past, DNS lookups were generally unencrypted, since they have to be handled by the network to direct traffic to the right locations. DNS over Hypertext Transfer Protocol over Transport Layer Security (HTTPS), often referred to as DNS over HTTPS (DoH), encrypts DNS requests by using HTTPS to provide privacy, integrity, and “last mile” source authentication with a client’s DNS resolver. It is useful to prevent eavesdropping and manipulation of DNS traffic. While DoH can help protect the privacy of DNS requests and the integrity of responses, enterprises that use DoH will lose some of the control needed to govern DNS usage within their networks unless they allow only their chosen DoH resolver to be used. Enterprise DNS controls can prevent numerous threat techniques used by cyber threat actors for initial access, command and control, and exfiltration. Using DoH with external resolvers can be good for home or mobile users and networks that do not use DNS security controls. For enterprise networks, however, NSA recommends using only designated enterprise DNS resolvers in order to properly leverage essential enterprise cybersecurity defenses, facilitate access to local network resources, and protect internal network information. The enterprise DNS resolver may be either an enterprise-operated DNS server or an externally hosted service. Either way, the enterprise resolver should support encrypted DNS requests, such as DoH, for local privacy and integrity protections, but all other encrypted DNS resolvers should be disabled and blocked.
    [Show full text]
  • Technical Impacts of DNS Privacy and Security on Network Service Scenarios
    - Technical Impacts of DNS Privacy and Security on Network Service Scenarios ATIS-I-0000079 | April 2020 Abstract The domain name system (DNS) is a key network function used to resolve domain names (e.g., atis.org) into routable addresses and other data. Most DNS signalling today is sent using protocols that do not support security provisions (e.g., cryptographic confidentiality protection and integrity protection). This may create privacy and security risks for users due to on-path nodes being able to read or modify DNS signalling. In response to these concerns, particularly for DNS privacy, new protocols have been specified that implement cryptographic DNS security. Support for these protocols is being rapidly introduced in client software (particularly web browsers) and in some DNS servers. The implementation of DNS security protocols can have a range of positive benefits, but it can also conflict with important network services that are currently widely implemented based on DNS. These services include techniques to mitigate malware and to fulfill legal obligations placed on network operators. This report describes the technical impacts of DNS security protocols in a range of network scenarios. This analysis is used to derive recommendations for deploying DNS security protocols and for further industry collaboration. The aim of these recommendations is to maximize the benefits of DNS security support while reducing problem areas. Foreword As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industry’s business priorities. ATIS’ 150 member companies are currently working to address network reliability, 5G, robocall mitigation, smart cities, artificial intelligence-enabled networks, distributed ledger/blockchain technology, cybersecurity, IoT, emergency services, quality of service, billing support, operations and much more.
    [Show full text]
  • The ISP Column Diving Into The
    The ISP Column A column on various things Internet October 2018 Geoff Huston Diving into the DNS DNS OARC organizes two meetings a year. They are two-day meetings with a concentrated dose of DNS esoterica. Here’s what I took away from the recent 29th meeting of OARC, held in Amsterdam in mid-October 2018. Cloudflare's 1.1.1.1 service Cloudflare have been running an open public DNS resolver service on 1.1.1.1 for more than six months now. The service, based on the Knot resolver engine, is certainly fast (http://bit.ly/2PBfoSh), and Cloudflare's attention to scale and speed is probably appreciated by users of this service. However, in a broader Internet environment that is now very aware of personal privacy it’s not enough to be fast and accurate. You have to be clear that as an operator of a public DNS resolution service you may be privy to clients’ activities and interests, and you need to clearly demonstrate that you are paying attention to privacy. Not only does this include appropriate undertakings regarding the way you handle and dispose of the logs of the resolvers' query streams, but also in being mindful of the way that users can pass queries to the service. The 1.1.1.1 service supports DNS over TLS 1.3 and 1.2 using the GnuTLS system. This supports long-lived connection with client systems and also supports session resumption. There are a number of DNS tools that can use the DNS over a TLS connection including kdig (http://bit.ly/2A9f9rX, http://bit.ly/2OoLu7a), GetDNS (https://getdnsapi.net/), Unbound (http://bit.ly/2CIKEf0), Android P and the Tenta browser (https://tenta.com/).
    [Show full text]
  • Unbound: a New Secure and High Performance Open Source DNS Server
    New Open Source DNS Server Released Today Unbound – A Secure, High-Performance Alternative to BIND – Makes its Debut within Open Source Community Amsterdam, The Netherlands and Mountain View, CA – May 20, 2008 – Unbound – a new open source alternative to the BIND domain name system (DNS) server– makes its worldwide debut today with the worldwide public release of Unbound 1.0 at http://unbound.net. Released to open source developers by NLnet Labs, VeriSign, Inc. (NASDAQ: VRSN), Nominet, and Kirei, Unbound is a validating, recursive, and caching DNS server designed as a high- performance alternative for BIND (Berkeley Internet Name Domain). Unbound will be supported by NLnet Labs. An essential component of the Internet, the DNS ties domain names (such as www.verisign.com) to the IP addresses and other information that Web browsers need to access and interact with specific sites. Though it is unknown to the vast majority of Web users, DNS is at the heart of a range of Internet-based services beyond Web browsing, including email, messaging and Voice Over Internet Protocol (VOIP) telecommunications. Although BIND has been the de facto choice for DNS servers since the 1980s, a desire to seek an alternative server that excels in security, performance and ease of use prompted an effort to develop an open source DNS implementation. Unbound is the result of that effort. Mostly deployed by ISPs and enterprise users, Unbound will also be available for embedding in customer devices, such as dedicated DNS appliances and ADSL modems. By making Unbound code available to open source developers, its originators hope to enable rapid development of features that have not traditionally been associated with DNS.
    [Show full text]
  • Mullvad DNS Over HTTPS Server Audit
    Report Mullvad DNS over HTTPS server audit Wictor Olsson, Emilie Barse, Benjamin Svensson, Johanna Abrahamsson Project Version Date MUL001 v1.0 2021-02-23 REPORT Project Version MUL001 v1.0 Date 2021-02-23 Executive summary Assured was tasked to perform a whitebox system audit of Mullvads DNS over HTTPS servers. The audit focused on configuration in regards to privacy, attack sur- face reduction and security best practices. The server deployment and config- uration displayed a good level of security in general. At the time of the au- dit, the exposed services were running at a good patch level, with no known vul- nerabilities. The most notable findings during the audit was related to a mis- configuration of the DNS service (Unbound), NTP service and iptables egress/ingress configuration, these issues were promptly resolved by the Mullvad team and ver- ified during the audit period. i REPORT Project Version MUL001 v1.0 Date 2021-02-23 Contents 1 Introduction 1 1.1 Background . 1 1.2 Constraints and disclaimer . 1 1.3 Project period and staffing . 1 1.4 Risk rating . 2 2 Scope and methodology 3 2.1 Scope . 3 2.1.1 Audit of Mullvad DNS over HTTPS servers . 3 2.2 Methodology . 3 2.2.1 System audit . 3 2.3 Limitations . 4 3 Observations 5 3.1 Mullvad DNS over HTTPS servers . 5 3.1.1 Low MITIGATED Unbound listening socket misconfigu- ration ......................... 5 3.1.2 Low FIXED Iptables should be more restrictive .. 6 3.1.3 Note FIXED Ntpd listening on all interfaces .... 7 3.1.4 Note Apparmor for exposed services .
    [Show full text]
  • Ikev2 Configuration for Encrypted DNS
    IKEv2 Configuration for Encrypted DNS draft-btw-add-ipsecme-ike Mohamed Boucadair (Orange) Tirumaleswar Reddy (McAfee, Inc.) Dan Wing (Citrix Systems, Inc.) Valery Smyslov (ELVIS-PLUS) July 2020, IETF#108 Agenda • Context • A Sample Use Case • IKE Configuration Attribute for Encrypted DNS • Next Steps 2 Problem Description • Several schemes to encrypt DNS have been specified – DNS over TLS (RFC 7858) – DNS over DTLS (RFC 8094) – DNS over HTTPS (RFC 8484) • …And others are being specified: – DNS over QUIC (draft-ietf-dprive-dnsoquic) • How to securely provision clients to use Encrypted DNS? This use can be within or outside the IPsec tunnel 3 A Sample Use Case: DNS Offload • VPN service providers can offer publicly accessible Encrypted DNS – the split-tunnel VPN configuration allows the client to access the DoH/DoT servers hosted by the VPN provider without traversing the tunnel 4 A Sample Use Case: Protecting Internal DNS Traffic • DoH/DoT ensures DNS traffic is not susceptible to internal attacks – see draft-arkko-farrell-arch-model-t-03#section-3.2.1 • encrypted DNS can benefit to Roaming Enterprise users to enhance privacy – With DoH/DoT the visibility of DNS traffic is limited to only the parties authorized to act on the traffic (“Zero Trust Architecture”) 5 Using IKE to Configure Encrypted DNS on Clients • New configuration attribute INTERNAL_ENC_DNS is defined to convey encrypted DNS information to clients: – Encrypted DNS type (e.g., DoH/DoT) – Scope of encrypted DNS use – One or more encrypted DNS server IPv6 addresses • For IPv4
    [Show full text]
  • Paper, We Note That Work Is with Help from Volunteer OONI Probe Users
    Measuring DoT/DoH Blocking Using OONI Probe: a Preliminary Study Simone Basso Open Observatory of Network Interference [email protected] Abstract—We designed DNSCheck, an active network exper- delivery networks (CDN). This fact raises concerns regarding iment to detect the blocking of DoT/DoH services. We imple- performance [25], competition, and privacy [14]. mented DNSCheck into OONI Probe, the network-interference (While DoH’s centralization and the resulting privacy con- measurement tool we develop since 2012. We compiled a list of popular DoT/DoH services and ran DNSCheck measurements cerns are not the focus of this paper, we note that work is with help from volunteer OONI Probe users. We present pre- underway to mitigate them [38] [24].) liminary results from measurements in Kazakhstan (AS48716), Simultaneously, the rollout of DoT and DoH does not Iran (AS197207), and China (AS45090). We tested 123 DoT/DoH fully solve the surveillance and censorship issues posed by services, corresponding to 461 TCP/QUIC endpoints. We found a cleartext internet. There are at least two remaining fields endpoints to fail or succeed consistently. In AS197207 (Iran), 50% of the DoT endpoints seem blocked. Otherwise, we found that could reveal the precise target of otherwise encrypted that more than 80% of the tested endpoints were always reach- communications. They are the Server Name Indication [19] able. The most frequently blocked services are Cloudflare’s and (SNI) extension inside the TLS ClientHello and the destination Google’s. In most cases, attempting to reach blocked endpoints IP address. However, in a landscape increasingly dominated by failed with a timeout.
    [Show full text]
  • The Impact of Time on DNS Security
    The Impact of Time on DNS Security Aanchal Malhotray, Willem Tooropz, Benno Overeinderz, Ralph Dolmansz and Sharon Goldbergy Boston Universityy, NLnet Labs, Amsterdamz [email protected], fwillem, benno, [email protected], [email protected] July 5, 2019 Abstract Time is an important component of the Domain Name System (DNS) and the DNS Security Extensions (DNSSEC). DNS caches rely on an absolute notion of time (e.g., “August 8, 2018 at 11:59pm”) to determine how long DNS records can be cached (i.e., their Time To Live (TTL)) and to determine the validity interval of DNSSEC signatures. This is especially interesting for two reasons. First, absolute time is set from external sources, and is thus vulnerable to a variety of network attacks that maliciously alter time. Meanwhile, relative time (e.g., “2 hours from the time the DNS query was sent”) can be set using sources internal to the operating system, and is thus not vulnerable to network attacks. Second, the DNS on-the-wire protocol only uses relative time; relative time is then translated into absolute time as a part of DNS caching, which introduces vulnerabilities. We leverage these two observations to show how to pivot from network attacks on absolute time to attacks on DNS caching. Specifically, we present and discuss the implications of attacks that (1) expire the cache earlier than intended and (2) make the cached responses stick in the cache longer than intended. We use network measurements to identify a significant attack surface for these DNS cache attacks, focusing specifically on pivots from Network Time Protocol (NTP) attacks by both on-path and off-path attackers.
    [Show full text]
  • A Cybersecurity Terminarch: Use It Before We Lose It
    SYSTEMS ATTACKS AND DEFENSES Editors: Davide Balzarotti, [email protected] | William Enck, [email protected] | Samuel King, [email protected] | Angelos Stavrou, [email protected] A Cybersecurity Terminarch: Use It Before We Lose It Eric Osterweil | George Mason University term · in · arch e /’ t re m , närk/ noun an individual that is the last of its species or subspecies. Once the terminarch dies, the species becomes extinct. hy can’t we send encrypt- in the Internet have a long history W ed email (secure, private of failure. correspondence that even our mail To date, there has only been one providers can’t read)? Why do our success story, and, fortunately, it is health-care providers require us to still operating. Today, almost ev- use secure portals to correspond erything we do online begins with a with us instead of directly emailing query to a single-rooted hierarchical us? Why are messaging apps the global database, whose namespace only way to send encrypted messag- is collision-free, and which we have es directly to friends, and why can’t relied on for more than 30 years: we send private messages without the Domain Name System (DNS). user-facing) layer(s). This has left the agreeing to using a single platform Moreover, although the DNS pro- potential to extend DNSSEC’s verifi- (WhatsApp, Signal, and so on)? Our tocol did not initially have verifica- cation protections largely untapped. cybersecurity tools have not evolved tion protections, it does now: the Moreover, the model we are using to offer these services, but why? DNS Security Extensions (DNS- exposes systemic vulnerabilities.
    [Show full text]