davidbgk
/
larlet-fr-david-cache

<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang=fr>
<!-- Has to be within the first 1024 bytes, hence before the <title>
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset=utf-8>
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>Centralised DoH is bad for privacy, in 2019 and beyond (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
  content: '';
  content: none;
}
table {
  border-collapse: collapse;
  border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
  font-weight: 300;
  font-style: italic;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'ConcourseT3';
  src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
       url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
  /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
  font-family: "EquityTextB", Palatino, serif;
  background-color: #f0f0ea;
  color: #07486c;
  font-kerning: normal;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: subpixel-antialiased;
  text-rendering: optimizeLegibility;
  font-variant-ligatures: common-ligatures contextual;
  font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
  font-family: 'TriplicateT4c', monospace;
}
em {
  font-style: italic;
  color: #323a45;
}
strong {
  font-weight: bold;
  color: black;
}
nav {
  background-color: #323a45;
  color: #f0f0ea;
  display: flex;
  justify-content: space-around;
  padding: 1rem .5rem;
}
  nav:last-child {
    border-bottom: 1vh solid #2d7474;
  }
  nav a {
    color: #f0f0ea;
  }
  nav abbr {
    border-bottom: 1px dotted white;
  }

h1 {
  border-top: 1vh solid #2d7474;
  border-bottom: .2vh dotted #2d7474;
  background-color: #e3e1e1;
  color: #323a45;
  text-align: center;
  padding: 5rem 0 4rem 0;
  width: 100%;
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
}
  h1.single {
    padding-bottom: 10rem;
  }
  h1 span {
    position: absolute;
    top: 1vh;
    left: 20%;
    line-height: 0;
  }
    h1 span a {
      line-height: 1.7;
      padding: 1rem 1.2rem .6rem 1.2rem;
      border-radius: 0 0 6% 6%;
      background: #2d7474;
      font-size: 1.3rem;
      color: white;
      text-decoration: none;
    }
h2 {
  margin: 4rem 0 1rem;
  border-top: .2vh solid #2d7474;
  padding-top: 1vh;
}
h3 {
  text-align: center;
  margin: 3rem 0 .75em;
}
hr {
  height: .4rem;
  width: .4rem;
  border-radius: .4rem;
  background: #07486c;
  margin: 2.5rem auto;
}
time {
  display: bloc;
  margin-left: 0 !important;
}
ul, ol {
  margin: 2rem;
}
ul {
  list-style-type: square;
}
a {
  text-decoration-skip-ink: auto;
  text-decoration-thickness: 0.05em;
  text-underline-offset: 0.09em;
}
article {
  max-width: 50rem;
  display: flex;
  flex-direction: column;
  margin: 2rem auto;
}
  article.single {
    border-top: .2vh dotted #2d7474;
    margin: -6rem auto 1rem auto;
    background: #f0f0ea;
    padding: 2rem;
  }
  article p:last-child {
    margin-bottom: 1rem;
  }
p {
  padding: 0 .5rem;
  margin-left: 3rem;
}
  p + p,
  figure + p {
    margin-top: 2rem;
  }

blockquote {
  background-color: #e3e1e1;
  border-left: .5vw solid #2d7474;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 1rem;
  margin: 1.5rem;
}
  blockquote cite {
    font-style: italic;
  }
  blockquote p {
    margin-left: 0;
  }

figure {
  border-top: .2vh solid #2d7474;
  background-color: #e3e1e1;
  text-align: center;
  padding: 1.5rem 0;
  margin: 1rem 0 0;
  font-size: 1.5rem;
  width: 100%;
}
  figure img {
    max-width: 250px;
    max-height: 250px;
    border: .5vw solid #323a45;
    padding: 1px;
  }
figcaption {
  padding: 1rem;
  line-height: 1.4;
}
aside {
  display: flex;
  flex-direction: column;
  background-color: #e3e1e1;
  padding: 1rem 0;
  border-bottom: .2vh solid #07486c;
}
  aside p {
    max-width: 50rem;
    margin: 0 auto;
  }

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
  font-size: 1rem;
  line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
  font-size: 1.9rem;
  line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
  font-size: 1.6rem;
  line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
  font-size: 1.35rem;
  line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
  /* The (100vw - 20rem) / (50 - 20) part
     resolves to 0-1rem, depending on the
     viewport width (between 20em and 50em). */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
    margin-left: 0;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
}
@media (min-width: 50em) {
  /* The right part of the addition *must* be a
     rem value. In this example we *could* change
     the whole declaration to font-size:2.5rem,
     but if our baseline value was not expressed
     in rem we would have to use calc. */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * 1rem );
    line-height: 1.5em;
  }
  p, li, pre, details {
    margin-left: 3rem;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * 1rem );
    line-height: 1.2em;
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * 1rem );
    line-height: 1.3em;
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * 1rem );
    line-height: 1.4em;
  }
  figure img {
    max-width: 500px;
    max-height: 500px;
  }
}

figure.unsquared {
  margin-bottom: 1.5rem;
}
  figure.unsquared img {
    height: inherit;
  }


@media print {
  body { font-size: 100%; }
  a:after { content: " (" attr(href) ")"; }
  a, a:link, a:visited, a:after {
    text-decoration: underline;
    text-shadow: none !important;
    background-image: none !important;
    background: white;
    color: black;
  }
  abbr[title] { border-bottom: 0; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  img { page-break-inside: avoid; }
  @page { margin: 2cm .5cm; }
  h1, h2, h3 { page-break-after: avoid; }
  p3 { orphans: 3; widows: 3; }
  img {
    max-width: 250px !important;
    max-height: 250px !important;
  }
  nav, aside { display: none; }
}

ul.with_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_columns {
    column-count: 2;
  }
}
@media (min-width: 50em) {
  ul.with_columns {
    column-count: 3;
  }
}
ul.with_two_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_two_columns {
    column-count: 1;
  }
}
@media (min-width: 50em) {
  ul.with_two_columns {
    column-count: 2;
  }
}

.gallery {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-around;
}
  .gallery figure img {
    margin-left: 1rem;
    margin-right: 1rem;
  }
  .gallery figure figcaption {
    font-family: 'ConcourseT3'
  }

footer {
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
  border-top: 3px solid white;
  padding: 4rem 0;
  background-color: #07486c;
  color: white;
}
  footer > * {
    max-width: 50rem;
    margin: 0 auto;
  }
  footer a {
    color: #f1c40f;
  }
  footer .avatar {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    float: left;
    -webkit-shape-outside: circle();
    shape-outside: circle();
    margin-right: 2rem;
    padding: 2px 5px 5px 2px;
    background: white;
    border-left: 1px solid #f1c40f;
    border-top: 1px solid #f1c40f;
    border-right: 5px solid #f1c40f;
    border-bottom: 5px solid #f1c40f;
  }
</style>

<h1>
  <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
  Centralised DoH is bad for privacy, in 2019 and beyond (archive)
  <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
  <article>
    <h3><a href="https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/">Source originale du contenu</a></h3>
    <p>Recently, Mozilla announced it would be <a href="https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/">moving Firefox DNS lookups to Cloudflare by default, for its American audience</a>. There will be a notification about this for existing users, at which point they could choose to go back to provider DNS. But crucially, there will be no opt-in: it is Cloudflare by default, using <a href="https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/">a technology called DoH</a>.</p>

<p>This reignited some controversy, mostly in Europe, where meetings and panels in <a href="https://www.youtube.com/watch?v=pjin3nv8jAo">Amsterdam</a>, <a href="https://neutralinterconnectdays.nl/speakers/bert-hubert/">The Hague</a>, <a href="http://www.frnog.org/?page=frnog33&amp;lang=en">Paris</a> and <a href="https://www.youtube.com/watch?v=FqVX8WplEPg&amp;feature=youtu.be&amp;list=PLjzK5ZtLlc93nQTtvvXNplEMZJu1NicqR&amp;t=2698">Belfast</a> went over the pros and cons of this move, because it might well come to our shores as well.</p>

<p>During these discussions, I noticed that we haven’t been very analytical about what moving and encrypting DNS does for privacy. Many people appear to conflate the concepts of privacy and encryption, which are in fact very different things.</p>

<p>In this post I argue that in September 2019, centralised DoH “by default” is a net-negative for privacy for everyone and that even in later years it will not improve privacy outside of the most privacy hostile environments – where no one should rely on partial measures like DoH to stay secure.</p>

<h2 id="recapping-what-doh-does">Recapping what DoH does</h2>

<p>DNS is currently typically provided by the operator of a network, which could be your Internet Service Provider, your phone company, your employer or your proverbially evil coffeeshop WiFi.</p>

<p>DNS provided this way is never encrypted. Anyone observing your network traffic can see which DNS lookups are made. A more capable person could also inject fake answers, potentially rerouting your traffic.</p>

<p>DNS over HTTPS meanwhile encrypts DNS queries going over the network, which means that no one between you and the DoH server can see your DNS queries or modify the DNS responses.</p>

<p><strong>Crucially, in both plain DNS and DoH, the operator of the DNS server can see, sell, block and modify your DNS data.</strong> It is only the people in between that get locked out.</p>

<p>DNS privacy matters. Or more in general, knowing what sites you visit matters: your traffic metadata. A complete listing of sites (and servers) contacted will reveal where you work, live, study, what your hobbies are, what equipment/devices you own, what sports teams you follow, which health care providers you frequent, what brand of car you (want to) own &amp; likely your sexual preferences.</p>

<p>Many governments will also be very interested in who communicates with political parties or organizations they don’t like.</p>

<p>Restricting and choosing who can see the meta-data of what sites you visit is therefore very worthwhile.</p>

<p>DNS is one of four ways in which such meta-data gets transmitted in plaintext. For starters, browsers do not exclusively perform HTTPS requests. Many visits still start with a plaintext HTTP request that then redirects to HTTPS.</p>

<p>Secondly, TLS (which underlies HTTPS) very often has to transmit, in plaintext, the name of the site (or server) the user intends to connect to. This is true even in TLS 1.3. There is an <a href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni/history/">IETF draft standard</a> for encrypting this plaintext Server Name Indication, but it is not widely adopted, and needs serious work before it can be standardised.</p>

<blockquote><p>It is frequently and mistakenly thought that TLS 1.3 has plugged this leak, it hasn’t. To verify, try: <code>sudo tshark -i eth0 -T fields -e ssl.handshake.extensions_server_name -Y ssl.handshake.extensions_server_name -n</code></p></blockquote>

<p>Thirdly, to ensure that the certificate used for a TLS connection is valid, many browsers and TLS stacks will perform an OCSP lookup to the Certificate Authority provider. This lookup itself is also plaintext. Note that with some care, <a href="https://www.digicert.com/ssl-support/nginx-enable-ocsp-stapling-on-server.htm">OCSP lookups can be prevented</a>.</p>

<p>Finally, research has uncovered that <a href="https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an-ip-address/">over 95% of websites can uniquely be identified</a> purely by the set of IP addresses they are hosted on, and these IP addresses also can’t be encrypted.</p>

<p>I should also note that unless special measures are taken, a whole horde of dedicated web tracking companies (like Facebook and Google) will record and monetize most of your moves online anyhow, no matter how well encrypted your connection.</p>

<h2 id="privacy-before-and-after-doh">Privacy before and after DoH</h2>

<p>From the above, we see that DNS over HTTPS plugs only one of four (or five) avenues leaking sites visited.</p>

<p>But if we sum it up, pre-DoH, the following parties have access to the names of most of the sites you visit:</p>

<ol>
<li>Your own network provider</li>
<li>Your own government, police, intelligence services (through court orders)</li>
<li>Anyone capable of snooping your local network</li>
<li>Certificate authority providers (through OCSP)</li>
<li>Large scale tracking &amp; advertising companies (Google, Facebook)</li>
</ol>

<p>DNS over HTTPS in browsers is currently exclusively offered by/through American companies. So after switching to DoH, we have to add the following to our list:</p>

<ol>
<li>Cloudflare / your DoH provider</li>
<li>The US Government, NSA, FBI etc</li>
</ol>

<p>Because DoH does not encrypt anything that is not also present in plain text, there is nothing to remove from the list.</p>

<p><strong>Based on this, we can conclude that as it stands, using DoH to a browser-provisioned cloud provider effectively worsens your privacy position.</strong></p>

<p>Note: DNS over HTTPS is the protocol, and it could be used to enhance privacy. Using DoH to move DNS to the cloud is a specific way of using DoH that is damaging to privacy in 2019.</p>

<h2 id="dns-over-https-offers-additional-tracking-capabilities">DNS over HTTPS offers additional tracking capabilities</h2>

<p>DNS over HTTPS opens up DNS to all the tracking possibilities present in HTTPS and TLS. As it stands, DNS over UDP almost always gets some free privacy by mixing all devices on a network together – an outside snooper sees a stream of queries coming from a household, a coffeeshop or even an entire office building, with no way to tie a query to any specific device or user. Such mixing of queries provides an imperfect but useful modicum of privacy.</p>

<p>DNS over HTTPS however neatly separates out each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses <a href="https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/">TLS Resumption</a> which offers even further tracking capabilities.</p>

<p>In short, setting up an encrypted connection eats up precious CPU cycles both on client and server. It is therefore possible to reuse a previously established encrypted state for subsequent connections, which saves a lot of time and processor energy.</p>

<p>It does however make it possible to track an application from IP address to IP address because this TLS Resumption session ID <a href="https://nakedsecurity.sophos.com/2018/10/25/could-tls-session-resumption-be-another-super-cookie/">is effectively a cookie</a> that uniquely tracks users across network and IP address changes.</p>

<h2 id="but-what-about-the-privacy-agreement">But what about the privacy agreement?</h2>

<p>DoH providers typically publish privacy policies in which they pledge to provide you excellent DNS service without them benefiting in any way from your data, except possibly through very abstract research, or nebulous performance benefits that might attract customers for other products.</p>

<p>History has shown that the overwhelming majority of providers of free services that carry interesting user data have eventually failed at keeping this promise – either by <a href="https://www.upguard.com/breaches/verizon-cloud-leak">being compromised</a> or by <a href="https://www.androidauthority.com/google-location-history-lawsuit-897097/">accidentally</a> using <a href="https://www.claimsjournal.com/news/national/2019/06/17/291497.htm">the</a> <a href="https://9to5mac.com/2019/08/07/siri-lawsuit-recordings/">data</a> <a href="https://www.theguardian.com/technology/2019/jul/12/facebook-fine-ftc-privacy-violations">anyhow</a>. Apologies ensue, but trust never returns.</p>

<p>In addition to this hypothetical future misbehaviour, no privacy agreement stands up to a court order to hand over data in bulk. It so happens that the US legal &amp; intelligence climate frequently does in fact use <a href="https://twitter.com/nytimes/status/1175001702535192576">subpoenas and national security letters to hoover up user data</a>. It should also be noted that specifically US law affords <a href="https://twitter.com/PowerDNS_Bert/status/1171148978915872768">far less privacy protection</a> to “<a href="https://en.wikipedia.org/wiki/United_States_person">non-US persons</a>“ than the already meager protection provided to American citizens.</p>

<p>Also, US law extends to all servers and services operated by US companies, so “hosting data in Switzerland” <a href="https://twitter.com/PowerDNS_Bert/status/1162459443487019009">does not provide protection</a> if the operator is American.</p>

<p>So relying on a privacy agreement as some kind of <a href="https://twitter.com/adambroach/status/1170227987431792640">axiomatic guarantee of</a> privacy is not grounded in history <a href="https://twitter.com/PowerDNS_Bert/status/1162459443487019009">nor in legal fact</a>.</p>

<h2 id="dns-for-security">DNS for Security</h2>

<p>DNS itself is, oddly enough, not much of a security function in a browser. We derive secrecy and integrity from TLS, which in itself does not care about DNS. As an extreme example, a DNS provider could simply hand out 198.51.100.1 as answer to any browser query, receive TLS connections on that address &amp; connect to the right server from there based on the Server Name Indication, and <a href="https://github.com/dlundquist/sniproxy">things would just work</a>.</p>

<p>This would not allow any snooping (because TLS is end-to-end, and will check the certificate provided by the server hosting that name), but it does show that DNS integrity is irrelevant for browser security, as long as TLS is used faithfully (and we have no alternative to it anyhow).</p>

<h2 id="dns-for-adblocking-censorship-cdn-distribution">DNS for adblocking, censorship, CDN distribution</h2>

<p>Although DNS can not change TLS protected data, it can surely prevent access to such data. Countries frequently use DNS as a censorship choke point because it is easy and cheap. Russia, Turkey and Indonesia use DNS extensively to block access to sites their governments do not like.</p>

<p>Phones and increasingly browsers do not make it easy to block advertisements. One simple way of doing so anyhow <a href="https://pi-hole.net/">is through DNS</a>. Sabotaging the lookups for popular ad-servers is a very effective way of blocking advertising content.</p>

<p>Similarly, using lists of known malware associated domain names, it is very possible to cheaply block devices from accessing botnet infrastructure.</p>

<p>Finally, DNS can be used to optimize connectivity to streaming video caches, based on the IP address of the client computer. Several very large scale CDNs and service providers rely on this technique to route users to the right server.</p>

<p>One significant change with DoH is that the choice what to censor (or block) moves from the network operator to the browser vendor (who picks the DoH provider). If you are a privacy activist this is great, as long as you trust your browser vendor (and its government) more than your own country.</p>

<p>If you want to block ads, malware or if you need to route users to the best server, this will only be possible if the selected DoH vendor provides this service. This may not always be the case, especially if your browser or DoH vendor is also in the advertising business, or in fact competes with other CDNs.</p>

<h2 id="service-provider-originated-doh">Service provider originated DoH</h2>

<p>I (and many others) argue that encrypted DNS is good and that we should be doing more of it. This often gets rejected out of hand because there is no encrypted way to provision a nameserver.</p>

<p>When we connect to a network, in almost all cases our devices get configured automatically with the right network settings &amp; nameservers to use. Crucially, this autoconfiguration (be it DHCP or PPP) is not itself super-encrypted. So although our WiFi or 4G may be encrypted, the nameserver address is provided in plaintext over that connection.</p>

<p>This would allow a clever attacker to provision a snooping DoH server, defeating the point of DoH.</p>

<p>Because of this reason, browser vendors argue that they must ignore this autoconfiguration and hardcode a DoH server to use, over at a vendor they have selected on behalf of the user.</p>

<p>However – we should realize that the worst thing a network provider can do is inject a nameserver to learn what they could already learn from 3 other ways in which a browser leaks what it connects to!</p>

<h2 id="doh-for-oppressive-regimes">DoH for oppressive regimes</h2>

<p>It is frequently brought up that DoH is <a href="https://twitter.com/tcely/status/1175446535716462593">not built for privileged westeners</a> living in countries with (perhaps deteriorating) rule of law. DoH is instead offered as a way for people living in oppressive regimes to evade censorship and scrutiny, which surely is a laudable goal.</p>

<p>It is often said that a little knowledge is a dangerous thing. I have no experience as a political freedom fighter, but I do have family members who have had to flee their profoundly undemocratic country because they are members of persecuted minority.</p>

<p>Some years ago I contacted them because a flaw had been found in TLS encryption that might be dangerous for them, and to my surprise no one there cared. They had been assuming their Internet traffic was being spied upon anyhow, and it turns they were right.</p>

<p>Later they told me “we all use VPNs” and was impressed how privacy conscious they were. But no they told me, everyone does that, because without a VPN the internet here is too slow, they suspected the spying machinery was generally overloaded. The VPN was for speed. It was not assumed to deliver privacy, on which point they were also proven right (most VPN providers are pretty shady).</p>

<p>I mention these two stories to show that our assumptions on oppressive regimes may be wildly off, and not represent the reality on the ground in China, Russia, Iran, Indonesia and Turkey. It is a lot of fun being an armchair imaginary political activist, but things are remarkably different if you actually live there.</p>

<p>Of course, more encryption is good if it makes the life of oppressive regimes harder. It is definitely a case of “we must do something, and this is something”. It is slightly (but only slightly) harder to extract the TLS Server Name Indication than it is to parse plain DNS.</p>

<p>But the dynamics of what will happen when people in those countries start relying on DoH for their safety are very hard to fathom. We hear that <a href="https://twitter.com/AliMirjamali/status/1175450125126311938">some governments</a> have already moved beyond DNS based blocking, something we also saw in Russia during “<a href="https://www.reuters.com/article/us-russia-telegram/russia-tries-more-precise-technology-to-block-telegram-messenger-idUSKCN1LF1ZZ">the Telegram wars</a>”.</p>

<p>In this context, it is instrumental to see DoH as a “very partial VPN” that only encrypts DNS packets, but leaves all other packets unmodified. And in fact, the various DoH apps for phones are implemented as VPN providers. If judged as a VPN, it does look like a terrible one full of weaknesses.</p>

<p>Given this, recommending DoH because it will help dissidents in dangerous countries may be a very “techbro” thing to do – assuming your invention must be helpful without fully understanding the situation. Because for all we know the false sense of security is actually more harmful.</p>

<p>We may wonder why proponents aren’t instead recommending a full VPN as a solution instead of pushing an incomplete solution. Perhaps the <a href="https://www.forbes.com/sites/oreillymedia/2014/03/06/the-creep-factor-how-to-think-about-big-data-and-privacy/">creep factor</a> of routing all your traffic <a href="https://www.theverge.com/2019/2/22/18235908/facebook-onavo-vpn-privacy-service-data-collection">through a cloud provider</a> is too much?</p>

<h2 id="doh-as-an-incremental-step">DoH as an incremental step</h2>

<p>DoH proponents often agree that DoH itself does not fix all metadata privacy leaks, but insist it is a good step. The stated goal is to be able to eventually use any network, no mater how untrusted, and browse the web in complete privacy.</p>

<p>Oddly enough, it DoH proponents say it is fine to already move everyone’s DNS to a central place in another country, even though it currently does not provide any benefit, except sending your DNS to an additional party under control of a foreign snooping happy government.</p>

<p>To achieve the goal of perfect privacy on untrusted networks (without running a VPN) will require us to:</p>

<ol>
<li>Completely shut down plaintext HTTP</li>
<li>Use encrypted DNS</li>
<li>Deploy functional and downgrade-proof encrypted SNI.</li>
<li>Disable OCSP/make OCSP stapling mandatory, or replacing it by an alternate mechanism.</li>
<li>Host everything (every last widget) on large content distribution networks that are able to provide generic IP addresses, that have no discoverable link to the sites they are hosting.</li>
</ol>

<p>If and only if all these steps are completed, shutting down entire internet industries in step 5, does DoH stand a chance to deliver actual privacy benefits.</p>

<h2 id="summarising">Summarising</h2>

<p>Centralised DoH is currently a privacy net negative since anyone that could see your metadata can still see your metadata when DNS is moved to a third party. Additionally, that third party then gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses.</p>

<p>Even if further privacy leaks are plugged, DoH to a third party remains at best a partial solution, one that should not be relied upon as a serious security layer, since it will be hard to plug everything, especially if non-CDN content providers survive.</p>

<p>Encrypting DNS is good, but if this could be done without involving additional parties, that would be better.</p>

<p>And for actual privacy on untrusted networks, nothing beats a VPN, except possibly not using hostile networks.</p>
  </article>
</section>


<nav id="jumpto">
  <p>
    <a href="/david/blog/">Accueil du blog</a> |
    <a href="https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/">Source originale</a> |
    <a href="/david/stream/2019/">Accueil du flux</a>
  </p>
</nav>

<footer>
  <div>
    <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
    <p>
      Bonjour/Hi!
      Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
      Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
    </p>
    <p>
      Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
    </p>
    
    <p>
      Voici quelques articles choisis :
      <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
      <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
      <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
      <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
      <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
      <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
      <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
      <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
      <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
      <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
      <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
      <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
      <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
      <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
      <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
      et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
    </p>
    <p>
      On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
    </p>
    <p>
      Je ne traque pas ta navigation mais mon
      <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
      conserve des logs d’accès.
    </p>
  </div>
</footer>
<script type="text/javascript">
  ;(_ => {
    const jumper = document.getElementById('jumper')
    jumper.addEventListener('click', e => {
      e.preventDefault()
      const anchor = e.target.getAttribute('href')
      const targetEl = document.getElementById(anchor.substring(1))
      targetEl.scrollIntoView({behavior: 'smooth'})
    })
  })()
</script>