Re: DOH (was: geolocation services disabled and Gnome maps)

[Celejar]

On Wed, 15 Apr 2020 07:49:28 -0400
Greg Wooledge  wrote:

> On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote:
> > On 4/14/20, Greg Wooledge  wrote:
> > > Accessing the mirrors via https makes the packages un-cacheable, which
> > > makes the traffic volume significantly greater -- and the package lists
> > > are already signed, so there's no gain in trustworthiness of the packages.
> > >
> > > Some people may cite "privacy", as in "I don't want them to know which
> > > window manager I use", or something... I do not understand this
> > > argument, frankly.  It sounds paranoid to me.
> > 
> > How about people that cite "security"?  And yes, I take the simplistic
> > approach that encrypted=good and clear-text=bad but clear-text allows
> > things like
> >   
> > https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers
> > 
> > my understanding is that vuln wouldn't have existed if https had been used.
> 
> That was a one-time bug, and was fixed quickly.  People have blown it
> way out of proportion.
> 
> The general answer for people who think "it's not https so it's not secure"
> is already given at .

As that site notes:

> However there may be other security benefits to using HTTPS for apt
> updates, in that it should greatly increase the difficulty for a
> man-in-the-middle attacker to exploit future bugs in APT, or to

IIUC, this is pretty much what happened to OpenWRT recently:

https://arstechnica.com/information-technology/2020/03/openwrt-is-vulnerable-to-attacks-that-execute-malicious-code/

They were using SHA2565 checksums to verify packages, not GPG signing,
but the vulnerability was caused by buggy code that allowed the hash
check to be bypassed, which I suppose could hit a GPG based system
as well ...

Celejar

Re: DOH (was: geolocation services disabled and Gnome maps)

[David Wright]

On Wed 15 Apr 2020 at 07:49:28 (-0400), Greg Wooledge wrote:
> On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote:
> > On 4/14/20, Greg Wooledge  wrote:
> > > Accessing the mirrors via https makes the packages un-cacheable, which
> > > makes the traffic volume significantly greater -- and the package lists
> > > are already signed, so there's no gain in trustworthiness of the packages.
> > >
> > > Some people may cite "privacy", as in "I don't want them to know which
> > > window manager I use", or something... I do not understand this
> > > argument, frankly.  It sounds paranoid to me.
> > 
> > How about people that cite "security"?  And yes, I take the simplistic
> > approach that encrypted=good and clear-text=bad but clear-text allows
> > things like
> >   
> > https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers
> > 
> > my understanding is that vuln wouldn't have existed if https had been used.

Looks like a sales pitch to me. (I didn't like their terms of use.)

> That was a one-time bug, and was fixed quickly.  People have blown it
> way out of proportion.
> 
> The general answer for people who think "it's not https so it's not secure"
> is already given at .

Cheers,
David.

Re: DOH (was: geolocation services disabled and Gnome maps)

[Greg Wooledge]

On Tue, Apr 14, 2020 at 07:12:47PM -0400, Lee wrote:
> On 4/14/20, Greg Wooledge  wrote:
> > Accessing the mirrors via https makes the packages un-cacheable, which
> > makes the traffic volume significantly greater -- and the package lists
> > are already signed, so there's no gain in trustworthiness of the packages.
> >
> > Some people may cite "privacy", as in "I don't want them to know which
> > window manager I use", or something... I do not understand this
> > argument, frankly.  It sounds paranoid to me.
> 
> How about people that cite "security"?  And yes, I take the simplistic
> approach that encrypted=good and clear-text=bad but clear-text allows
> things like
>   
> https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers
> 
> my understanding is that vuln wouldn't have existed if https had been used.

That was a one-time bug, and was fixed quickly.  People have blown it
way out of proportion.

The general answer for people who think "it's not https so it's not secure"
is already given at .

Re: DOH (was: geolocation services disabled and Gnome maps)

[Lee]

On 4/14/20, Greg Wooledge  wrote:
> On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
>> dnssec just adds a cryptographic signature to the data -- everything
>> is still done "in the clear" (like Debian updates.  or has buster
>> switched to using https for downloading updates?)
>
> The apt-transport-https package is available, but is not installed
> by default.  The Debian mirrors can be accessed via https, but again,
> this is not the default.  (I.e. even if you install apt-transport-https,
> you still have to edit sources.list to use it.)

*sigh* I wasn't able to get that working :(   This was right after I
installed Debian for the first time, so I was pretty much totally
clueless, but it was a compleat fail for me.

> Accessing the mirrors via https makes the packages un-cacheable, which
> makes the traffic volume significantly greater -- and the package lists
> are already signed, so there's no gain in trustworthiness of the packages.
>
> Some people may cite "privacy", as in "I don't want them to know which
> window manager I use", or something... I do not understand this
> argument, frankly.  It sounds paranoid to me.

How about people that cite "security"?  And yes, I take the simplistic
approach that encrypted=good and clear-text=bad but clear-text allows
things like
  
https://www.guardicore.com/2019/01/a-vulnerability-in-debians-apt-allows-for-easy-lateral-movement-in-data-centers

my understanding is that vuln wouldn't have existed if https had been used.

> I'd *love* to continue using http at work, but my workplace has been
> shutting down more and more plain http sites via their firewall.

Getting rid of clear-text protocols is usually at the top of network
audit checklists & with most people working from home now, it doesn't
surprise me at all that network security is being "improved".

> In the last few weeks, this includes the Debian mirrors.  So, I had to
> switch my work machines to https.  I really did not want to do that,
> because there are several of them, and now they can no longer share
> their package download bandwidth via a simple squid proxy.
>
> I'm not sure if I'll be willing to put the time into trying to come up
> with some other way to share downloads among them.

Yeah.. it's extremely frustrating when 'they' do stupid stuff 'because
security.'

But if you talk to the people in the security group about what's going
on -- if they'll talk to you at all - they've usually got at least a
semi-reasonable explanation for why.  (because the CIO said so being
the one that frustrated me the most)

Regards,
Lee

Re: DOH (was: geolocation services disabled and Gnome maps)

[Celejar]

On Tue, 14 Apr 2020 05:45:45 -0400
Lee  wrote:

> On 4/13/20, Celejar wrote:
> > On Mon, 13 Apr 2020 08:47:22 +0300
> > Reco  wrote:
> >
> >>Hi.
> >>
> >> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
> >
> > ...
> >
> >> > I just did a quick search and couldn't find anything for smart TVs
> >> > using DOH.
> >>
> >> Probably because they aren't there yet. A typical smart TV is based on
> >> the Android, and Google haven't said their word about DOH so far.
> >
> > I suppose you mean DoH specifically, as opposed to DNS over TLS (DoT),
> > but just to clarify for the record, they have implemented the latter:
> >
> > https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/
> > https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/
> >
> 
> Yes, DNS over HTTPS specifically is the concern.  DNS over TLS uses a
> specific port (that they could change, yeah, i know) that I have
> blocked, so I'm not all that concerned about DoT.

Ah, I think I understand. But if you're really worried about bad guys:

> > 3) Bad guys and gals can hijack DNS too, to the usual hilarious results.
> 
> And the bad guys and gals can use DOH to "hide" their traffic and
> circumvent things like pihole.  I just did a quick search and couldn't
> find anything for smart TVs using DOH.  Probably because my search
> skillz sux :(

why would they be limited by whatever the OS supports? Surely their
malware can easily include an internal DoH implementation, although I
suppose you'll at least be safer from malware that doesn't bother.

Celejar

Re: DOH (was: geolocation services disabled and Gnome maps)

[Andrei POPESCU]

On Ma, 14 apr 20, 07:32:58, Greg Wooledge wrote:
> On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
> > dnssec just adds a cryptographic signature to the data -- everything
> > is still done "in the clear" (like Debian updates.  or has buster
> > switched to using https for downloading updates?)
> 
> The apt-transport-https package is available, but is not installed
> by default.

Not required anymore (at least in buster).

$ apt show apt-transport-https
Package: apt-transport-https
Version: 1.8.2
[...]
Description: transitional package for https support
 This is a dummy transitional package - https support has been moved into
 the apt package in 1.5. It can be safely removed.


> The Debian mirrors can be accessed via https, but again,
> this is not the default.  (I.e. even if you install apt-transport-https,
> you still have to edit sources.list to use it.)

This is still applicable.

> Accessing the mirrors via https makes the packages un-cacheable, which
> makes the traffic volume significantly greater -- and the package lists
> are already signed, so there's no gain in trustworthiness of the packages.
> 
> Some people may cite "privacy", as in "I don't want them to know which
> window manager I use", or something... I do not understand this
> argument, frankly.  It sounds paranoid to me.

Some people might not want to advertise to the world they are using 
packages like weboob (only in stretch) :)

More seriously, there is the argument about using encryption even if not 
really needed in order to "hide" the cases where it is.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[Reco]

On Tue, Apr 14, 2020 at 07:06:05AM -0400, Lee wrote:
> >> Right.  The ISP can't see what names the user is looking up but
> >> Cloudflare sees every single one.  On the other hand, take a look at
> >>   https://wiki.mozilla.org/Security/DOH-resolver-policy
> >
> > An interesting declaration. For instance:
> >
> > 1. The resolver may retain user data (including identifiable data...)
> > but should do so only for the purpose of operating the service and
> > must not retain that data for longer than 24 hours.
> > ...
> > 2. Transparency Report. There must be a transparency report published at
> > least yearly that documents the policy for how the party operating the
> > resolver will handle law enforcement requests for user data and that
> > documents the types and number of requests received and answered, except
> > to the extent such disclosure is prohibited by law.
> >
> > Thus:
> >
> > a) Cloudflare is allowed to store whatever they want for 24 hours.
> > b) They aren't forbidden to give that data to the law enforcement, which
> > is not binded by that Mozilla’s Trusted Recursive Resolver program.
> 
> Maybe I'm being naive, but I'm taking the clause "except as may be
> required by law" to mean they can't just give the data to LE; there
> has to be some kind of court order compelling them to hand it over.

Probably. But I fail to see how a court order will prevent such data
leak in the described scenario.


> > c) Law enforcement entity hires some independent contractor to help them
> > store this data.
> > d) Next thing you know, everyone's DNS history is world-accessible via
> > some unprotected ElasticSearch instance on AWS.
> > e) And the best thing here is - Mozilla legally allowed it to happen.
> 
> Is there some other DNS provider that has a  published privacy policy?
>  That's anywhere near as good as CloudFlare's?

To be frank, then you have your own DNS, there's little need to be
interested in others' privacy policies.


> To be clear - I'm not saying you should trust CloudFlare.  It's just
> that I don't see a whole lot of options & quite possibly CloudFlare is
> more trustworthy than your USA ISP.

I disagree. Cloudflare serves 10-20% sites on the Internet world-wide
already. There's no need to trust them to do DNS resolution on the top
of it.


> Cool - so you would know the answer to this question: Is the chromium
> you build from source code **totally** built from source code you have
> with no binaries, libraries, DLLs, or anything else like that
> included?

I do it the same way as Debian does, from the same sources (but with the
custom patches on top on them).
So, chromium version 81.0.4044.92 contains:

1) 5412 assorted python scripts, which are executed during the build
process (maybe not all of them).
2) 16299 javascript files, but those are definitely not required by the
build process.

Since I do it for the Linux only, I could not care less if the source
tree contains EXEs, DLLs or other Windoze artifacts.
I'm definitely sure that there are no ELF executables there or pre-built
.so and .a files.
I should note, however, that Debian's chromium source is sanitized, and
certain parts of the source tree are deliberately removed.


> In other words, how trustworthy is your 'built from source code'
> chromium?  Have you done any testing to see if it "phones home"?

YES! In fact, I do it after every update (once a month on average), and
check periodically just for the fun of it.
The answer is - the only connections it does without my intervention are
"trial experiment downloads" (it's clients[0-9].google.com), so I'm
looking for a patch to disable *that* too (currently I'm merely blocking
it).

Check out [1] if you're interested, that patchset rocks. Combining it
with Debian chromium patches is an interesting exercise though.


> >> > As far as the "last mile" is concerned - maybe.
> >>
> >> How about as far as the "end user" is concerned? (which is what I
> >> thought we were talking about -- clueless end-users having doh forced
> >> on them)
> >
> > It's akin to the tempered glass. I.e. it's less likely to break than a
> > normal glass, but it's still transparent. It's also akin to building a
> > castle on a sand.
> >
> > I.e. if the user does not care about security it may improve overall
> > situation somewhat, but the cost of this improvement is privacy.
> 
> Do you live in the EU?

I won't answer that. Privacy.


> >> >> How many people use a dnssec validating resolver?
> >> >
> >> > See above. Besides, DNSSEC is for integrity of zones, not privacy.
> >> > You need DNS-over-TLS if you need last one.
> >>
> >> "integrity of zones" is part of "security" - yes?
> >
> > Yes. My point is that it's only a part of the security. A needed part,
> > but a part nevertheless.
> >
> >
> >> DoT or DoH - either one gets you privacy from your ISP
> >> DoT is easy to block, DoH is harder to block, so somewhat censorship
> >> resistant?

If it bothers you (it does bother me), you probably should not 

Re: DOH (was: geolocation services disabled and Gnome maps)

[Greg Wooledge]

On Tue, Apr 14, 2020 at 01:48:24PM +0200, n...@dismail.de wrote:
> On Tue, Apr 14, 2020 at 07:06:05 -0400, Lee wrote:
> > Is there some other DNS provider that has a  published privacy policy?
> >  That's anywhere near as good as CloudFlare's?
> > 
> > To be clear - I'm not saying you should trust CloudFlare.  It's just
> > that I don't see a whole lot of options & quite possibly CloudFlare is
> > more trustworthy than your USA ISP.
> 
> Some non-profit organisations here operate public non-logging[1] DNS servers.
> They all support DoT, only some support DoH.
> But none of them would have enough resources to serve all Firefox users in 
> the 
> world though.

I really don't understand the appeal of this approach on a Linux users'
mailing list.  The amount of technical knowledge and effort that it takes
to run your own caching resolver and point resolv.conf to 127.0.0.1 is
only *slightly* greater than the amount of technical knowledge and effort
that it takes to point resolv.conf to "some global caching resolver that
is like 8.8.8.8 but theoretically more trustworthy, maybe".

In both cases, the major issue is getting isc-dhcp-client and network-manager
and other such things to leave your resolv.conf the hell alone after
you edit it.  See  for help with
that.

Installing a caching resolver is pretty simple.  Editing /etc/resolv.conf
is likewise pretty simple, or *should* be for anyone on this mailing list.

Re: DOH (was: geolocation services disabled and Gnome maps)

[nito]

On Tue, Apr 14, 2020 at 07:06:05 -0400, Lee wrote:
> Is there some other DNS provider that has a  published privacy policy?
>  That's anywhere near as good as CloudFlare's?
> 
> To be clear - I'm not saying you should trust CloudFlare.  It's just
> that I don't see a whole lot of options & quite possibly CloudFlare is
> more trustworthy than your USA ISP.

Some non-profit organisations here operate public non-logging[1] DNS servers.
They all support DoT, only some support DoH.
But none of them would have enough resources to serve all Firefox users in the 
world though.

--- Nito

[1]: Only malformed queries are logged for diagnosis.

Re: DOH (was: geolocation services disabled and Gnome maps)

[Greg Wooledge]

On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
> dnssec just adds a cryptographic signature to the data -- everything
> is still done "in the clear" (like Debian updates.  or has buster
> switched to using https for downloading updates?)

The apt-transport-https package is available, but is not installed
by default.  The Debian mirrors can be accessed via https, but again,
this is not the default.  (I.e. even if you install apt-transport-https,
you still have to edit sources.list to use it.)

Accessing the mirrors via https makes the packages un-cacheable, which
makes the traffic volume significantly greater -- and the package lists
are already signed, so there's no gain in trustworthiness of the packages.

Some people may cite "privacy", as in "I don't want them to know which
window manager I use", or something... I do not understand this
argument, frankly.  It sounds paranoid to me.

I'd *love* to continue using http at work, but my workplace has been
shutting down more and more plain http sites via their firewall.
In the last few weeks, this includes the Debian mirrors.  So, I had to
switch my work machines to https.  I really did not want to do that,
because there are several of them, and now they can no longer share
their package download bandwidth via a simple squid proxy.

I'm not sure if I'll be willing to put the time into trying to come up
with some other way to share downloads among them.

Re: DOH (was: geolocation services disabled and Gnome maps)

[Lee]

On 4/14/20, Reco wrote:
>   Hi.

Hi

> On Mon, Apr 13, 2020 at 06:42:10PM -0400, Lee wrote:
>> On 4/13/20, Reco  wrote:
>> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>> >> > The questionable idea behind DOH is that the browser makers do not
>> >> > trust
>> >> > your local resolver.
>> >>
>> >> Mozilla claims it's a privacy issue:
>> >> https://support.mozilla.org/en-US/kb/firefox-dns-over-https
>> >
>> > It's a privacy issue along with the other things.
>> > With the default settings the Firefox user is handing all DNS
>> > resolution
>> > to Cloudflare. Not an equivalent to complete browsing history, but
>> > close
>> > enough.
>>
>> Right.  The ISP can't see what names the user is looking up but
>> Cloudflare sees every single one.  On the other hand, take a look at
>>   https://wiki.mozilla.org/Security/DOH-resolver-policy
>
> An interesting declaration. For instance:
>
> 1. The resolver may retain user data (including identifiable data...)
> but should do so only for the purpose of operating the service and
> must not retain that data for longer than 24 hours.
> ...
> 2. Transparency Report. There must be a transparency report published at
> least yearly that documents the policy for how the party operating the
> resolver will handle law enforcement requests for user data and that
> documents the types and number of requests received and answered, except
> to the extent such disclosure is prohibited by law.
>
>
> Thus:
>
> a) Cloudflare is allowed to store whatever they want for 24 hours.
> b) They aren't forbidden to give that data to the law enforcement, which
> is not binded by that Mozilla’s Trusted Recursive Resolver program.

Maybe I'm being naive, but I'm taking the clause "except as may be
required by law" to mean they can't just give the data to LE; there
has to be some kind of court order compelling them to hand it over.

> c) Law enforcement entity hires some independent contractor to help them
> store this data.
> d) Next thing you know, everyone's DNS history is world-accessible via
> some unprotected ElasticSearch instance on AWS.
> e) And the best thing here is - Mozilla legally allowed it to happen.

Is there some other DNS provider that has a  published privacy policy?
 That's anywhere near as good as CloudFlare's?

To be clear - I'm not saying you should trust CloudFlare.  It's just
that I don't see a whole lot of options & quite possibly CloudFlare is
more trustworthy than your USA ISP.

>> >> If firefox wasn't a viable alternative to chrome, what are the chances
>> >> that change would have been implemented?
>> >
>> > It is implemented already, it's just there are alternatives to
>> > declarativeNetRequest that are working - so far.
>>
>> Ahh.  I thought Google backed down on the change..
>
> I happen to build chromium from the source from time to time. Recent
> versions (>=80) require re2 regex library just for declarativeNetRequest
> alone.

Cool - so you would know the answer to this question: Is the chromium
you build from source code **totally** built from source code you have
with no binaries, libraries, DLLs, or anything else like that
included?

In other words, how trustworthy is your 'built from source code'
chromium?  Have you done any testing to see if it "phones home"?

>> >> > With the advent of HTTPS all this may be seen as moot points (if
>> >> > you're
>> >> > redirected elsewhere the certificate validation should fail), but
>> >> > nevertheless DOH is forced upon the collective throat of Firefox
>> >> > users
>> >> > as we speak (and Chrome users are likely to follow them Soon™).
>> >> > Currently a Firefox user is supposed to trust Cloudflare to do DNS
>> >> > queries for them, and HTTPS is used for this purpose because
>> >> > Security™.
>> >>
>> >> For some values of "security", DOH _is_ more secure.
>> >
>> > As far as the "last mile" is concerned - maybe.
>>
>> How about as far as the "end user" is concerned? (which is what I
>> thought we were talking about -- clueless end-users having doh forced
>> on them)
>
> It's akin to the tempered glass. I.e. it's less likely to break than a
> normal glass, but it's still transparent. It's also akin to building a
> castle on a sand.
>
> I.e. if the user does not care about security it may improve overall
> situation somewhat, but the cost of this improvement is privacy.

Do you live in the EU?

Not everyone has the ability or inclination to do things like run
their own resolver or build chromium from source.  It's possible FF
enabling DOH is an improvement for most of their users.

>> >> How many people use a dnssec validating resolver?
>> >
>> > See above. Besides, DNSSEC is for integrity of zones, not privacy.
>> > You need DNS-over-TLS if you need last one.
>>
>> "integrity of zones" is part of "security" - yes?
>
> Yes. My point is that it's only a part of the security. A needed part,
> but a part nevertheless.
>
>
>> DoT or DoH - either one gets you privacy from your ISP
>> DoT is easy to block, 

Re: DOH (was: geolocation services disabled and Gnome maps)

[Lee]

On 4/13/20, Celejar wrote:
> On Mon, 13 Apr 2020 08:47:22 +0300
> Reco  wrote:
>
>>  Hi.
>>
>> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>
> ...
>
>> > I just did a quick search and couldn't find anything for smart TVs
>> > using DOH.
>>
>> Probably because they aren't there yet. A typical smart TV is based on
>> the Android, and Google haven't said their word about DOH so far.
>
> I suppose you mean DoH specifically, as opposed to DNS over TLS (DoT),
> but just to clarify for the record, they have implemented the latter:
>
> https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/
> https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/
>

Yes, DNS over HTTPS specifically is the concern.  DNS over TLS uses a
specific port (that they could change, yeah, i know) that I have
blocked, so I'm not all that concerned about DoT.

Regards,
Lee

Re: DOH (was: geolocation services disabled and Gnome maps)

[tomas]

On Mon, Apr 13, 2020 at 07:03:12PM -0400, Lee wrote:
> On 4/13/20, tomas wrote:
> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:

[...]

> Agreed.  But how many home users have a local sys admin?  That knows
> how to configure the local resolver?
> 
> OK .. on this list, probably most.  But *nix users are what percentage
> of all users?

I think "percentage" is important. But in the first place, we
are here to make this *possible* at all!

Otherwise we get 0%.

Increasing percentage (aka education) is, of course, as important.

Cheers
-- t


signature.asc
Description: Digital signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[Reco]

Hi.

On Mon, Apr 13, 2020 at 06:42:10PM -0400, Lee wrote:
> On 4/13/20, Reco  wrote:
> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
> >> > The questionable idea behind DOH is that the browser makers do not
> >> > trust
> >> > your local resolver.
> >>
> >> Mozilla claims it's a privacy issue:
> >> https://support.mozilla.org/en-US/kb/firefox-dns-over-https
> >
> > It's a privacy issue along with the other things.
> > With the default settings the Firefox user is handing all DNS resolution
> > to Cloudflare. Not an equivalent to complete browsing history, but close
> > enough.
> 
> Right.  The ISP can't see what names the user is looking up but
> Cloudflare sees every single one.  On the other hand, take a look at
>   https://wiki.mozilla.org/Security/DOH-resolver-policy

An interesting declaration. For instance:

1. The resolver may retain user data (including identifiable data...)
but should do so only for the purpose of operating the service and
must not retain that data for longer than 24 hours.
...
2. Transparency Report. There must be a transparency report published at
least yearly that documents the policy for how the party operating the
resolver will handle law enforcement requests for user data and that
documents the types and number of requests received and answered, except
to the extent such disclosure is prohibited by law.


Thus:

a) Cloudflare is allowed to store whatever they want for 24 hours.
b) They aren't forbidden to give that data to the law enforcement, which
is not binded by that Mozilla’s Trusted Recursive Resolver program.
c) Law enforcement entity hires some independent contractor to help them
store this data.
d) Next thing you know, everyone's DNS history is world-accessible via
some unprotected ElasticSearch instance on AWS.
e) And the best thing here is - Mozilla legally allowed it to happen.


> >> If firefox wasn't a viable alternative to chrome, what are the chances
> >> that change would have been implemented?
> >
> > It is implemented already, it's just there are alternatives to
> > declarativeNetRequest that are working - so far.
> 
> Ahh.  I thought Google backed down on the change..

I happen to build chromium from the source from time to time. Recent
versions (>=80) require re2 regex library just for declarativeNetRequest
alone.


> >> > With the advent of HTTPS all this may be seen as moot points (if you're
> >> > redirected elsewhere the certificate validation should fail), but
> >> > nevertheless DOH is forced upon the collective throat of Firefox users
> >> > as we speak (and Chrome users are likely to follow them Soon™).
> >> > Currently a Firefox user is supposed to trust Cloudflare to do DNS
> >> > queries for them, and HTTPS is used for this purpose because Security™.
> >>
> >> For some values of "security", DOH _is_ more secure.
> >
> > As far as the "last mile" is concerned - maybe.
> 
> How about as far as the "end user" is concerned? (which is what I
> thought we were talking about -- clueless end-users having doh forced
> on them)

It's akin to the tempered glass. I.e. it's less likely to break than a
normal glass, but it's still transparent. It's also akin to building a
castle on a sand.

I.e. if the user does not care about security it may improve overall
situation somewhat, but the cost of this improvement is privacy.


> >> How many people use a dnssec validating resolver?
> >
> > See above. Besides, DNSSEC is for integrity of zones, not privacy.
> > You need DNS-over-TLS if you need last one.
> 
> "integrity of zones" is part of "security" - yes?

Yes. My point is that it's only a part of the security. A needed part,
but a part nevertheless.


> DoT or DoH - either one gets you privacy from your ISP
> DoT is easy to block, DoH is harder to block, so somewhat censorship 
> resistant?

Both are easily blocked in their current form, in fact, DoH is easier in
this regard - it makes very distinct HTTPS (i.e. tcp:443) queries to a
ten (at most) well-known IPs.


> >> At least Cloudflare resolvers have dnssec enabled.
> >
> > *And* the ability to see users' DNS queries. Neat, right?
> 
> Yup, and probably a net win for people that don't have a clue about
> dns .. or at least people in the US.  Do people in the EU have to
> worry about their ISP selling their usage data?

No. You do not worry about something that widely happens, you deal with
it one way or another. And it's possible to sidestep GDPR just by
injecting "trusted partners'" ads in users' HTTP traffic, for instance.

Reco

Re: DOH (was: geolocation services disabled and Gnome maps)

[Celejar]

On Mon, 13 Apr 2020 08:47:22 +0300
Reco  wrote:

>   Hi.
> 
> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:

...

> > I just did a quick search and couldn't find anything for smart TVs
> > using DOH.
> 
> Probably because they aren't there yet. A typical smart TV is based on
> the Android, and Google haven't said their word about DOH so far.

I suppose you mean DoH specifically, as opposed to DNS over TLS (DoT),
but just to clarify for the record, they have implemented the latter:

https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/
https://www.techrepublic.com/article/how-to-enable-dns-over-tls-in-android-pie/

Celejar

Re: DOH (was: geolocation services disabled and Gnome maps)

[Lee]

On 4/13/20, tomas wrote:
> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>
> [...]
>
>> Mozilla claims it's a privacy issue:
>> https://support.mozilla.org/en-US/kb/firefox-dns-over-https
>>   Benefits
>
> Yes, sure [1], but *not in each and every friggin' application*.

I prefer apps that don't "phone home".

> It'd be OK for the local DNS caching resolver to forward its
> queries to some DOH responder "out there", *configurable by
> the local sys admin. Locally, you have the same posibilities
> (resolv.conf, nsswitch, hosts).

Agreed.  But how many home users have a local sys admin?  That knows
how to configure the local resolver?

OK .. on this list, probably most.  But *nix users are what percentage
of all users?

> [1] I know. Even with DNSSEC, your ISP can see it /is/ DNS
>traffic,

dnssec just adds a cryptographic signature to the data -- everything
is still done "in the clear" (like Debian updates.  or has buster
switched to using https for downloading updates?)

> whereas they have given up (have they)? on sniffing  https.

not that I've heard.  There's something coming Real Soon Now that will
prevent ISPs from seeing the name of the server you're connecting to
but I don't remember what it's called right now :(

Regards
Lee

Re: DOH (was: geolocation services disabled and Gnome maps)

[Lee]

On 4/13/20, Reco  wrote:
>   Hi.

Hi

> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
>> > The questionable idea behind DOH is that the browser makers do not
>> > trust
>> > your local resolver.
>>
>> Mozilla claims it's a privacy issue:
>> https://support.mozilla.org/en-US/kb/firefox-dns-over-https
>
> It's a privacy issue along with the other things.
> With the default settings the Firefox user is handing all DNS resolution
> to Cloudflare. Not an equivalent to complete browsing history, but close
> enough.

Right.  The ISP can't see what names the user is looking up but
Cloudflare sees every single one.  On the other hand, take a look at
  https://wiki.mozilla.org/Security/DOH-resolver-policy

Not that I understand my ISP's privacy policy, but I don't see anything like
  [will not] sell, license, sublicense, or grant any rights to user data to
  any other person or entity.
in my ISP's privacy policy.  So at least in that sense, handing my
data to Cloudflare is better than letting my ISP have it.

>> > 1) One can use a local resolver with the ability *not* to resolve
>> > certain DNS queries, which refer to the sites which just happen to
>> > contain advertisements, fingerprinting, tracking, cryptomining etc.
>> > Since all two major browser makers (Google and Mozilla) happen to rely
>> > on revenue generated by advertising *and* users' browsing habits this
>> > obviously can not be tolerated.
>>
>> Wasn't there a fairly recent kerfluffle about an upcoming change to
>> chrome that would break things like the uMatrix addon?
>
> There was, indeed.
>
>
>> If firefox wasn't a viable alternative to chrome, what are the chances
>> that change would have been implemented?
>
> It is implemented already, it's just there are alternatives to
> declarativeNetRequest that are working - so far.

Ahh.  I thought Google backed down on the change..
I don't use chrome, so I don't follow what they're doing other than
reading the occasional news article.

>> > 3) Bad guys and gals can hijack DNS too, to the usual hilarious
>> > results.
>>
>> And the bad guys and gals can use DOH to "hide" their traffic and
>> circumvent things like pihole.
>
> There is tor or i2p for *that* already.

Right.  Again :)

>> I just did a quick search and couldn't find anything for smart TVs
>> using DOH.
>
> Probably because they aren't there yet. A typical smart TV is based on
> the Android, and Google haven't said their word about DOH so far.
>
>
>> > With the advent of HTTPS all this may be seen as moot points (if you're
>> > redirected elsewhere the certificate validation should fail), but
>> > nevertheless DOH is forced upon the collective throat of Firefox users
>> > as we speak (and Chrome users are likely to follow them Soon™).
>> > Currently a Firefox user is supposed to trust Cloudflare to do DNS
>> > queries for them, and HTTPS is used for this purpose because Security™.
>>
>> For some values of "security", DOH _is_ more secure.
>
> As far as the "last mile" is concerned - maybe.

How about as far as the "end user" is concerned? (which is what I
thought we were talking about -- clueless end-users having doh forced
on them)

> As far as the whole
> Internet goes - not so much as overall security of DNS queries depends
> of DNSSEC implemented in every zone (and it ain't there yet).

Unfortunately, yes.  DNSSEC adoption is way below where I was hoping it'd be.

>> How many people use a dnssec validating resolver?
>
> See above. Besides, DNSSEC is for integrity of zones, not privacy.
> You need DNS-over-TLS if you need last one.

"integrity of zones" is part of "security" - yes?
DoT or DoH - either one gets you privacy from your ISP
DoT is easy to block, DoH is harder to block, so somewhat censorship resistant?

>> At least Cloudflare resolvers have dnssec enabled.
>
> *And* the ability to see users' DNS queries. Neat, right?

Yup, and probably a net win for people that don't have a clue about
dns .. or at least people in the US.  Do people in the EU have to
worry about their ISP selling their usage data?

Regards,
Lee

Re: DOH (was: geolocation services disabled and Gnome maps)

[Liam O'Toole]

On Mon, 13 Apr, 2020 at 16:19:55 +0300, Reco wrote:
> On Mon, Apr 13, 2020 at 12:14:44PM +0100, Liam O'Toole wrote:
> > On Mon, 13 Apr, 2020 at 12:57:54 +0300, Reco wrote:
> > >   Hi.
> > > 
> > > On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:
> > 
> > [...]
> > 
> > > > Whether DoH or DNS-over-TLS, you have to trust the DNS server.
> > > 
> > > Yup. That's why I have my own, and every Debian user can have their own
> > > too, using only free software.
> > > 
> > 
> > Pray tell us more. I use dnsmasq for clients on my LAN, but even that
> > has to use an upstream name server --- in my case the one provided by my
> > ISP.
> 
> 1) Rent yourself a VPS, install bind there (there's no DNS but bind).
> Replace bind with unbound if you need caching-only nameserver
> (caching-only bind is possible, but it's an overkill).
> 
> 2) Apply [1] to your dnsmasq.
> 
> 3) Your ISP gets a TLS tunneled DNS request (and they can't do anything
> about it), you get unmolested name resolution.
> 

[...]

Thanks for the detailed information.

I'm not familiar with bind. Does it work by consulting root name servers
directly?

Re: DOH (was: geolocation services disabled and Gnome maps)

[Reco]

On Mon, Apr 13, 2020 at 12:14:44PM +0100, Liam O'Toole wrote:
> On Mon, 13 Apr, 2020 at 12:57:54 +0300, Reco wrote:
> > Hi.
> > 
> > On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:
> 
> [...]
> 
> > > Whether DoH or DNS-over-TLS, you have to trust the DNS server.
> > 
> > Yup. That's why I have my own, and every Debian user can have their own
> > too, using only free software.
> > 
> 
> Pray tell us more. I use dnsmasq for clients on my LAN, but even that
> has to use an upstream name server --- in my case the one provided by my
> ISP.

1) Rent yourself a VPS, install bind there (there's no DNS but bind).
Replace bind with unbound if you need caching-only nameserver
(caching-only bind is possible, but it's an overkill).

2) Apply [1] to your dnsmasq.

3) Your ISP gets a TLS tunneled DNS request (and they can't do anything
about it), you get unmolested name resolution.

stunnel can be replaced with ipsec or openvpn or wireguard.
Whatever you use as a caching DNS on your end does not matter, as long
as it can forward DNS queries to another upstream DNS.

Reco

[1] https://kb.isc.org/docs/aa-01386

Re: DOH (was: geolocation services disabled and Gnome maps)

[Liam O'Toole]

On Mon, 13 Apr, 2020 at 12:57:54 +0300, Reco wrote:
>   Hi.
> 
> On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:

[...]

> > Whether DoH or DNS-over-TLS, you have to trust the DNS server.
> 
> Yup. That's why I have my own, and every Debian user can have their own
> too, using only free software.
> 

Pray tell us more. I use dnsmasq for clients on my LAN, but even that
has to use an upstream name server --- in my case the one provided by my
ISP.

Re: DOH (was: geolocation services disabled and Gnome maps)

[tomas]

On Mon, Apr 13, 2020 at 12:57:54PM +0300, Reco wrote:
>   Hi.
> 
> On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:

[...]

> Yup. That's why I have my own, and every Debian user can have their own
> too, using only free software.

...and that is why I want the apps on my box to take my DNS and not
theirs [1].

Cheers

[1] "theirs" being the one their developers deemed the right one for
   me.
-- t


signature.asc
Description: Digital signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[Reco]

Hi.

On Mon, Apr 13, 2020 at 11:16:02AM +0300, Andrei POPESCU wrote:
> On Lu, 13 apr 20, 08:47:22, Reco wrote:
> > On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
> > 
> > > How many people use a dnssec validating resolver?
> > 
> > See above. Besides, DNSSEC is for integrity of zones, not privacy.
> > You need DNS-over-TLS if you need last one.
> > 
> > 
> > > At least Cloudflare resolvers have dnssec enabled.
> > 
> > *And* the ability to see users' DNS queries. Neat, right?
> 
> Whether DoH or DNS-over-TLS, you have to trust the DNS server.

Yup. That's why I have my own, and every Debian user can have their own
too, using only free software.

Reco

Re: DOH (was: geolocation services disabled and Gnome maps)

[Andrei POPESCU]

On Lu, 13 apr 20, 08:47:22, Reco wrote:
> On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
> 
> > How many people use a dnssec validating resolver?
> 
> See above. Besides, DNSSEC is for integrity of zones, not privacy.
> You need DNS-over-TLS if you need last one.
> 
> 
> > At least Cloudflare resolvers have dnssec enabled.
> 
> *And* the ability to see users' DNS queries. Neat, right?

Whether DoH or DNS-over-TLS, you have to trust the DNS server.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[tomas]

On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:

[...]

> Mozilla claims it's a privacy issue:
> https://support.mozilla.org/en-US/kb/firefox-dns-over-https
>   Benefits

Yes, sure [1], but *not in each and every friggin' application*.

It'd be OK for the local DNS caching resolver to forward its
queries to some DOH responder "out there", *configurable by
the local sys admin. Locally, you have the same posibilities
(resolv.conf, nsswitch, hosts).

But letting an app bypass that, to some Mozilla-blessed DOH
service is *not nice*.

Just imagine your solitaire game had its very own way of doing
name resolving.

Cheers
[1] I know. Even with DNSSEC, your ISP can see it /is/ DNS
   traffic, whereas they have given up (have they)? on sniffing
   https.

-- tomás


signature.asc
Description: Digital signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[Reco]

Hi.

On Sun, Apr 12, 2020 at 07:46:38PM -0400, Lee wrote:
> > The questionable idea behind DOH is that the browser makers do not trust
> > your local resolver.
> 
> Mozilla claims it's a privacy issue:
> https://support.mozilla.org/en-US/kb/firefox-dns-over-https

It's a privacy issue along with the other things.
With the default settings the Firefox user is handing all DNS resolution
to Cloudflare. Not an equivalent to complete browsing history, but close
enough.


> > 1) One can use a local resolver with the ability *not* to resolve
> > certain DNS queries, which refer to the sites which just happen to
> > contain advertisements, fingerprinting, tracking, cryptomining etc.
> > Since all two major browser makers (Google and Mozilla) happen to rely
> > on revenue generated by advertising *and* users' browsing habits this
> > obviously can not be tolerated.
> 
> Wasn't there a fairly recent kerfluffle about an upcoming change to
> chrome that would break things like the uMatrix addon?

There was, indeed.


> If firefox wasn't a viable alternative to chrome, what are the chances
> that change would have been implemented?

It is implemented already, it's just there are alternatives to
declarativeNetRequest that are working - so far.


> > 3) Bad guys and gals can hijack DNS too, to the usual hilarious results.
> 
> And the bad guys and gals can use DOH to "hide" their traffic and
> circumvent things like pihole.

There is tor or i2p for *that* already.


> I just did a quick search and couldn't find anything for smart TVs
> using DOH.

Probably because they aren't there yet. A typical smart TV is based on
the Android, and Google haven't said their word about DOH so far.


> > With the advent of HTTPS all this may be seen as moot points (if you're
> > redirected elsewhere the certificate validation should fail), but
> > nevertheless DOH is forced upon the collective throat of Firefox users
> > as we speak (and Chrome users are likely to follow them Soon™).
> > Currently a Firefox user is supposed to trust Cloudflare to do DNS
> > queries for them, and HTTPS is used for this purpose because Security™.
> 
> For some values of "security", DOH _is_ more secure.

As far as the "last mile" is concerned - maybe. As far as the whole
Internet goes - not so much as overall security of DNS queries depends
of DNSSEC implemented in every zone (and it ain't there yet).


> How many people use a dnssec validating resolver?

See above. Besides, DNSSEC is for integrity of zones, not privacy.
You need DNS-over-TLS if you need last one.


> At least Cloudflare resolvers have dnssec enabled.

*And* the ability to see users' DNS queries. Neat, right?

Reco

Re: DOH (was: geolocation services disabled and Gnome maps)

[Lee]

On 4/12/20, Reco  wrote:
> On Sun, Apr 12, 2020 at 12:35:44PM +0200, to...@tuxteam.de wrote:
>> On Sun, Apr 12, 2020 at 01:21:08PM +0300, Reco wrote:
>> > On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
>> > > That's why I cringe at the idea that browsers want to start doing
>> > > name resolution over HTTPS.
>> >
>> > This simple one line of dnsmasq configuration will disable this
>> > problematic feature for good for Firefox (basically it creates a bogus
>> > NXDOMAIN response for this particular site):
>> >
>> > local=/use-application-dns.net/
>>
>> I don't quite understand [1] how the dnsmasq config has a say on
>> whether the browser resolves things over HTTP (it won't ask the
>> resolver in the first place, would it?), but thanks for the pointer
>> anyway.
>>
>> Cheers
>> [1] That's not a rhethorical flourish, it's genuine. I know too
>>little about DNS-over-HTTP to be of any use at this point.
>
> The questionable idea behind DOH is that the browser makers do not trust
> your local resolver.

Mozilla claims it's a privacy issue:
https://support.mozilla.org/en-US/kb/firefox-dns-over-https
  Benefits
DoH improves privacy by hiding domain name lookups from someone
lurking on public WiFi, your ISP, or anyone else on your local
network. DoH, when enabled, ensures that your ISP cannot collect and
sell personal information related to your browsing behavior.

Altho I suspect "cannot" should be changed to "has a slightly harder time to"

> As usual, main arguments here are:
>
> 1) One can use a local resolver with the ability *not* to resolve
> certain DNS queries, which refer to the sites which just happen to
> contain advertisements, fingerprinting, tracking, cryptomining etc.
> Since all two major browser makers (Google and Mozilla) happen to rely
> on revenue generated by advertising *and* users' browsing habits this
> obviously can not be tolerated.

Wasn't there a fairly recent kerfluffle about an upcoming change to
chrome that would break things like the uMatrix addon? hrmm...  ok,
found it
https://bugs.chromium.org/p/chromium/issues/detail?id=896897=2#c23
  If this (quite limited) declarativeNetRequest API ends up being the
only way content blockers can accomplish their duty, this essentially
means that two content blockers I have maintained for years, uBlock
Origin ("uBO") and uMatrix, can no longer exist.

If firefox wasn't a viable alternative to chrome, what are the chances
that change would have been implemented?


> 2) ISPs can intercept DNS queries, and modify them at their leisure.
> Usually considered a first step to a censorship, implemented in this
> particular form at certain European countries.

along with ISPs can monitor DNS queries and sell the info.

https://www.vice.com/en_us/article/9kembz/comcast-lobbying-against-doh-dns-over-https-encryption-browsing-data
  Ellen Canale, director of corporate communications at Mozilla, wrote
in an email, "This is part of a pretty aggressive campaign we've seen
from the ISPs to protect their control over DNS traffic and the
tracking opportunities it provides them."

> 3) Bad guys and gals can hijack DNS too, to the usual hilarious results.

And the bad guys and gals can use DOH to "hide" their traffic and
circumvent things like pihole.  I just did a quick search and couldn't
find anything for smart TVs using DOH.  Probably because my search
skillz sux :(

> With the advent of HTTPS all this may be seen as moot points (if you're
> redirected elsewhere the certificate validation should fail), but
> nevertheless DOH is forced upon the collective throat of Firefox users
> as we speak (and Chrome users are likely to follow them Soon™).
> Currently a Firefox user is supposed to trust Cloudflare to do DNS
> queries for them, and HTTPS is used for this purpose because Security™.

For some values of "security", DOH _is_ more secure.  How many people
use a dnssec validating resolver?  At least Cloudflare resolvers have
dnssec enabled.

^shrug^ there's lots of trade-offs to be made in this area.  I'm
certainly not a fan of DOH and I do my best to block it on my
network..  I just think there are some privacy/security arguments for
DOH that you're minimizing.

Regards,
Lee

Re: DOH (was: geolocation services disabled and Gnome maps)

[Gene Heskett]

On Sunday 12 April 2020 09:39:09 to...@tuxteam.de wrote:

> On Sun, Apr 12, 2020 at 07:33:51AM -0400, Gene Heskett wrote:
>
> [...]
>
> > I don't either, but at some point in an https environment, it seems
> > to me that a dns lookup is going to have to be translated into a
> > plain dns lookup.
>
> No, that's not how it works. When the browser wants to resolve a
> name, it doesn't "do" DNS (when it's doing DOH, that is) but uses
> some "web-service-ish" protocol over https to some server out there
> (cloudflare, e.g.) which does the resolution and answers via https.
>
> Thus bypassing whatever scheme the sysadmin has set up for DNS.
>
> I don't have polite words for that.
>
Neither do I, and it WILL BE EXPLOITED. Linux has been such a breath of 
fresh air when I found it in late 1998, that I've forgotten a monologue, 
about 4 or 5 minutes long I used in my early dealings with Nt-3.51 and 
its random deletions of important dll's that M$ used to make you buy a 
new license.  Once, I might have been gullible enough to buy it, but at 
$600 for a new license twice in 2 years time on 2 different machines the 
same dll just vanished has to be malicious. But the crowning blow was 
when somebody in Redmond had the chutzpah to call me a pie-rat because I 
wanted a floppy fedexed to me with just that library on it. Screw em, 
and the camel that rode in on them...

> Cheers
> -- t


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: DOH (was: geolocation services disabled and Gnome maps)

[tomas]

On Sun, Apr 12, 2020 at 01:34:07PM +0100, Tixy wrote:
> On Sun, 2020-04-12 at 13:21 +0300, Reco wrote:
> > On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> > > That's why I cringe at the idea that browsers want to start doing
> > > name resolution over HTTPS.
> > 
> > This simple one line of dnsmasq configuration will disable this
> > problematic feature for good for Firefox (basically it creates a
> > bogus
> > NXDOMAIN response for this particular site):
> > 
> > local=/use-application-dns.net/
> > 
> 
> Technically, that doesn't disable it, just just disables any 'on by
> default' DoH [1]. For individual users worried about this, it would be
> simpler not to accept it when Firefox asks to enable it, or to disable
> it it with a config option. [2] That would be needed to be done anyway
> for mobile devices that can roam to different networks.
> 
> [1] https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet
> [2] https://support.mozilla.org/en-US/kb/firefox-dns-over-https

Yep. That sounds less fragile. Thanks.

Cheers
-- t


signature.asc
Description: Digital signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[tomas]

On Sun, Apr 12, 2020 at 07:33:51AM -0400, Gene Heskett wrote:

[...]

> I don't either, but at some point in an https environment, it seems to me 
> that a dns lookup is going to have to be translated into a plain dns 
> lookup.

No, that's not how it works. When the browser wants to resolve a
name, it doesn't "do" DNS (when it's doing DOH, that is) but uses
some "web-service-ish" protocol over https to some server out there
(cloudflare, e.g.) which does the resolution and answers via https.

Thus bypassing whatever scheme the sysadmin has set up for DNS.

I don't have polite words for that.

Cheers
-- t


signature.asc
Description: Digital signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[tomas]

On Sun, Apr 12, 2020 at 02:03:55PM +0300, Reco wrote:
> On Sun, Apr 12, 2020 at 12:35:44PM +0200, to...@tuxteam.de wrote:

[...]

> > [1] That's not a rhethorical flourish, it's genuine. I know too
> >little about DNS-over-HTTP to be of any use at this point.
> 
> The questionable idea behind DOH is that the browser makers do not trust
> your local resolver. As usual, main arguments here are:

[...]

Ah, OK. Thanks. Sounds a bit... fragile.

Now I know a bit more!

Cheers
-- t


signature.asc
Description: Digital signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[Tixy]

On Sun, 2020-04-12 at 13:21 +0300, Reco wrote:
> On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> > That's why I cringe at the idea that browsers want to start doing
> > name resolution over HTTPS.
> 
> This simple one line of dnsmasq configuration will disable this
> problematic feature for good for Firefox (basically it creates a
> bogus
> NXDOMAIN response for this particular site):
> 
> local=/use-application-dns.net/
> 

Technically, that doesn't disable it, just just disables any 'on by
default' DoH [1]. For individual users worried about this, it would be
simpler not to accept it when Firefox asks to enable it, or to disable
it it with a config option. [2] That would be needed to be done anyway
for mobile devices that can roam to different networks.

[1] https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet
[2] https://support.mozilla.org/en-US/kb/firefox-dns-over-https

-- 
Tixy

Re: DOH (was: geolocation services disabled and Gnome maps)

[Gene Heskett]

On Sunday 12 April 2020 06:35:44 to...@tuxteam.de wrote:

> On Sun, Apr 12, 2020 at 01:21:08PM +0300, Reco wrote:
> > On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> > > That's why I cringe at the idea that browsers want to start doing
> > > name resolution over HTTPS.
> >
> > This simple one line of dnsmasq configuration will disable this
> > problematic feature for good for Firefox (basically it creates a
> > bogus NXDOMAIN response for this particular site):
> >
> > local=/use-application-dns.net/
>
> I don't quite understand [1] how the dnsmasq config has a say on
> whether the browser resolves things over HTTP (it won't ask the
> resolver in the first place, would it?), but thanks for the pointer
> anyway.
>
> Cheers
> [1] That's not a rhethorical flourish, it's genuine. I know too
>little about DNS-over-HTTP to be of any use at this point.
>
> -- tomás

I don't either, but at some point in an https environment, it seems to me 
that a dns lookup is going to have to be translated into a plain dns 
lookup.  Perhaps I'm being dense but I am not personally aware of an 
encrypted to https protocol for dns lookups. I have no such facility 
here in my two stage resolver that I've been aware of, but https Just 
Works.

But density is relative, in a recent thread asking about installing  more 
memory, it was said that he had started with a 4GB stick and that the op 
was adding another 8Gb stick. In my experience thats doomed to run at 
half speed because the two sticks don't match.  Yet no one mentioned 
that with matching sticks, memory can be accessed at double speed, 
alternating between matching sticks by reading even addresses 
interleaved with reading odd addresses.  With dis-similar sizes, this 
interleaving of addresses cannot be done. Sequential reads are the 
forced into half speed reads because of the memory's recovery speeds.  

Rule of thumb then is installing memory as pairs but consult the 
motherboards docs to find out if pairs are slots 0 and 1, or 0 and 2. 
Yet no on mentioned that effect on speed in that whole thread.  Shame on 
us.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: DOH (was: geolocation services disabled and Gnome maps)

[Reco]

On Sun, Apr 12, 2020 at 12:35:44PM +0200, to...@tuxteam.de wrote:
> On Sun, Apr 12, 2020 at 01:21:08PM +0300, Reco wrote:
> > On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> > > That's why I cringe at the idea that browsers want to start doing
> > > name resolution over HTTPS.
> > 
> > This simple one line of dnsmasq configuration will disable this
> > problematic feature for good for Firefox (basically it creates a bogus
> > NXDOMAIN response for this particular site):
> > 
> > local=/use-application-dns.net/
> 
> I don't quite understand [1] how the dnsmasq config has a say on
> whether the browser resolves things over HTTP (it won't ask the
> resolver in the first place, would it?), but thanks for the pointer
> anyway.
> 
> Cheers
> [1] That's not a rhethorical flourish, it's genuine. I know too
>little about DNS-over-HTTP to be of any use at this point.

The questionable idea behind DOH is that the browser makers do not trust
your local resolver. As usual, main arguments here are:

1) One can use a local resolver with the ability *not* to resolve
certain DNS queries, which refer to the sites which just happen to
contain advertisements, fingerprinting, tracking, cryptomining etc.
Since all two major browser makers (Google and Mozilla) happen to rely
on revenue generated by advertising *and* users' browsing habits this
obviously can not be tolerated.

2) ISPs can intercept DNS queries, and modify them at their leisure.
Usually considered a first step to a censorship, implemented in this
particular form at certain European countries.

3) Bad guys and gals can hijack DNS too, to the usual hilarious results.

With the advent of HTTPS all this may be seen as moot points (if you're
redirected elsewhere the certificate validation should fail), but
nevertheless DOH is forced upon the collective throat of Firefox users
as we speak (and Chrome users are likely to follow them Soon™).
Currently a Firefox user is supposed to trust Cloudflare to do DNS
queries for them, and HTTPS is used for this purpose because Security™.


In its current form DOH has a huge gaping hole that every system
administrator worthy of the title is familiar with - local name
resolution - because Cloudflare cannot resolve hosts in your Intranet,
although they probably want to. And yes, your dirty /etc/hosts tricks
won't work here, because DOH simply skips parsing the contents of hosts
file.


Hence the trick. What Firefox does first is trying to resolve
use-application-dns.net on the assumption that if it local DNS does the
resolving then the user's host is connected to the Internet.
Because if it does not - then it's most probably a corporate Intranet so
DOH should be disabled for the duration of this browser run.
I won't go into the details here on how many levels this logic is
flawed or outright broken.

I'll just say that it's enough to use it for your own good and to
disable DOH without rebuilding Firefox from the source. So, as I wrote
earlier - if you controlling your network DOH is just another
questionable thing that can be rid of.

Reco

Re: DOH (was: geolocation services disabled and Gnome maps)

[tomas]

On Sun, Apr 12, 2020 at 01:21:08PM +0300, Reco wrote:
> On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> > That's why I cringe at the idea that browsers want to start doing
> > name resolution over HTTPS.
> 
> This simple one line of dnsmasq configuration will disable this
> problematic feature for good for Firefox (basically it creates a bogus
> NXDOMAIN response for this particular site):
> 
> local=/use-application-dns.net/

I don't quite understand [1] how the dnsmasq config has a say on
whether the browser resolves things over HTTP (it won't ask the
resolver in the first place, would it?), but thanks for the pointer
anyway.

Cheers
[1] That's not a rhethorical flourish, it's genuine. I know too
   little about DNS-over-HTTP to be of any use at this point.

-- tomás


signature.asc
Description: Digital signature

Re: DOH (was: geolocation services disabled and Gnome maps)

[Reco]

On Sun, Apr 12, 2020 at 12:10:45PM +0200, to...@tuxteam.de wrote:
> That's why I cringe at the idea that browsers want to start doing
> name resolution over HTTPS.

This simple one line of dnsmasq configuration will disable this
problematic feature for good for Firefox (basically it creates a bogus
NXDOMAIN response for this particular site):

local=/use-application-dns.net/

Chromium does not do it *yet*, but I'll implement something akin to the
previous once it'll get there.

So, as long as you control your network - it does not concern you.

Reco