MISC-32: Android DoH App Intra leaks DNS Queries

Issue Information

Issue Type: Bug
 
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: Miscellaneous (MISC)
Resolution: Fixed (2019-05-27 13:01:37)
Labels: Android, DNS-over-HTTPS, DoH, Intra, Privacy, Security,
Environment: Android 8.0.0
MIUI Global 10.2 | Stable 10.2.2.0
Intra version 1.1.3

Created: 2019-05-27 11:47:44
Time Spent Working


Description
I originally started recording this on Twitter (see links) as I wasn't convinced I was seeing what I thought I was.

Raising this issue as have had opportunity to collect more data.

Jigsaw is Google's sister company, and Intra is an App which allows you to intercept DNS lookups and send them via DNS-over-HTTPS (DoH) instead. It works by acting as though it were a VPN, and then intercepting any packets on UDP 53.

In early May, I noticed my home pi-hole interface was showing lookups from my phone, which runs Intra in order to send queries out to my DoH server on the net (https://www.bentasker.co.uk/documentation/linux/407-building-and-running-your-own-dns-over-https-server)

The behaviour stopped shortly after I noticed it though - presumably (https://twitter.com/bentasker/status/1129696578867011584) because I'd interacted with the phone and woken something up?

On Saturday whilst on someone else's Wifi I got a BT NXDOMAIN interception page (https://twitter.com/bentasker/status/1132288203023704064) which should never happen.

This morning I've taken captures, and found queries hitting port 53 with no corresponding queries hitting my DoH server (despite the Intra Icon being in my notification panel).

Will update the comment in a minute with copies of notes/comments from earlier in the Twitter thread


Attachments

Issue Links

Thread (Twitter)
Toggle State Changes

Activity


2019-05-27 11:50:04
Wondered if perhaps Intra falls through to local if it receives a result it didn't expect (like 0.0.0.0), but Qs like (link: http://graph.facebook.com) graph.facebook.com wouldn't result in that kind of result. Doesn't appear to be sending to DoH & onto the network routinely, so guess need to check logs

Ah, so, looking at it, queries from #Intra at the #DoH server from my phone start at 09:52 UTC this morning. Just after I'd noticed those pi-hole entries (times there are BST) and picked my phone up to check it. I may know what this is now

Actually not that. I thought Intra might be another victim of #MIUI's insanely aggressive battery saver, but it's disabled. That said, MIUI's optimisation has been known to kill of the system's GPS service, so it's still possible it's the battery saver...

On the other hand, the things been on charge all night and most of the morning, so the idea the app would even need suspending to save battery is insane. But, thinking about it, when I picked the phone up the VPN icon was missing from the top right for a few secs

Just for avoidance of doubt, #Intra does allow you to exclude apps from being sent to the DoH server. I have a couple ticked, though none should have resulted in those queries. The Niantic queries in the log must have come from Pokemon Go which definitely isn't excluded

So, given the lack of log entries (even of idle activity) from my phone on my DoH server, I'm inclined to think the Battery Saver may have killed of the VPN connection that Intra uses to intercept DNS.

It still might be something else, but if I'm right, that's worrying.
@Jigsaw initially made this app for places like China, but running on a Chinese branded phone we get DNS leakage onto the local network (and from there onto upstream resolvers in full view of ISPs)

Not much the app can do about that of course, and in my case it's just a minor annoyance, but in other's situations it could potentially be dangerous.

I guess the answer is to pay closer attention and see if it happens again. It's always possible it was something more innocuous

2019-05-27 11:51:02
And the comments from a couple of days ago:

There's definitely some leakage going on. Out and someone's house and just accidentally refreshed a tab open on one of my internal domains (Doh server can resolve it). Got greeted by BT's NXDOMAIN interception page. Shouldn't happen ever if DoH is being used

Can fairly reliably repro with a non existent domain. Guess Intra does let queries fall through if the DoH lookup isn't successful. Means leakage is silent if an adversary blocks the DoH server... dangerous

Also, no comment on
@bt_uk's suggestions for flibblewibble.com... Hard to believe they still think intercepting nxdomain is a good idea in 2019
Image

2019-05-27 11:52:19
btasker added 'pihole_log.jpeg' to Attachments

2019-05-27 11:52:19
btasker added 'miui_batter_saver.jpeg' to Attachments

2019-05-27 11:52:19
btasker added 'bt_nxdomain_interception.jpeg' to Attachments

2019-05-27 11:55:44
OK, so running captures


We see the lookup come in 

root@VR1:~# tcpdump -i eth0 -X -v host 192.168.1.214 and port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:23:23.768409 IP (tos 0x0, ttl 64, id 558, offset 0, flags [DF], proto UDP (17), length 68)
    benphone.38172 > google-public-dns-a.google.com.domain: 36118+ A? flibblewibble.com.home. (40)
	0x0000:  4500 0044 022e 4000 4011 65ed c0a8 01d6  E..D..@.@.e.....
	0x0010:  0808 0808 951c 0035 0030 2f26 8d16 0100  .......5.0/&....
	0x0020:  0001 0000 0000 0000 0d66 6c69 6262 6c65  .........flibble
	0x0030:  7769 6262 6c65 0363 6f6d 0468 6f6d 6500  wibble.com.home.
	0x0040:  0001 0001                                ....
11:23:23.770832 IP (tos 0x0, ttl 63, id 53498, offset 0, flags [DF], proto UDP (17), length 68)
    google-public-dns-a.google.com.domain > benphone.38172: 36118 ServFail 0/0/0 (40)
	0x0000:  4500 0044 d0fa 4000 3f11 9820 0808 0808  E..D..@.?.......
	0x0010:  c0a8 01d6 0035 951c 0030 aea3 8d16 8182  .....5...0......
	0x0020:  0001 0000 0000 0000 0d66 6c69 6262 6c65  .........flibble
	0x0030:  7769 6262 6c65 0363 6f6d 0468 6f6d 6500  wibble.com.home.
	0x0040:  0001 0001                                ....
^C




DNS logs show: 
86.138.218.68	-	-	[27/May/2019:10:23:23 +0000]	"GET /[trimmed]/dns-query?dns=AAABAAABAAAAAAAADWZsaWJibGV3aWJibGUDY29tAAABAAE HTTP/2.0"	200	136	"-"	"Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0"	"-"	"dns.bentasker.co.uk"	CACHE_-	0.019	debian-9-doh-newbuild	-
86.138.218.68	-	-	[27/May/2019:10:23:23 +0000]	"GET /[trimmed]/dns-query?dns=AAABAAABAAAAAAAADWZsaWJibGV3aWJibGUDY29tAAAcAAE HTTP/2.0"	200	57	"-"	"Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0"	"-"	"dns.bentasker.co.uk"	CACHE_-	0.018	debian-9-doh-newbuild	-
86.138.218.68	-	-	[27/May/2019:10:23:23 +0000]	"GET /[trimmed]/dns-query?dns=AAABAAABAAAAAAAAA3d3dw1mbGliYmxld2liYmxlA2NvbQAAAQAB HTTP/2.0"	200	140	"-"	"Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0"	"-"	"dns.bentasker.co.uk"	CACHE_-	0.019	debian-9-doh-newbuild	-
86.138.218.68	-	-	[27/May/2019:10:23:23 +0000]	"GET /[trimmed]/dns-query?dns=AAABAAABAAAAAAAAA3d3dw1mbGliYmxld2liYmxlA2NvbQAAHAAB HTTP/2.0"	200	61	"-"	"Mozilla/5.0 (Android 8.0.0; Mobile; rv:67.0) Gecko/67.0 Firefox/67.0"	"-"	"dns.bentasker.co.uk"	CACHE_-	0.018	debian-9-doh-newbuild	-


Interestingly, we don't have any queries from Intra, only Firefox's TRR. So when that failed and fell through, we used the system resolver.

I wonder then if Firefox is doing something funky rather than handing it over to the OS to handle?

Turning TRR off in Firefox (change network.trr.mode from 2 to 0) to see whether we then get a request from Intra

I now get nothing on port 53, but also nothing in the DoH server logs.

OK, placing a request for a non-existent domain on an authoritative I control: 
20190527-113603	86.138.218.0	SOA	foobar.balanced.bentasker.co.uk					74.125.73.68	86.138.218.0/24	CACHE:	0.00023

20190527-103603	86.138.218.68	SOA	foobar.balanced.bentasker.co.uk					86.138.218.68	86.138.218.68/32	CACHE:	0.00028
20190527-103603	86.138.218.0	SOA	foobar.balanced.bentasker.co.uk					74.125.73.74	86.138.218.0/24	CACHE:	0.00026


So, the resolvers there are Google and BT. facepalm I know why... I've been a twat. Running the tcpdump on the wrong host, I recently dropped pi-hole onto the network. Re-running there

There we go 
root@pihole:/home/ben# tcpdump -i eth0 -X -v host 192.168.1.214 and port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:39:09.005192 IP (tos 0x0, ttl 64, id 25810, offset 0, flags [DF], proto UDP (17), length 68)
    benphone.9304 > pihole.domain: 18941+ A? ibblewibbleflibble.com. (40)
	0x0000:  4500 0044 64d2 4000 4011 50c8 c0a8 01d6  E..Dd.@.@.P.....
	0x0010:  c0a8 01e8 2458 0035 0030 7be1 49fd 0100  ....$X.5.0{.I...
	0x0020:  0001 0000 0000 0000 1269 6262 6c65 7769  .........ibblewi
	0x0030:  6262 6c65 666c 6962 626c 6503 636f 6d00  bbleflibble.com.
	0x0040:  0001 0001                                ....
11:39:09.082567 IP (tos 0x0, ttl 64, id 22377, offset 0, flags [DF], proto UDP (17), length 141)
    pihole.domain > benphone.9304: 18941 NXDomain 0/1/0 (113)
	0x0000:  4500 008d 5769 4000 4011 5de8 c0a8 01e8  E...Wi@.@.].....
	0x0010:  c0a8 01d6 0035 2458 0079 8599 49fd 8183  .....5$X.y..I...
	0x0020:  0001 0000 0001 0000 1269 6262 6c65 7769  .........ibblewi
	0x0030:  6262 6c65 666c 6962 626c 6503 636f 6d00  bbleflibble.com.
	0x0040:  0001 0001 c01f 0006 0001 0000 0383 003d  ...............=
	0x0050:  0161 0c67 746c 642d 7365 7276 6572 7303  .a.gtld-servers.
	0x0060:  6e65 7400 056e 7374 6c64 0c76 6572 6973  net..nstld.veris
	0x0070:  6967 6e2d 6772 73c0 1f5c ebbe 3900 0007  ign-grs..\..9...
	0x0080:  0800 0003 8400 093a 8000 0151 80         .......:...Q.
11:39:09.094484 IP (tos 0x0, ttl 64, id 25811, offset 0, flags [DF], proto UDP (17), length 73)
    benphone.5163 > pihole.domain: 27923+ A? ibblewibbleflibble.com.home. (45)
	0x0000:  4500 0049 64d3 4000 4011 50c2 c0a8 01d6  E..Id.@.@.P.....
	0x0010:  c0a8 01e8 142b 0035 0035 9117 6d13 0100  .....+.5.5..m...
	0x0020:  0001 0000 0000 0000 1269 6262 6c65 7769  .........ibblewi
	0x0030:  6262 6c65 666c 6962 626c 6503 636f 6d04  bbleflibble.com.
	0x0040:  686f 6d65 0000 0100 01                   home.....
11:39:09.233720 IP (tos 0x0, ttl 64, id 22390, offset 0, flags [DF], proto UDP (17), length 73)
    pihole.domain > benphone.5163: 27923 ServFail 0/0/0 (45)
	0x0000:  4500 0049 5776 4000 4011 5e1f c0a8 01e8  E..IWv@.@.^.....
	0x0010:  c0a8 01d6 0035 142b 0035 8555 6d13 8182  .....5.+.5.Um...
	0x0020:  0001 0000 0000 0000 1269 6262 6c65 7769  .........ibblewi
	0x0030:  6262 6c65 666c 6962 626c 6503 636f 6d04  bbleflibble.com.
	0x0040:  686f 6d65 0000 0100 01                   home.....
11:39:09.237758 IP (tos 0x0, ttl 64, id 25824, offset 0, flags [DF], proto UDP (17), length 73)
    benphone.4648 > pihole.domain: 27923+ A? ibblewibbleflibble.com.home. (45)
	0x0000:  4500 0049 64e0 4000 4011 50b5 c0a8 01d6  E..Id.@.@.P.....
	0x0010:  c0a8 01e8 1228 0035 0035 931a 6d13 0100  .....(.5.5..m...
	0x0020:  0001 0000 0000 0000 1269 6262 6c65 7769  .........ibblewi
	0x0030:  6262 6c65 666c 6962 626c 6503 636f 6d04  bbleflibble.com.
	0x0040:  686f 6d65 0000 0100 01                   home.....
11:39:09.241659 IP (tos 0x0, ttl 64, id 22392, offset 0, flags [DF], proto UDP (17), length 73)
    pihole.domain > benphone.4648: 27923 ServFail 0/0/0 (45)
	0x0000:  4500 0049 5778 4000 4011 5e1d c0a8 01e8  E..IWx@.@.^.....
	0x0010:  c0a8 01d6 0035 1228 0035 8555 6d13 8182  .....5.(.5.Um...
	0x0020:  0001 0000 0000 0000 1269 6262 6c65 7769  .........ibblewi
	0x0030:  6262 6c65 666c 6962 626c 6503 636f 6d04  bbleflibble.com.
	0x0040:  686f 6d65 0000 0100 01                   home.....
11:39:09.283196 IP (tos 0x0, ttl 64, id 25827, offset 0, flags [DF], proto UDP (17), length 77)
    benphone.12045 > pihole.domain: 23731+ A? foobar.balanced.bentasker.co.uk. (49)
	0x0000:  4500 004d 64e3 4000 4011 50ae c0a8 01d6  E..Md.@.@.P.....
	0x0010:  c0a8 01e8 2f0d 0035 0039 5bcc 5cb3 0100  ..../..5.9[.\...
	0x0020:  0001 0000 0000 0000 0666 6f6f 6261 7208  .........foobar.
	0x0030:  6261 6c61 6e63 6564 0962 656e 7461 736b  balanced.bentask
	0x0040:  6572 0263 6f02 756b 0000 0100 01         er.co.uk.....
11:39:09.343187 IP (tos 0x0, ttl 64, id 22416, offset 0, flags [DF], proto UDP (17), length 77)
    pihole.domain > benphone.12045: 23731 0/0/0 (49)
	0x0000:  4500 004d 5790 4000 4011 5e01 c0a8 01e8  E..MW.@.@.^.....
	0x0010:  c0a8 01d6 0035 2f0d 0039 8559 5cb3 8180  .....5/..9.Y\...
	0x0020:  0001 0000 0000 0000 0666 6f6f 6261 7208  .........foobar.
	0x0030:  6261 6c61 6e63 6564 0962 656e 7461 736b  balanced.bentask
	0x0040:  6572 0263 6f02 756b 0000 0100 01         er.co.uk.....
11:39:09.346043 IP (tos 0x0, ttl 64, id 25832, offset 0, flags [DF], proto UDP (17), length 82)
    benphone.4027 > pihole.domain: 18005+ A? foobar.balanced.bentasker.co.uk.home. (54)
	0x0000:  4500 0052 64e8 4000 4011 50a4 c0a8 01d6  E..Rd.@.@.P.....
	0x0010:  c0a8 01e8 0fbb 0035 003e ba9a 4655 0100  .......5.>..FU..
	0x0020:  0001 0000 0000 0000 0666 6f6f 6261 7208  .........foobar.
	0x0030:  6261 6c61 6e63 6564 0962 656e 7461 736b  balanced.bentask
	0x0040:  6572 0263 6f02 756b 0468 6f6d 6500 0001  er.co.uk.home...
	0x0050:  0001                                     ..
11:39:09.351818 IP (tos 0x0, ttl 64, id 22419, offset 0, flags [DF], proto UDP (17), length 82)
    pihole.domain > benphone.4027: 18005 ServFail 0/0/0 (54)
	0x0000:  4500 0052 5793 4000 4011 5df9 c0a8 01e8  E..RW.@.@.].....
	0x0010:  c0a8 01d6 0035 0fbb 003e 855e 4655 8182  .....5...>.^FU..
	0x0020:  0001 0000 0000 0000 0666 6f6f 6261 7208  .........foobar.
	0x0030:  6261 6c61 6e63 6564 0962 656e 7461 736b  balanced.bentask
	0x0040:  6572 0263 6f02 756b 0468 6f6d 6500 0001  er.co.uk.home...
	0x0050:  0001                                     ..
11:39:09.359430 IP (tos 0x0, ttl 64, id 25833, offset 0, flags [DF], proto UDP (17), length 82)
    benphone.22041 > pihole.domain: 18005+ A? foobar.balanced.bentasker.co.uk.home. (54)
	0x0000:  4500 0052 64e9 4000 4011 50a3 c0a8 01d6  E..Rd.@.@.P.....
	0x0010:  c0a8 01e8 5619 0035 003e 743c 4655 0100  ....V..5.>t<FU..
	0x0020:  0001 0000 0000 0000 0666 6f6f 6261 7208  .........foobar.
	0x0030:  6261 6c61 6e63 6564 0962 656e 7461 736b  balanced.bentask
	0x0040:  6572 0263 6f02 756b 0468 6f6d 6500 0001  er.co.uk.home...
	0x0050:  0001                                     ..
11:39:09.363200 IP (tos 0x0, ttl 64, id 22420, offset 0, flags [DF], proto UDP (17), length 82)
    pihole.domain > benphone.22041: 18005 ServFail 0/0/0 (54)
	0x0000:  4500 0052 5794 4000 4011 5df8 c0a8 01e8  E..RW.@.@.].....
	0x0010:  c0a8 01d6 0035 5619 003e 855e 4655 8182  .....5V..>.^FU..
	0x0020:  0001 0000 0000 0000 0666 6f6f 6261 7208  .........foobar.
	0x0030:  6261 6c61 6e63 6564 0962 656e 7461 736b  balanced.bentask
	0x0040:  6572 0263 6f02 756b 0468 6f6d 6500 0001  er.co.uk.home...
	0x0050:  0001                                     ..
11:39:09.399699 IP (tos 0x0, ttl 64, id 25836, offset 0, flags [DF], proto UDP (17), length 72)
    benphone.28587 > pihole.domain: 18354+ A? www.ibblewibbleflibble.com. (44)
	0x0000:  4500 0048 64ec 4000 4011 50aa c0a8 01d6  E..Hd.@.@.P.....
	0x0010:  c0a8 01e8 6fab 0035 0034 b7e2 47b2 0100  ....o..5.4..G...
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d00 0001 0001                      com.....
11:39:09.415602 IP (tos 0x0, ttl 64, id 22431, offset 0, flags [DF], proto UDP (17), length 145)
    pihole.domain > benphone.28587: 18354 NXDomain 0/1/0 (117)
	0x0000:  4500 0091 579f 4000 4011 5dae c0a8 01e8  E...W.@.@.].....
	0x0010:  c0a8 01d6 0035 6fab 007d 859d 47b2 8183  .....5o..}..G...
	0x0020:  0001 0000 0001 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d00 0001 0001 c023 0006 0001 0000  com......#......
	0x0050:  0384 003d 0161 0c67 746c 642d 7365 7276  ...=.a.gtld-serv
	0x0060:  6572 7303 6e65 7400 056e 7374 6c64 0c76  ers.net..nstld.v
	0x0070:  6572 6973 6967 6e2d 6772 73c0 235c ebbe  erisign-grs.#\..
	0x0080:  4300 0007 0800 0003 8400 093a 8000 0151  C..........:...Q
	0x0090:  80                                       .
11:39:09.418358 IP (tos 0x0, ttl 64, id 25837, offset 0, flags [DF], proto UDP (17), length 77)
    benphone.15951 > pihole.domain: 19863+ A? www.ibblewibbleflibble.com.home. (49)
	0x0000:  4500 004d 64ed 4000 4011 50a4 c0a8 01d6  E..Md.@.@.P.....
	0x0010:  c0a8 01e8 3e4f 0035 0039 0b79 4d97 0100  ....>O.5.9.yM...
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....
11:39:09.583111 IP (tos 0x0, ttl 64, id 22463, offset 0, flags [DF], proto UDP (17), length 77)
    pihole.domain > benphone.15951: 19863 ServFail 0/0/0 (49)
	0x0000:  4500 004d 57bf 4000 4011 5dd2 c0a8 01e8  E..MW.@.@.].....
	0x0010:  c0a8 01d6 0035 3e4f 0039 8559 4d97 8182  .....5>O.9.YM...
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....
11:39:09.588802 IP (tos 0x0, ttl 64, id 25843, offset 0, flags [DF], proto UDP (17), length 77)
    benphone.23095 > pihole.domain: 19863+ A? www.ibblewibbleflibble.com.home. (49)
	0x0000:  4500 004d 64f3 4000 4011 509e c0a8 01d6  E..Md.@.@.P.....
	0x0010:  c0a8 01e8 5a37 0035 0039 ef90 4d97 0100  ....Z7.5.9..M...
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....
11:39:09.591255 IP (tos 0x0, ttl 64, id 22465, offset 0, flags [DF], proto UDP (17), length 77)
    pihole.domain > benphone.23095: 19863 ServFail 0/0/0 (49)
	0x0000:  4500 004d 57c1 4000 4011 5dd0 c0a8 01e8  E..MW.@.@.].....
	0x0010:  c0a8 01d6 0035 5a37 0039 8559 4d97 8182  .....5Z7.9.YM...
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....
11:39:09.837872 IP (tos 0x0, ttl 64, id 25856, offset 0, flags [DF], proto UDP (17), length 77)
    benphone.8919 > pihole.domain: 15947+ A? www.ibblewibbleflibble.com.home. (49)
	0x0000:  4500 004d 6500 4000 4011 5091 c0a8 01d6  E..Me.@.@.P.....
	0x0010:  c0a8 01e8 22d7 0035 0039 363d 3e4b 0100  ...."..5.96=>K..
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....
11:39:09.842468 IP (tos 0x0, ttl 64, id 22497, offset 0, flags [DF], proto UDP (17), length 77)
    pihole.domain > benphone.8919: 15947 ServFail 0/0/0 (49)
	0x0000:  4500 004d 57e1 4000 4011 5db0 c0a8 01e8  E..MW.@.@.].....
	0x0010:  c0a8 01d6 0035 22d7 0039 8559 3e4b 8182  .....5"..9.Y>K..
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....
11:39:09.845948 IP (tos 0x0, ttl 64, id 25857, offset 0, flags [DF], proto UDP (17), length 77)
    benphone.27682 > pihole.domain: 15947+ A? www.ibblewibbleflibble.com.home. (49)
	0x0000:  4500 004d 6501 4000 4011 5090 c0a8 01d6  E..Me.@.@.P.....
	0x0010:  c0a8 01e8 6c22 0035 0039 ecf1 3e4b 0100  ....l".5.9..>K..
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....
11:39:09.849943 IP (tos 0x0, ttl 64, id 22499, offset 0, flags [DF], proto UDP (17), length 77)
    pihole.domain > benphone.27682: 15947 ServFail 0/0/0 (49)
	0x0000:  4500 004d 57e3 4000 4011 5dae c0a8 01e8  E..MW.@.@.].....
	0x0010:  c0a8 01d6 0035 6c22 0039 8559 3e4b 8182  .....5l".9.Y>K..
	0x0020:  0001 0000 0000 0000 0377 7777 1269 6262  .........www.ibb
	0x0030:  6c65 7769 6262 6c65 666c 6962 626c 6503  lewibbleflibble.
	0x0040:  636f 6d04 686f 6d65 0000 0100 01         com.home.....


But the key point here, is there're no requests from Intra being received at the DoH server despite the fact it's icon is sat in my notification bar (see screenshot) and is ostensibly running

2019-05-27 11:56:41
btasker added 'Screenshot_2019-05-27-11-24-22-018_org.mozilla.firefox.png' to Attachments

2019-05-27 12:02:19
I suspect if I go into Intra it'll start working again... before I do that though, lets see when intra last made an appearance in my DoH logs (i.e. how long it's been sat silently broken for)

That's.... a while 
root@debian-9-doh-newbuild:~# grep "Jigsaw-DNS" /var/log/nginx/dns.log
root@debian-9-doh-newbuild:~# grep "Jigsaw-DNS" /var/log/nginx/dns.log.1
root@debian-9-doh-newbuild:~# zgrep "Jigsaw-DNS" /var/log/nginx/dns.log.{2..10}.gz | head
/var/log/nginx/dns.log.6.gz:86.138.218.68	-	-	21/May/2019:06:26:13 +0000	"POST /n6RFhP2ffYzKY0zEkF/dns-query HTTP/2.0"	200	95	"-"	"Jigsaw-DNS/1.1.3"	"-"	"dns.bentasker.co.uk"	CACHE_-	0.002	debian-9-doh-newbuild-

Lets get an exact time 
root@debian-9-doh-newbuild:~# zgrep "Jigsaw-DNS" /var/log/nginx/dns.log.6.gz | tail -n 1
86.138.218.68	-	-	21/May/2019:22:35:55 +0000	"POST /n6RFhP2ffYzKY0zEkF/dns-query HTTP/2.0"	200	86	"-"	"Jigsaw-DNS/1.1.3"	"-"	"dns.bentasker.co.uk"	CACHE_-	0.005	debian-9-doh-newbuild	-

So, despite being sat "active" in the notification tray, Intra has been sat silently leaking my DNS queries since 22:35 UTC on 21 May (so, 6 days, give or take). That's dangerous....

2019-05-27 12:10:54
Ok, so had a look at Intra in developer options and in the broken state it showed 0 processes and 1 service (see screenshot).

When I then went into Intra, queries immediately started being recorded at the DoH server, and Developer tools showed Intra running 3 processes and 1 service (see other screenshot).

2019-05-27 12:10:54
btasker added 'Screenshot_2019-05-27-12-08-02-973_com.android.settings.png' to Attachments

2019-05-27 12:10:54
btasker added 'Screenshot_2019-05-27-12-08-57-767_com.android.settings.png' to Attachments

2019-05-27 12:25:36
So, my theory is that the OS is stopping the intra process in order to free up RAM.

To test that theory, I ran MIUI's "Clear Memory" app.

The result is that Intra's icon remains in the notifications bar, but we stop receiving queries at the DoH server. Developer Settings -> Running Services shows Intra in the same state as before (0 processes and 1 service).

So, either I've found another way to repro this, or the underlying issue is that MIUI's memory management results in a silent failure. For avoidance of doubt, looking in Developer Options the memory management settings are currently at

- Background process limit: Standard Limit
- Turn on MIUI Optimization

2019-05-27 12:28:16
So, although Xiaomi have made the process fairly unintuitive (unless you know what it is already), lets try "Locking" intra and then seeing if the issue recurs. The idea being that a locked process shouldn't be killed by memory management.

So

- Make sure Intra is running (i.e. go into it and come back out)
- press the task switcher button (little square at time of writing, used to be a hamburger menu)
- In the task switcher, hold down on Intra's window
- Three buttons should appear, one of which will be a padlock
- Press it
- In Task switcher Intra should now have a padlock next to it


2019-05-27 12:38:25
Ran Clear Memory again, and this time queries continued to hit the DoH server, and Intra's processes continue running in the Developer Options process list.

It looks hopeful, but need to wait and see now whether it silently breaks again.

As I noted here (https://twitter.com/bentasker/status/1129696593790291968) this is pretty concerning though. Intra was made for countries like China where even the smallest leakage could have major ramifications for the operator. Yet, on Chinese hardware, running Chinese software, made by one of China's most popular phone brands (Number 5 in 2018), Intra can silently fail and leak 100% of DNS queries for days.

Obviously, it's far less severe for me.

My leakage was mitigated by the fact I also had DoH/TRR configured in Firefox, so until this morning's testing the only queries (from my browsing) that would have leaked are where Firefox felt the query failed (so, NXDOMAIN or server unreachable). That's not without it's risk, but still a lot better than everything (and also avoidable by configuring network.trr.mode to 3 so there's no failover).

Which, actually, raises an interesting point in my mind. My intention had, ultimately, been to disable TRR in Firefox and let the system level DoH stub (in Android's case, Intra) handle queries, but this shows that that's not actually the wisest idea. As much as I personally dislike the idea of applications performing their own lookups, clearly it also acts as an important safety net against failures like this.

Even then, a double failure would be potentially severe (if less likely to occur).

2019-05-27 12:39:55
Ok, so before I close this out as fixed (pending a recurrence) there is one last thing I want to test quickly.

What will Intra's behaviour be if I (as a nefarious ISP) block it's access to the DoH server. Adding a firewall rule to do just that now...

2019-05-27 12:48:45
The behaviour there is sane.

Intra tries to connect out to the DoH server, fails, tries again and eventually resolution is just considered to have failed. There's no fallback to local so the query gets sent to your local UDP DNS servers.

So a malicious network operator blocking your DoH server won't cause Intra to start sending your queries to your local DNS server. That something at least...

2019-05-27 12:49:06
btasker changed Project from 'STAGING' to 'Miscellaneous'

2019-05-27 12:49:06
btasker changed Key from 'STGNG-11' to 'MISC-32'

2019-05-27 12:50:58
btasker added 'Ben Tasker' to assignee

2019-05-27 12:51:30
btasker added 'Android DNS-over-HTTPS DoH Intra Privacy Security' to labels

2019-05-27 13:01:37
btasker changed status from 'Open' to 'Resolved'

2019-05-27 13:01:37
btasker added 'Fixed' to resolution

2019-05-27 13:01:41
btasker changed status from 'Resolved' to 'Closed'

2019-05-28 01:00:58
I've written up an opinion piece based on this here - https://www.bentasker.co.uk/blog/privacy/460-an-argument-in-favour-of-application-level-name-resolution

2019-05-29 12:17:50
Have been out and about a bit this morning, so checked logs on the DoH server and can see my phone continued using it when on mobile-data as well as foreign networks.