DNS Privacy: Concerns, Issues and Technologies

Total Page:16

File Type:pdf, Size:1020Kb

DNS Privacy: Concerns, Issues and Technologies DNS Privacy: Concerns, Issues and Technologies David Roth, John Worley, Jose Castejon-Amenedo, Ian Cohee Secure64 Software The Domain Name Service (DNS) is the critical Internet service, without which the modern Internet and the information economy would not exist. It is a public, distributed, highly-redundant, highly-scalable distributed database of translations between domain names, e.g., www.google.com, and the information needed to access resources and services, such as web pages, mail servers, files, time of day, etc. The most common and familiar function is mapping a domain name to an IPv4 or IPv6 address. The mapping is required in order for an application to open a network connection to a remote service. For example, when www.google.com is typed into a browser, the domain name portion of the URL is submitted to the system’s resolver library, which in turn initiates a domain name lookup to the system’s configured DNS server, usually an external caching recursive resolver configured by the network provider. The web browser then awaits a valid response containing the IP address to connect to the web site over HTTP or HTTP/S. Critical system applications such as NTP function in a similar manner. DNS Privacy The domain name system is considered public knowledge and as such DNS queries and responses are sent over the network in the clear. Because DNS data is unencrypted, it is easily collected. Of particular interest is who sent the query and what domain they are visiting. This information may be used to compile end user profiles, which in turn may be used for targeted advertising, or competitive analysis1. While DNS data does not reveal the full extent of a user’s activities, it does provide valuable metadata for big- data analysis. To address DNS privacy issues, there are a number of active initiatives to secure DNS requests on the wire, led by dnsprivacy.org and within the IETF. This paper provides a detailed look at the problem space, emerging standards, and services available today to protect client DNS privacy. In particular we’ll cover the IETF standards for DNS over HTTPS (hereafter DoH) and DNS over TLS (hereafter DoT). The focus will be on stub-to-resolver privacy issues. These approaches to DNS privacy build upon the use of TCP and cryptographic protocols. Security and Privacy In many discussions about DNS, the terms security and privacy are used interchangeably; however, they have very different meanings and distinct implications. Privacy only means that the contents of a DNS query cannot be viewed in transit by a third party, often referred to as a “man in the middle”, or MITM. One simple mechanism to ensure privacy would be to have a point-to-point connection between the client and the recursive server. In the Internet environment, where packets will traverse many hops (routers, proxies, etc.) between the client and server, privacy requires some form of encryption. 11POWERDNS Technical Blog, “On Firefox moving DNS to a third party”., https://blog.powerdns.com/2018/09/04/on- firefox-moving-dns-to-a-third-party/. 1 Security, on the other hand, is composed of three different attributes, each of which may be independently present. Privacy is one attribute, but security also includes: ⚫ Authentication, a process by which a client knows, with a high degree of certainty, it is communicating with the expected server, and ⚫ Data Integrity, a process by which the client knows, with a high degree of certainty, data sent and received cannot be altered or changed without being detected. As with privacy, both authentication and data integrity use cryptographic methods. However, it is possible to be secure, but not private. An important example of this is DNS Security (or DNSSEC), which protects communication between recursive resolvers and the authoritative servers. In DNSSEC, authoritative responses are sent in the clear (without encryption) but accompanied by special DNS records called Resource Record Signatures (RRSIG) and DNSSEC Keys (DNSKEY). Together, these records allow the recursive resolver to validate the response, which prevents the response from being altered by a MITM (data integrity). Additionally, the DNSKEY records can be validated against another DNS record, the Delegation of Signing (DS), giving a high degree of confidence the authority is returning the expected data (authentication). DNS Privacy Considerations RFC 7626 covers DNS privacy considerations in detail. What follows is a summary of the salient points. 1. A DNS resolver query is typically sent over the wire as an unencrypted UDP packet. This traffic is easily decoded using packet analysis tools such as WIRESHARK, TCPDUMP or deep packet inspection applications. The particular information of interest is the IP source address and the query name. The source port number is also of interest as it may differentiate clients behind a NAT’ed network. 2. Web browsers when connecting to web sites may trigger a number of primary, secondary, and even tertiary requests for name resolution: ◦ The primary request is for the website’s domain name. ◦ Secondary requests are from embedded links in the downloaded HTML page. ◦ Tertiary requests which result when a caching server does not have the domain name in its cache and consults the authoritative servers to find it. As well, some browsers may prefetch domain names for future use or to autocomplete the URL in the address bar. 3. DNS data is considered public as noted above. However, RFC 7626 argues (§2.1) the need to differentiate between the DNS data and the transaction: DNS data and the results of a DNS query are [publicly available] and may not have any confidentiality requirements. However, the same is not true of a single transaction or a sequence of transactions; that transaction is not / should not be public. A typical example from outside the DNS world is: the web site of Alcoholics Anonymous is public; the fact that you visit it should not be. 2 The DNS attack surface is broad and encompasses the system which issues the DNS lookup request, the caching server which processes the request, and authority servers which assist in the domain name lookup. The attack surface will be further examined in subsequent sections. DNS Privacy Standards and Industry Efforts A number of technical solutions have been proposed over the last 10 years intended to address DNS privacy: DNSCrypt2, DNSCurve3, Namecoin4, Confidential DNS5, the GNU name system6, and Google DNS over HTTPS. All of these designs take different approaches in reducing the role of DNS as the ultimate source of meta data in the digital panopticon known as the Internet. These approaches to DNS privacy have yet to see the same level of acceptance as DoH and DoT. For completeness, the following sections provide an overview of each. DNSCurve Having been first put forth in 2011, this DNS privacy proposal is one of the oldest available. Details about this solution can be found here. This protocol establishes a secure channel between a client and a server by means of cryptographic techniques based on the Curve25519 elliptic curve7. It is meant to be used by caching servers to exchange DNS information with other caching or authoritative servers. DNSCrypt DNSCrypt is a formal proposal for the use of DNSCurve. Namecoin Namecoin is an approach to DNS confidentiality that uses blockchain techniques. This proposal requires a major overhaul of the DNS infrastructure. Confidential DNS (IETF Draft) This proposal introduces a new DNS record ENCRYPT. This record is returned by a DNS server when queried and contains a public key for the server. The protocol uses the public key to securely transfer a small amount of data between the client and server, allowing them to settle on specific key material that they can use in order to establish a secure channel for exchanging encrypted queries, and their associated responses. GNU name system The GNU Name System (GNS) is part of the GNU Net8 effort to provide a framework for secure peer-to- peer networking. 22https://en.wikipedia.org/wiki/DNSCurve 33DNSCrypt, https://github.com/DNSCrypt/dnscrypt-protocol/blob/master/DNSCRYPT-V2-PROTOCOL.txt 44https://namecoin.org/ 55https://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-02 66https://gnunet.org/taxonomy/term/34 77 https://en.wikipedia.org/wiki/Curve2551 88 https://gnu.net 3 Like Namecoin, GNS constitutes a complete overhaul of the DNS infrastructure. It relies on the GNU peer-to-peer network, plus a distributed hash table (DHT). The name resolution itself is carried out by means of DHT, whereas the queries and responses are exchanged over the GNS peer-to-peer network. Such data exchange is encrypted and signed, using capabilities provided by the GNU peer-to-peer network. Google DNS over HTTPS Proposal 9 This specification defines a web friendly JSON ReST API for the DNS request and response. As such it diverges from RFC 8484, which defines a binary response. A request is sent as follows: https://dns.google.com/resolve? To which the following parameters may be passed: name, type, cd, edns_client_subnet, and random_padding may be passed as keys with assigned values to further refine the query. A response is received in the following JSON format: { "Status": 0, // NOERROR - Standard DNS response code (32 bit integer). "TC": false, // Whether the response is truncated "RD": true, // Always true for Google Public DNS "RA": true, // Always true for Google Public DNS "AD": false, // Whether all response data was validated with DNSSEC "CD": false, // Whether the client asked
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]
  • 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]
  • 4.4 IT Infrastructure 4.4.1 Does the Institution Have a Comprehensive IT
    4.4 IT Infrastructure 4.4.1 Does the Institution have a comprehensive IT Policy with regard to: 1. IT Service Management ITS Centre for Dental Studies & Research is focused towards the applications of new technologies for easing up the day-to-day jobs and functions performed within and outside the campus. To achieve the same we at ITS CDSR are running many application to facilitate the routine works including the OPD & IPD, Resource management through ERP, and effective complaint handling and resolutions using Cloud Hosted Complaint Management System. Seamless 24*7 availability of Internet plays a vital role for effective use of the mentioned applications. A core IT staff team provides immediate resolutions to the user complaints and maintain the application uptime. 2. Information Security • Server Level Security: Quick Heal End Point Security Server Edition is installed on all the Servers to protect the Information from all Threats. • Client Level Security: All the desktop machines are installed with Quick Heal End Point Security to protect the client side Information from various Threats. • Network Level Security: The Campus Network is protected using UTM Device which protects the entire network from breaches and intrusion attacks from Internet. • Backups: o Server Side: Daily backups of all the Servers a taken by the Server Staff on External Hard Drives. o Client Side: Daily backups are taken by the staff members of their data on External Hard Drives. 3. Network Security • Installation of Unified Threat Management (UTM) Device: The campus wide network is protected from the Threats which propagate from Internet using the UTM device which offers following facilities: o Firewall o Gateway Level Anti-Virus o Gateway Level Anti-Spyware o Gateway Level Anti-Malware o Intrusion Detection/Prevention System o SSL and IPSec VPN’s Note: Please find detailed UTM Policy implementation for Authentication, Web & Application Filtration, Quota Management, QoS, and Data Transfer Limits in ANNEXURE I.
    [Show full text]
  • Evolution of the Linux TCP Stack: a Simulation Study
    UNIVERSITE CATHOLIQUE DE LOUVAIN ECOLE POLYTECHNIQUE DE LOUVAIN Evolution of the Linux TCP stack: a simulation study Thesis submitted for the Master's degree Supervisor: Olivier Bonaventure in computer science and engineering (120 credits) Readers: Ramin Sadre, Fabien Duch^ene options: networking and security by Esteban Sastre Ferr´andez Louvain-la-Neuve Academic year 2014-2015 \My laughter is my sword, and my joy is my shield." Martin Lutero. Abstract TCP (Transport Control Protocol) is widely known as a communication protocol be- tween devices that guarantees a reliable, ordered and error-checked exchange of informa- tion flow between them. As research progresses, changes in it's design and architecture are made, new features are added or modified, etc.. This translates into the existence of a large variety of different implementations of the same. Every new Linux Kernel version comes on the heels of representative changes inside TCP that may incur an en- hancement or a disadvantage when it comes to use one or another in certain specific network scenario. Measuring performance of all distinct versions of the protocol turns into an impossible task to carry out in the ample variety of heterogeneous real envi- ronments. This thesis provides a set of simulations of different TCP implementations under diverse traffic scenarios, all performed in several network topologies considered representative to a range of real cases. To achieve this goal, simulations are done within the ns-3 discrete event network simulator along with the DCE(Direct Code Execution) framework. Obviously taking into account every potential scenario is impossible. Hence, what this work offers is a representative subset of tests that may be useful to later re- searchers/sysadmins as a reference when it comes to deploy one or other version in a real environment.
    [Show full text]
  • How Speedy Is SPDY?
    How Speedy is SPDY? Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall, University of Washington https://www.usenix.org/conference/nsdi14/technical-sessions/wang This paper is included in the Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’14). April 2–4, 2014 • Seattle, WA, USA ISBN 978-1-931971-09-6 Open access to the Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’14) is sponsored by USENIX How speedy is SPDY? Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall University of Washington Abstract provides only a modest improvement [13, 19]. In our SPDY is increasingly being used as an enhancement own study [25] of page load time (PLT) for the top 200 to HTTP/1.1. To understand its impact on performance, Web pages from Alexa [1], we found either SPDY or we conduct a systematic study of Web page load time HTTP could provide better performance by a significant (PLT) under SPDY and compare it to HTTP. To identify margin, with SPDY performing only slightly better than the factors that affect PLT, we proceed from simple, syn- HTTP in the median case. thetic pages to complete page loads based on the top 200 As we have looked more deeply into the performance Alexa sites. We find that SPDY provides a significant im- of SPDY, we have come to appreciate why it is chal- provement over HTTP when we ignore dependencies in lenging to understand. Both SPDY and HTTP perfor- the page load process and the effects of browser compu- mance depend on many factors external to the protocols tation.
    [Show full text]
  • Online Security for Independent Media and Civil Society Activists
    Online Security for Independent Media and Civil Society Activists A white paper for SIDA’s October 2010 “Exile Media” conference Eric S Johnson (updated 13 Oct 2013) For activists who make it a priority to deliver news to citizens of countries which try to control the information to which their citizens have access, the internet has provided massive new opportunities. But those countries’ governments also realise ICTs’ potential and implement countermeasures to impede the delivery of independent news via the internet. This paper covers what exile media can or should do to protect itself, addressing three categories of issues: common computer security precautions, defense against targeted attacks, and circumventing cybercensorship, with a final note about overkill (aka FUD: fear, uncertainty, doubt). For each of the issues mentioned below, specific ex- amples from within the human rights or freedom of expression world can be provided where non-observance was cata- strophic, but most of those who suffered problems would rather not be named. [NB Snowden- gate changed little or nothing about these recommendations.] Common computer security: The best defense is a good … (aka “lock your doors”) The main threats to exile media’s successful use of ICTs—and solutions—are the same as for any other computer user: 1) Ensure all software automatically patches itself regularly against newly-discovered secu- rity flaws (e.g. to maintain up-to-date SSL certificate revocation lists). As with antivirus software, this may cost something; e.g. with Microsoft (Windows and Office), it may re- quire your software be legally purchased (or use the WSUS Offline Update tool, which helps in low-bandwidth environments).
    [Show full text]
  • Dns / Opennic / Dnscrypt
    dns / opennic / dnscrypt Serial: 2015111401 What is DNS ● Domain Name System ● In simple words when you are looking for hackerspace.gr you 're looking for the IP of the server that hosts the hackerspace site. ● But how ? How DNS works public/open dns ● Goodle dns – 8.8.8.8 2001:4860:4860::8888 – 8.8.4.4 2001:4860:4860::8844 ● OpenDNS – 208.67.222.222 2620:0:ccc::2 – 208.67.220.220 2620:0:ccd::2 ● norton dns/comodo/dns advantage/dns.watch ● fdn/freeDNS/Verisign ● BUT THEY ALL track what you are watching!!!! https://www.opennicproject.org/ ● OpenNIC is an alternate network information center/alternative DNS root which lists itself as an alternative to ICANN and its registries. ● Total DNS Neutrality ● Have A Say In Your DNS ● Protect Your Privacy ● No More ISP DNS Hijacking ● No Cost (Gratis) ● Freedom From Government Intervention openic website/wiki New Top Level Domains .bbs .ing .dyn .micro .free .neo .fur .null .geek .oss .gopher .oz .indy .parody 1. How does opennic work? . 82796 IN NS ns9.opennic.glue. 82796 IN NS ns3.opennic.glue. 82796 IN NS ns8.opennic.glue. 82796 IN NS ns4.opennic.glue. 82796 IN NS ns10.opennic.glue. 82796 IN NS ns6.opennic.glue. 82796 IN NS ns7.opennic.glue. 82796 IN NS ns2.opennic.glue. ;; Received 174 bytes from 94.242.59.170#53(94.242.59.170) in 126 ms 2. gr. 172800 IN NS gr-br.ics.forth.gr. gr. 172800 IN NS gr-at.ics.forth.gr. gr. 172800 IN NS estia.ics.forth.gr.
    [Show full text]
  • NSA's MORECOWBELL
    NSA's MORECOWBELL: Knell for DNS Christian Grothoff Matthias Wachs Monika Ermert Jacob Appelbaum Inria TU Munich Heise Verlag Tor Project 1 Introduction On the net, close to everything starts with a request to the Domain Name System (DNS), a core Internet protocol to allow users to access Internet services by names, such as www.example.com, instead of using numeric IP addresses, like 2001:DB8:4145::4242. Developed in the \Internet good old times" the contemporary DNS is like a large network activity chart for the visually impaired. Consequently, it now attracts not only all sorts of commercially-motivated surveillance, but, as new documents of the NSA spy program MORECOWBELL confirm, also the National Security Agency. Given the design weaknesses of DNS, this begs the question if DNS be secured and saved, or if it has to be replaced | at least for some use cases. In the last two years, there has been a flurry of activity to address security and privacy in DNS at the Internet Engineering Task Force (IETF), the body that documents the DNS standards. The Internet Architecture Board, peer body of the IETF, just called on the engineers to use encryption everywhere, possibly including DNS. [4] A recent draft [6] by the IETF on DNS privacy starts by acknowledging that the DNS \... is one of the most important infrastructure components of the Internet and one of the most often ignored or misunderstood. Almost every activity on the Internet starts with a DNS query (and often several). Its use has many privacy implications ..." Despite seemingly quick consensus on this assessment, the IETF is not expecting that existing industry solutions will change the situation anytime soon: \It seems today that the possibility of massive encryption of DNS traffic is very remote." [5] From a surveillance perspective, DNS currently treats all information in the DNS database as public data.
    [Show full text]
  • Vpn Vpns Que Aceptan Pagos Anónimos Vpns De Pago Vpns Gratuitas
    Anonimato En Red Ante todo, hay que tener claro que el anonimato 100% fiable en internet, no existe. Aún así, con diversos programas puedes ¨camuflarte¨ en un porcentaje bastante elevado. Indice Vpn VPNs que aceptan pagos anónimos VPNs de pago VPNs gratuitas Servidores DNS libres ¿Qué son? Cambiar DNS en WinXP Cambiar DNS en Windows Vista o Win7 Cambiar DNS en GNU/Linux Securizar DNS Lista de servidores DNS libres Tor ¿Cómo funciona? Instalación en Windows Instalación en Debian/Ubuntu Debilidades de la red Tor i2p ¿Qué es? Como acceder a IRC a través de i2p Iniciando i2p en Linux FoxyProxy ¿Qué es? ¿Qué es un proxy? Instalación Utilización Otra información de interés JonDonym ¿Qué es? Configuración y uso Freenet ¿Qué es? Configuración en Linux Descarga VPN VPN o Redes Privadas Virtuales (wiki: en.wikipedia.org/wiki/Virtual_private_n... ). “El mejor método” para navegar de forma anónima y casi el más fácil de configurar sería un VPN de PAGO. Hay versiones gratuitas de VPNs, pero no son recomendables, ya que podrían dar información de tu acceso a Internet a compañías 1 of 13 de publicidad y lo más probable es que estén más dispuestos a renunciar a proteger tu información en cualquier situación legal delicada. Las instrucciones para instalar y/o configurar tu VPN suelen ser facilitadas por los propios proveedores del servicio. VPNs que aceptan pagos anónimos (ukash, cashu, paysafecar, BitCoin etc…) www.101sec.net (Recomendada por #opspain) www.bwprivacy.to www.yourprivatevpn.com www.ivacy.com www.microvpn.com (solo IPs de EEUU) www.ovpn.to www.change-mon-ip.com
    [Show full text]
  • TCP Fast Open
    TCP Fast Open Sivasankar Radhakrishnan, Yuchung Cheng, Jerry Chu, Arvind Jain Barath Raghavan Google ICSI [email protected], {ycheng, hkchu, arvind}@google.com [email protected] ABSTRACT 2.4KB respectively [25]. As a result of the preponderance of Today’s web services are dominated by TCP flows so short small objects in large pages, web transfer latency has come that they terminate a few round trips after handshaking; this to be dominated by both the round-trip time (RTT) between handshake is a significant source of latency for such flows. In the client and server and the number of round trips required this paper we describe the design, implementation, and de- to transfer application data. The RTT of a web flow largely ployment of the TCP Fast Open protocol, a new mechanism comprises two components: transmission delay and propa- that enables data exchange during TCP’s initial handshake. gation delay. Though network bandwidth has grown substan- In doing so, TCP Fast Open decreases application network tially over the past two decades thereby significantly reduc- latency by one full round-trip time, decreasing the delay ex- ing transmission delays, propagation delay is largely con- perienced by such short TCP transfers. strained by the speed of light and therefore has remained un- We address the security issues inherent in allowing data changed. Thus reducing the number of round trips required exchange during the three-way handshake, which we miti- for the transfer of a web object is the most effective way to gate using a security token that verifies IP address owner- improve the latency of web applications [14, 18, 28, 31].
    [Show full text]
  • Understanding the Impact of Encrypted DNS on Internet Censorship
    Understanding the Impact of Encrypted DNS on Internet Censorship Lin Jin Shuai Hao Haining Wang Chase Cotton University of Delaware Old Dominion University Virginia Tech University of Delaware Newark, Delaware, USA Norfolk, Virginia, USA Arlington, Virginia, USA Newark, Delaware, USA [email protected] [email protected] [email protected] [email protected] ABSTRACT 1 INTRODUCTION DNS traffic is transmitted in plaintext, resulting in privacy leakage. The Domain Name System (DNS) provides important mappings To combat this problem, secure protocols have been used to encrypt between domain names and their numerical IP addresses to direct DNS messages. Existing studies have investigated the performance users to Internet services. As a fundamental component of the overhead and privacy benefits of encrypted DNS communications, Internet, DNS was designed as an unencrypted protocol. However, yet little has been done from the perspective of censorship. In this this allows eavesdroppers to sniff the domain that a user is going paper, we study the impact of the encrypted DNS on Internet cen- to visit, raising a privacy concern. In order to mitigate this privacy sorship in two aspects. On one hand, we explore the severity of DNS issue, secure protocols, such as DNS-over-TLS (DoT) [29] and DNS- manipulation, which could be leveraged for Internet censorship, over-HTTPS (DoH) [25], have been proposed to encrypt DNS traffic, given the use of encrypted DNS resolvers. In particular, we perform and DNS service providers, such as Google and Cloudflare, have 7.4 million DNS lookup measurements on 3,813 DoT and 75 DoH gradually supported these protocols on their resolvers.
    [Show full text]
  • TLS 1.3 (Over TCP Fast Open) Vs. QUIC
    An extended abstract of this paper appeared in the 24th European Symposium on Research in Com- puter Security, ESORICS 2019. This is the full version. Secure Communication Channel Establishment: TLS 1.3 (over TCP Fast Open) vs. QUIC Shan Chen1, Samuel Jero2, Matthew Jagielski3, Alexandra Boldyreva4, and Cristina Nita-Rotaru3 1Technische Universit¨atDarmstadt∗, [email protected] 2MIT Lincoln Laboratoryy, [email protected] 3Northeastern University, [email protected] [email protected] 4Georgia Institute of Technology, [email protected] November 27, 2020 Abstract Secure channel establishment protocols such as Transport Layer Security (TLS) are some of the most important cryptographic protocols, enabling the encryption of Internet traffic. Reducing latency (the number of interactions between parties before encrypted data can be transmitted) in such protocols has become an important design goal to improve user experience. The most important protocols addressing this goal are TLS 1.3, the latest TLS version standardized in 2018 to replace the widely deployed TLS 1.2, and Quick UDP Internet Connections (QUIC), a secure transport protocol from Google that is implemented in the Chrome browser. There have been a number of formal security analyses for TLS 1.3 and QUIC, but their security, when layered with their underlying transport protocols, cannot be easily compared. Our work is the first to thoroughly compare the security and availability properties of these protocols. Towards this goal, we develop novel security models that permit \layered" security analysis. In addition to the standard goals of server authentication and data confidentiality and integrity, we consider the goals of IP spoofing prevention, key exchange packet integrity, secure channel header integrity, and reset authentication, which capture a range of practical threats not usually taken into account by existing security models that focus mainly on the cryptographic cores of the protocols.
    [Show full text]