Inside Firefox’s DNS-over-HTTPS engine

And, like you said, this is a bad idea. Is there something wrong with efforts like DNSCrypt + DNSSec? That's supposed to provide authentication and encryption to DNS without sending everything over HTTP.

Did Mozilla just totally ignore the work that's already been done in this area?

However I disagree that it is a bad idea and that the implementation is bad. Regardless of how software _should_ behave, Firefox operates in how software is actually run for their users. DNS is a source of security vulnerabilities and headaches.

Demanding a higher level abstraction is not always an option for many, but using Firefox often is. This is especially important for mobile, where a lot of people don't have access or knowledge to set in place a system wide proxy after rooting their phones, but it is very easy to install Firefox mobile.

What about web browser usage on library or campus computers? Often they will have several browsers installed as well.

The point is that making security more available and easier to use where it matters most is a good idea.

[0] https://github.com/cloudflare/cloudflared

[1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https

Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic).

Applications should not contain their own encapsulated resolvers, let alone resolvers that default to sending all of my DNS traffic to for-profit companies that have previously experienced massive data leaks (and fun CF fact, they invited the then-CTO of Cambridge Analytica to talk at their Internet Summit event in SF last year).

"0 - Off (default). use standard native resolving"

...

"5 - Explicitly off. Also off, but selected off by choice and not default."

It seems that the plan for the "0 - default" is to switch the users to other modes without the user knowing it, and to keep the behavior off the user must specifically change the option to "5."

Furthermore, ISPs in some countries like India forces all port 53 traffic to their own censored servers. DNS over TLS won’t solve that.

One reason to desire separate trust stores is that your model of trust is almost certainly not "I wish my application trusted exactly the same CAs as [say] the Firefox web browser and I will incorporate all the same special rules and exception as that browser".

Example: Back in 2016 the US government expressed interest in operating its own public CA. This probably won't happen under Trump of course, but in Firefox this would have been no problem if they met its other criteria, it's easily able to accept a new CA and apply constraints to it. So that in Firefox a US Federal Web PKI cert for whitehouse.gov works, but one for gov.uk or google.com does not. But does your application have that logic? Or would it just blindly trust the new CA because Mozilla added it to their trust store?

The other reason is that your application is (especially if you aren't on the ball enough to run your own trust store) probably not able to keep up with the security treadmill, and falling off may be painful.

Example: If your system depended upon SHA-1 certificates to function, but you used the Web PKI CAs from somewhere like Mozilla's NSS store, magically in 2016 no more new certificates were available. No problem for the browser vendors, they had voted for exactly this outcome. Too bad for your application.

The difficulty there, I believe, is that /etc/hosts is commonly parsed by your libc, so firefox will have to reimplement /etc/host parsing on top of their libc if it does not expose /etc/host entries in some way (glibc and muslc both don't to my knowledge)

   / novice alert. this is probably 3x larger than necessary
   h0:_getenv "g";h1:0:h0;h1:{:[(#h1[x] _ss "://")>0;h1[x];_exit 1]}'!#h1;h1:{*((h1[x] _ss "://[^/]")+3) _ h1[x]}'!#h1;h2:{h1[x] _ss "[^a-z^A-Z^0-9^.^-]"};h3:{*h2[x]};h1:{h3[x]#h1[x]}'!#h1;h1:?:/h1;if[0=#h1[0];h1:h1 _di 0];h0 0:h1;

   ftp -4o 1.htm $1;
   fetch -4o 1.htm $1;
   wget -4o 1.htm $1;
   curl -4o 1.htm $1;
   
   exec k 1d \
   |exec tcs cloudflare-dns.com cloudflare-dns.com >1.json;
   yyf < 1.json >1.csv;
   #t=list exec k j;
   #t=hosts exec k j;
   t=db exec k j >1.csv;
   #t=zone exec k j;

   \\

   k).Q.fs[{`t insert +:`ts`ip`hn!("ZSS";",")0:x}]`:1.csv
   k)t

   \\

   / 1d.k
   / urls, hosts
   a:0:"1.htm";
   a:,/$a;
   a:_ssr[a;"\42";""];
   a:_ssr[a;"http://";"https://"];
   a:_ssr[a;"src=//";"https://"];
   b:a _ss "https://";
   a:b _ a;
   b:{a[x] _ss "[^a-z^A-Z^0-9^.^-]"}'!#a / fail: https://example.com-
   c:{1#(3_ b[x])}'!#b;
   b:{c[x]#a[x]}'!#c;
   b:?:/b;
   b:{8_ b[x] }'!#b;
   / http
   a:"GET /dns-query?ct=application/dns-json&name=";
   c:"&type=1 HTTP/1.1\r\nHost: cloudflare-dns.com\r\nConnection: ";
   d:"keep-alive";
   e:"close";
   f:"\r\n\r\n"; 
   g:(#b)-1;
   h:{a,b[x],c,d,f}'!g;
   i:a,b[g],c,e,f;

   `0:,/$h,i;

   \\

   int main(int argc, char **argv){
   char *b[17];
   b[0]="/usr/bin/openssl";
   b[1]="s_client";
   b[2]="-tls1_2";
   b[3]="-no_ssl2";
   b[4]="-no_ssl3";
   b[5]="-ign_eof";
   b[6]="-no_ticket";
   b[7]="-tlsextdebug";
   b[8]="-servername";
   b[9]=argv[2];
   b[10]="-verify";
   b[11]="9";
   /* -host, -port removed from manual */
   /* but still found in s_client.c */
   b[12]="-host"; 
   b[13]=argv[1];
   b[14]="-port";
   b[15]="443";
   b[16]=(void *)0;
   execve("/usr/bin/openssl",b,(void *)0);

   }



   /j.k

   j:("SSSSSS";",")0:"1.csv";
   k:_getenv "t";
   if[k _sm "list";`0:{,/$j[4;x]}'!#j[5]];
   if[k _sm "hosts";`0:{,/$j[5;x]," ",j[4;x]}'!#j[5]];
   if[k _sm "db";`0:{,/$j[2;x],".",j[1;x],".",j[0;x],"T",j[3;x],",",j[5;x],",",j[4;x]}'!#j[2]];
   if[k _sm "zone";`0:{,/$".",j[4;x],"\n&",j[4;x],".:127.0.0.1:5\n=",j[4;x],".:",j[5;x],":5"}'!#j[2]];
   \\

   \\

   /* f.l */

    #define echo ECHO
    #define jmp BEGIN
    #define p printf
    #define nl p("\n")
    #define s p(",")
   %s xa xb xc xd xx xy xz
   xa "\"Question\":[{\"name\": \""
   ya ", \"type\": 1}],"
   x1 "\"type\": 1" 
   x0 "\"type\": "[^1]","
   yb "\"data\": \""
   xw "Date: "
   xx \"\},\{\"
   xy \"\}\]\}
   xz "Sun, "|"Mon, "|"Tues, "|"Wed, "|"Thu, "|"Fri, "|"Sat, "
   %%
   {xw} jmp xz;
   <xz>"GMT" jmp xy;
   <xz>{xz}
   <xz>" Jan " p(",01,");
   <xz>" Feb " p(",02,");
   <xz>" Mar " p(",03,");
   <xz>" Apr " p(",04,");
   <xz>" May " p(",05,");
   <xz>" Jun " p(",06,");
   <xz>" Jul " p(",07,");
   <xz>" Aug " p(",08,");
   <xz>" Sep " p(",09,");
   <xz>" Oct " p(",10,");
   <xz>" Nov " p(",11,");
   <xz>" Dec " p(",12,");
   <xz>\40 s;
   <xz>. echo;
   <xy>{xa} jmp xa; 
   <xa>{ya} s;jmp xb;
   <xa>\.\"
   <xa>. echo;
   <xb>{x0} jmp xx;
   <xx>{xy} nl;jmp 0;
   <xx>{xx} jmp xb;
   <xb>{x1} jmp xc; 
   <xb>. 
   <xc>{yb} jmp xd;
   <xc>.  
   <xd>\"\} nl;jmp 0;
   <xd>. echo;
   \n
   .
   %%
   int main(){ yylex();}
   int yywrap(){}

Even without tickets, having TCP sessions means that server operators can link multiple queries to a single device, even if multiple devices share the same external IP.

This gives server operators more data than plain DNS.

The DNSCrypt protocol can use a unique key for every query in order to prevent this. Since it doesn't use sessions, and all queries are independent, there is no latency overhead.

For DoH, dnscrypt-proxy has an option to disable TLS session resumption. But it introduces some overhead every time a reconnection is necessary.

https://datatracker.ietf.org/wg/quic/about/

But yes, for the common case the performance will be the same.