10:40 a.m.
Hi,
Is there any project or team involved with improving encrypted DNS support in
Fedora? Any movement in Red Hat corporate?
- Glibc team?
The /etc/resolv.conf file needs some love. AFAIK it still does not verify DNSSEC.
- Bind team?
Using 'stunnel' is not a real option.
- DHCP(d & c) team?
Some sort of standard for applying DoT/DoH options to resolv.conf
- NetworkManager team?
Same as above.
This last effort I know of was back in 2012[1] but it was limited to DNSSEC only.
According to Arch's table[2] only two DNS applications have support for encrypted
DNS.
IMHO, this should be our number one priority over modules, new spins, or whatever
paint color the bike shed needs to be today. I would like to see DNS over TLS (DoT)
with DTLS at the very least.
Regards,
Michael
[1] https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations
[2] https://wiki.archlinux.org/index.php/Domain_name_resolution#DNS_servers
11:03 a.m.
On Mon, Nov 04, 2019 at 10:40:47AM -0600, Michael Cronenworth wrote:
Hi,
Is there any project or team involved with improving encrypted DNS support
in Fedora? Any movement in Red Hat corporate?
- Glibc team?
The /etc/resolv.conf file needs some love. AFAIK it still does not verify DNSSEC.
- Bind team?
Using 'stunnel' is not a real option.
- DHCP(d & c) team?
Some sort of standard for applying DoT/DoH options to resolv.conf
- NetworkManager team?
Same as above.
This last effort I know of was back in 2012[1] but it was limited to DNSSEC
only. According to Arch's table[2] only two DNS applications have support
for encrypted DNS.
IMHO, this should be our number one priority over modules, new spins, or
whatever paint color the bike shed needs to be today. I would like to see
DNS over TLS (DoT) with DTLS at the very least.
We have getdns-stubby packaged for DoT and dnscrypt-proxy for DoH.
Anyone interested can have Do* enabled on his system.
systemd-resolved also supports DoT, although in insecure way:
https://github.com/systemd/systemd/issues/9397
We may be missing stuff like https://github.com/dimkr/nss-tls ,
but do we need it?
I have DoH enabled system-wide on one of my installatioans for over
a year. We have required software packaged, so what exactly do you
propose?
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzichubg(a)chrome.pl -- Baron Vladimir Harkonnen
11:04 a.m.
On Mon, 4 Nov 2019 at 11:44, Michael Cronenworth <mike(a)cchtml.com> wrote:
Hi,
Is there any project or team involved with improving encrypted DNS support in
Fedora? Any movement in Red Hat corporate?
- Glibc team?
The /etc/resolv.conf file needs some love. AFAIK it still does not verify DNSSEC.
- Bind team?
Using 'stunnel' is not a real option.
- DHCP(d & c) team?
Some sort of standard for applying DoT/DoH options to resolv.conf
- NetworkManager team?
Same as above.
This last effort I know of was back in 2012[1] but it was limited to DNSSEC only.
According to Arch's table[2] only two DNS applications have support for encrypted
DNS.
IMHO, this should be our number one priority over modules, new spins, or whatever
paint color the bike shed needs to be today. I would like to see DNS over TLS (DoT)
with DTLS at the very least.
It might be more important but unless you have people who are actually
experts in DNS, encryption, TLS, and other items.. you will end up
with something a lot worse than any of the things we are currently
"bike shedding".
The people who have worked on this have come and gone at different
times with burnout from the usual 'why are you doing this versus
working on this X' that comes from 400 different cats in a bag. I
believe we have been running unbound servers for nearly 10 years with
some form of DNS over TLS since at least Fedora 13.
https://www.linode.com/docs/networking/dns/use-unbound-for-local-dns-reso...
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
--
Stephen J Smoogen.
2:18 p.m.
On Mon, Nov 4, 2019 at 12:04 pm, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
Just in case of any possible confusion: this change proposal was never
successfully implemented.
4:51 p.m.
On 11/4/19 2:18 PM, Michael Catanzaro wrote:
On Mon, Nov 4, 2019 at 12:04 pm, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Just in case of any possible confusion: this change proposal was never
successfully implemented.
Based on the feedback so far (thank you for the feedback!) it looks like the best
course of action is to revive this Change as a "v2" with a few updates.
2:25 a.m.
On 04/11/2019 23:51, Michael Cronenworth wrote:
On 11/4/19 2:18 PM, Michael Catanzaro wrote:
> On Mon, Nov 4, 2019 at 12:04 pm, Stephen John Smoogen
> <smooge(a)gmail.com> wrote:
>> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> Just in case of any possible confusion: this change proposal was never
> successfully implemented.
Based on the feedback so far (thank you for the feedback!) it looks like
the best course of action is to revive this Change as a "v2" with a few
updates.
The work described in the wiki might end up more complicated then it
seems, but if you have enough time to finish this definitely go for it.
--
Martin Sehnoutka
Software Engineer
Red Hat
12:44 p.m.
On 04/11/19 10:40 -0600, Michael Cronenworth wrote:
IMHO, this should be our number one priority over modules, new
spins, or whatever paint color the bike shed needs to be today.
I would like to see DNS over TLS (DoT) with DTLS at the very least.
I may be wrong, but it seems to me the usual plaintext by default
system wide policies regarding name resolution is what drives some
famous applications to bypass system altogether, perhaps overboard
from other perspectives (e.g. in steep contrast with crypto limits
unification, whereby not abiding the system policies is deemed bad
practice): https://bugzilla.redhat.com/show_bug.cgi?id=1751410
--
Jan (Poki)
2:17 p.m.
* Michael Cronenworth:
Hi,
Is there any project or team involved with improving encrypted DNS
support in Fedora? Any movement in Red Hat corporate?
- Glibc team?
The /etc/resolv.conf file needs some love. AFAIK it still does not
verify DNSSEC.
We are not going to implement this directly in glibc. You should talk
to a stub resolver on 127.0.0.1 instead. We do not want to link a
cryptographic library into every process that queries an Internet host
name. That also applies to DNSSEC.
Thanks,
Florian
4:52 p.m.
On 11/4/19 2:17 PM, Florian Weimer wrote:
We are not going to implement this directly in glibc. You should
talk
to a stub resolver on 127.0.0.1 instead. We do not want to link a
cryptographic library into every process that queries an Internet host
name. That also applies to DNSSEC.
The transition to DoT/DoH makes the resolv.conf file obsolete. Any discussion on
removing it entirely? Default to looking at a local resolver.
2:27 a.m.
* Michael Cronenworth:
On 11/4/19 2:17 PM, Florian Weimer wrote:
> We are not going to implement this directly in glibc. You should talk
> to a stub resolver on 127.0.0.1 instead. We do not want to link a
> cryptographic library into every process that queries an Internet host
> name. That also applies to DNSSEC.
The transition to DoT/DoH makes the resolv.conf file obsolete. Any
discussion on removing it entirely? Default to looking at a local
resolver.
This is the default today. The issue is that the defaults for the DNS
search path and some other options are wrong, and we will need a
transition to correct that. Then we can probably remove the file,
unless something else is stored there.
Thanks,
Florian
5:51 a.m.
Florian Weimer writes:
* Michael Cronenworth:
> On 11/4/19 2:17 PM, Florian Weimer wrote:
>> We are not going to implement this directly in glibc. You should talk
>> to a stub resolver on 127.0.0.1 instead. We do not want to link a
>> cryptographic library into every process that queries an Internet host
>> name. That also applies to DNSSEC.
>
> The transition to DoT/DoH makes the resolv.conf file obsolete. Any
> discussion on removing it entirely? Default to looking at a local
> resolver.
This is the default today. The issue is that the defaults for the DNS
search path and some other options are wrong, and we will need a
transition to correct that. Then we can probably remove the file,
unless something else is stored there.
Where would the dhcp-supplied DNS resolver, and DNS search path, go?
Ubuntu's default configuration appears to set up a stub resolver on
localhost and dnsmasq. Made it somewhat difficult to do any kind of
diagnostics, sine the real DNS server IP address seems to get stored
entirely within dnsmasq, and not visible anywhere.
I like plain text files, in well-defined locations. Makes things much easier
to troubleshoot.
6:07 a.m.
dnsmasq can include the real dns server ips from a external file
19/11/5 12:51(e)an, Sam Varshavchik igorleak idatzi zuen:
Florian Weimer writes:
> * Michael Cronenworth:
>
> > On 11/4/19 2:17 PM, Florian Weimer wrote:
> >> We are not going to implement this directly in glibc. You should
> talk
> >> to a stub resolver on 127.0.0.1 instead. We do not want to link a
> >> cryptographic library into every process that queries an Internet
> host
> >> name. That also applies to DNSSEC.
> >
> > The transition to DoT/DoH makes the resolv.conf file obsolete. Any
> > discussion on removing it entirely? Default to looking at a local
> > resolver.
>
> This is the default today. The issue is that the defaults for the DNS
> search path and some other options are wrong, and we will need a
> transition to correct that. Then we can probably remove the file,
> unless something else is stored there.
Where would the dhcp-supplied DNS resolver, and DNS search path, go?
Ubuntu's default configuration appears to set up a stub resolver on
localhost and dnsmasq. Made it somewhat difficult to do any kind of
diagnostics, sine the real DNS server IP address seems to get stored
entirely within dnsmasq, and not visible anywhere.
I like plain text files, in well-defined locations. Makes things much
easier to troubleshoot.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Julen Landa Alustiza
7:14 a.m.
Am 04.11.19 um 23:52 schrieb Michael Cronenworth:
cryptographic library into every process that queries an Internet
host
> name. That also applies to DNSSEC.
The transition to DoT/DoH makes the resolv.conf file obsolete. Any
discussion on removing it entirely? Default to looking at a local
resolver.
ahm.. in which way, does the use of encryption, make a sourcelist for
dns names to ask, obsolete?
nscd i.e. uses resolv.conf as source for the round robin server list.
best regards,
Marius
7:21 a.m.
* Marius Schwarz:
Am 04.11.19 um 23:52 schrieb Michael Cronenworth:
> cryptographic library into every process that queries an Internet host
>> name. That also applies to DNSSEC.
>
> The transition to DoT/DoH makes the resolv.conf file obsolete. Any
> discussion on removing it entirely? Default to looking at a local
> resolver.
ahm.. in which way, does the use of encryption, make a sourcelist for
dns names to ask, obsolete?
Names or servers?
nscd i.e. uses resolv.conf as source for the round robin server list.
With encryption, the server address will always be 127.0.0.1 (or
potentially in the future, a UNIX domain socket) because pretty much all
the current DNS client software does not support encryption. Running a
small local cache has other benefits as well, such as caching server
reachability information.
Thanks,
Florian
8:07 a.m.
Am 05.11.19 um 14:21 schrieb Florian Weimer:
> ahm.. in which way, does the use of encryption, make a sourcelist for
> dns names to ask, obsolete?
Names or servers?
"names of domainnameservers"
> nscd i.e. uses resolv.conf as source for the round robin server
list.
With encryption, the server address will always be 127.0.0.1 (or
potentially in the future, a UNIX domain socket) because pretty much all
the current DNS client software does not support encryption. Running a
small local cache has other benefits as well, such as caching server
reachability information.
running a local DNS-Cache does not make so much sense as you may think.
besides the obvious reasons like short daytime usage with poweroff at
the end,
you will run into the same kind of problems, the windows local dnscache had:
It's even harder to debug customers problems, as more caches are involved.
Countless days i had to let users flush their local dns cache, to ensure
they don't connect to something outdated.
DNS is so vital to all services, that you want to have something easy to
maintain and debug, unlike NetworkManager,
which enslaves all users to the default dns names, that came via dhcp.
Last time i checked, it does not support
round robin to increase privacy. NSCD does, and if NM lets it, it's
working good. (had it running)
If someone wants to improve privacy, some rules apply:
a) you don't ask the same server for all your questions ( Round Robin
with thousands of dnscaches world wide)
b) you build a chain of trust ( DNSSEC )
c) the entire chain encrypts the traffic
It would be ok, to have a local resolver handle this for all apps and it
mimics an unencrypted ns on 127.0.0.1:53 .
But the main problem with a+b+c is, it takes a sh*tload of overhead to a
real simple thing AND as with browsers,
has absolutely no value, because the browser will tell anyone between
himself and the target, what he is connecting to.
(see other posting).
Most people won't even gain privacy protection out of it, as outbound
dns is blocked except for the ISPs dns,
the cable/dsl box they use will just send them two dns servers, not
thousands to choose from and
in the end, the browser will give them away anyway.
From my POV, which supports the DoT as it's a good idea, "why protecting
something, that the last device sabotages anyway?"
Ok, there are more than webpages, but most used services like mail pop
imap, open one connection to a known targetport,
not hard to guess what it is and where it is. BTW, those clients do 1
dns resolve per day, they won't profit from a local cache ;)
And even if the browser would not give the dn away in SNI or Host: , it
does not make things better, as you can simply ask the internet, which
websites are hosted on a specific ip, and you get a long list of names.
Tracking a users connections makes it always possible to build profiles,
maybe not as precise as with dns data, but good enough.
My conclusion:
DoT and DoH, if not done via a browser, and not done via one single
server, are acceptable and a valid goal for a change inside Fedora,
but they won't help in privacy protection. What is needed to reach this
special goal, takes more than Fedora or Red Hat can provide.
I personally favor DoT as it would make use of the millions of dns
server available on the net. DoH is too centralized to implement for now.
best regards,
Marius
8:17 a.m.
* Marius Schwarz:
Am 05.11.19 um 14:21 schrieb Florian Weimer:
>
>> ahm.. in which way, does the use of encryption, make a sourcelist for
>> dns names to ask, obsolete?
> Names or servers?
"names of domainnameservers"
>> nscd i.e. uses resolv.conf as source for the round robin server list.
> With encryption, the server address will always be 127.0.0.1 (or
> potentially in the future, a UNIX domain socket) because pretty much all
> the current DNS client software does not support encryption. Running a
> small local cache has other benefits as well, such as caching server
> reachability information.
running a local DNS-Cache does not make so much sense as you may
think.
It definitely makes sense to cache server availability because that's
not something a short-running process can effectively determine from
scratch.
I categorically reject your notion that you can increase privacy by
sending queries to more servers. As a result, you will end up with a
larger set of servers you must trust, not a smaller one.
Thanks,
Florian
8:50 a.m.
Am 05.11.19 um 15:17 schrieb Florian Weimer:
I categorically reject your notion that you can increase privacy by
sending queries to more servers. As a result, you will end up with a
larger set of servers you must trust, not a smaller one.
You don't need to trust them for your privacy, the more servers
involved, the fewer data they get to profile about you.
Simple mathematics.
To an extend in bandwidth, you could send out parallel queries and
check, if they match or if someone has tampered
with them. Would be a nice sideeffect.
best regards,
Marius
9:01 a.m.
On Tue, 5 Nov 2019 at 09:51, Marius Schwarz <fedoradev(a)cloud-foo.de> wrote:
Am 05.11.19 um 15:17 schrieb Florian Weimer:
> I categorically reject your notion that you can increase privacy by
> sending queries to more servers. As a result, you will end up with a
> larger set of servers you must trust, not a smaller one.
>
You don't need to trust them for your privacy, the more servers
involved, the fewer data they get to profile about you.
Simple mathematics.
Except most of those servers are run by the same 3-4 organizations
which will just use the same datatracking methods they use over other
cloud apps to figure out what X is doing. Currently the
8.8.8.8/8.8.4.4 are thousands of DNS servers which also have other ip
addresses that are given out by various coffee shops and other
devices. The same with the 1.1.1.1 and probably a dozen other single
IP servers.
To an extend in bandwidth, you could send out parallel queries and
check, if they match or if someone has tampered
with them. Would be a nice sideeffect.
This breaks down for multiple reasons.
I do a parallel query and I get two different answers.. it isn't
because they are tampered with but because the DNS server got a GEOIP
regional address and so each server got one that was closest. However
this also leads to consolidation because a lot of DNS servers aren't
spec'd to dealing with more traffic than local DNS. Getting lots of
outside traffic ends up causing problems and links. So instead you get
a deal with Google/CloudFare/Akamai/etc to put in a DNS server which
they then offer to the public for a bit and you mostly. Tada.. person
on the internet thinks they spread out and aren't tracked but are just
as much as before.
best regards,
Marius
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
10:07 a.m.
Am 05.11.19 um 16:01 schrieb Stephen John Smoogen:
> To an extend in bandwidth, you could send out parallel queries and
> check, if they match or if someone has tampered
> with them. Would be a nice sideeffect.
This breaks down for multiple reasons.
I do a parallel query and I get two different answers.. it isn't
because they are tampered with but because the DNS server got a GEOIP
regional address and so each server got one that was closest. However
this also leads to consolidation because a lot of DNS servers aren't
spec'd to dealing with more traffic than local DNS. Getting lots of
outside traffic ends up causing problems and links. So instead you get
a deal with Google/CloudFare/Akamai/etc to put in a DNS server which
they then offer to the public for a bit and you mostly. Tada.. person
on the internet thinks they spread out and aren't tracked but are just
as much as before.
I can imagine, that it is a realistic scenario for the US, but not in
the rest of the free world.
I.e. here in Germany, you find static ips, which would be mandatory for
a public dns cache,
or did you mean public as in "public places"? , mainly in companies and
they won't share theire bandwidth
for a public dns cache. Some private people and organizations run free
open dns caches on science centers,
but thats about it. That google (or anyone else) gave them money to
redirect to i.e. 8.8.8.8 is hard to believe.
Concerns about privacy + google/facebook/younameit are wide spread in
europe, which is totally different in the us, as far as I heard.
best regards,
Marius
12:45 p.m.
On Tue, Nov 05, 2019 at 03:07:53PM +0100, Marius Schwarz wrote:
I personally favor DoT as it would make use of the millions of dns
server available on the net. DoH is too centralized to implement for now.
I don't agree with centralisation. You should run your own DoH endpoint,
using Google's, Cloudflare's or Quad9's servers is a shortcut.
--
Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg(a)chrome.pl an IP-routable hand grenade.'' -- Andrew Morton
(LKML)
3 p.m.
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
I don't agree with centralisation. You should run your own DoH
endpoint,
using Google's, Cloudflare's or Quad9's servers is a shortcut.
DoH has zero integration and manageability. “It’s not centralized” (but
you have to set manually DoH settings in all apps *or* rely on a
centralized Google DoH whitelist) is an utter joke.
Real decentralization means something like DHCP works on your own
network. So you can run your own load balancers and all the other cool
free software things that rely on name resolution.
But if you delegate DoH endpoint selection to DHCP all the “protection”
benefits of DoH vanish. Which just shows that the actual “protection”
of DoH is giving the kingdom keys to a small centralized cartel of
cloud companies (just like they gave the certificate keys to a small
number of CA companies, and *that* was a brillant success).
DoH works for people for whom network = Google + Chrome + Android. And
useful idiots who find nowheristan’s police practices outrageous but
turn a blind eye to the USA privatized surveillance state.
The day DoH actually gets decentralized the nowheristan state and its
ISPs will run DoH servers like everyone else and influence their
results exactly like today, and the nowheristan population will use the
result by default just like they use the state and ISP servers by
default.
Because that’s what decentralization actually means. Same thing as free
software. You don’t get to choose who runs things — tech has no
political opinions (neither does Google BTW, see: China). And the state
has all the big guns, wherever you reside on Earth. Because the state
not having all the big guns basically means any nutcake can butcher
everyone around him with impunity (see: failed states).
The only thing aggressive DoH migration gets you today is instant
depreciation of Google competitors. And you may not like them, but
you’ll like a world where Google has no remaining competitors even
less.
And all the money Google will make of DoH will serve to find ways to
track and profile you even further.
Regards,
--
Nicolas Mailhot
12:11 a.m.
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel wrote:
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
>
>
> I don't agree with centralisation. You should run your own DoH
> endpoint,
> using Google's, Cloudflare's or Quad9's servers is a shortcut.
DoH has zero integration and manageability. “It’s not centralized” (but
you have to set manually DoH settings in all apps *or* rely on a
centralized Google DoH whitelist) is an utter joke.
Setting in all apps? Excuse me? You run your stub DoH resolver
on ::1 and put ::1 in resolv.conf. Done, you've got DoH set
system-wide, which I believe this thread is about.
And you run resolving endpoint on your trusted server, or on some
micro-vm in Azure or somewhere else, or even on Fedora's Communishift.
Google does not even enter the picture.
(cutting the rest as it's irrelevant)
--
Tomasz Torcz Once you've read the dictionary,
xmpp: zdzichubg(a)chrome.pl every other book is just a remix.
3:53 p.m.
On 11/6/19 7:11 AM, Tomasz Torcz wrote:
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel
wrote:
> Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
>>
>>
>> I don't agree with centralisation. You should run your own DoH
>> endpoint,
>> using Google's, Cloudflare's or Quad9's servers is a shortcut.
>
> DoH has zero integration and manageability. “It’s not centralized” (but
> you have to set manually DoH settings in all apps *or* rely on a
> centralized Google DoH whitelist) is an utter joke.
Setting in all apps? Excuse me? You run your stub DoH resolver
on ::1 and put ::1 in resolv.conf. Done, you've got DoH set
system-wide, which I believe this thread is about.
And you run resolving endpoint on your trusted server, or on some
micro-vm in Azure or somewhere else, or even on Fedora's Communishift.
Google does not even enter the picture.
(cutting the rest as it's irrelevant)
I agree with one sidenote. It is not required to use DoH for that, DoT
is enough already. And it cannot contain privacy leaking headers,
because there are just none in the protocol.
I think dnssec-trigger might be and example. It checks dnssec in current
resolvers obtained by DHCP. If it does not support it, it uses its own.
If they are blocked, it uses proxy. Does not know anything about
encryption, but it might work if tuned a bit.
Problem is, it has already terrible design. It should be driven by
network manager or something similar. Anyway, I think any encryption
belongs to the system, not applications. But first, we need some
system-wide tool prepared for that. Besides dnssec-trigger, there is
getdns-stubby package. It does not allow simple use of DHCP specified
resolvers, but it is the best solution for encrypted DNS at the moment.
Regards,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com PGP: 65C6C973
11:18 a.m.
Le mercredi 06 novembre 2019 à 07:11 +0100, Tomasz Torcz a écrit :
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel
wrote:
> Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
> >
> > I don't agree with centralisation. You should run your own DoH
> > endpoint,
> > using Google's, Cloudflare's or Quad9's servers is a shortcut.
>
> DoH has zero integration and manageability. “It’s not centralized”
> (but
> you have to set manually DoH settings in all apps *or* rely on a
> centralized Google DoH whitelist) is an utter joke.
Setting in all apps? Excuse me? You run your stub DoH resolver
on ::1 and put ::1 in resolv.conf.
That won't be honored by DoH-enabled apps that refuse to honor system
resolution.
That won't be honoured by all the other things on your network, unless
you reparameter every and each one of them by hand (assuming they
support DoH, or allow setting a DNS resolver manually in the first
place)
That won't be honoured by the smartphone of your visitors, by their pet
smart collar, etc, unless you spend 15 minutes figuring how to
reconfigure them at the start of their visit, and reconfigure them back
at the end. Don't bother giving them your wifi code.
So, no smart tv, no internet radio, no smart toaster, no resolved
network path to your gaming console, no nothing for them. Back to the
dark ages where nothing worked by default, networks were an enterprise-
only thing, and ISPs felt entitled to charge multiples if you plugged
more than one computer at the end of their cable.
That's what your single-system “solution” actually means.
Using DoH today means, in practical terms, using Google-approved
resolvers, and names Google know of (bye bye private networks) because
that's the only common ground DoH apps agree on, and the only practical
way to synchronize DoH naming results with the rest of the network
world.
Distributing DoH settings has not been specified yet, and even if it
were (for example DHCP side) there is zero commitment by Google or any
of the other DoH supporters to honor it. So, *just* *like* *for*
*http2*, Google will only specify the parts of the protocol it is
interested in, go AWOL for the other parts, and block their
standardisation by refusing to implement them even if someone managed
the specification (Google owns enough of the Internet to veto anything
it does not like). And Chrome will have an enterprise mode that allows
everything it blocks for home/SOHO users, and good bye any free-
software-like level field for others.
That's why using DoH in any form is a terrible idea right now. It's not
finished in practical terms. Its proponents have both the ability, and
the record track, of not playing nice once the parts they want get
adopted.
And I didn't even get into technical DoT/DoH comparisons, or asked you
if your DoH endpoint was packaged into Fedora, in a solid enough form
to run in production without getting owned.
Regards,
--
Nicolas Mailhot
4:09 a.m.
On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel wrote:
> >
> > DoH has zero integration and manageability. “It’s not centralized”
> > (but
> > you have to set manually DoH settings in all apps *or* rely on a
> > centralized Google DoH whitelist) is an utter joke.
>
> Setting in all apps? Excuse me? You run your stub DoH resolver
> on ::1 and put ::1 in resolv.conf.
That won't be honored by DoH-enabled apps that refuse to honor system
resolution.
That won't be honoured by all the other things on your network, unless
you reparameter every and each one of them by hand (assuming they
support DoH, or allow setting a DNS resolver manually in the first
place)
That won't be honoured by the smartphone of your visitors, by their pet
smart collar, etc, unless you spend 15 minutes figuring how to
reconfigure them at the start of their visit, and reconfigure them back
at the end. Don't bother giving them your wifi code.
So, no smart tv, no internet radio, no smart toaster, no resolved
network path to your gaming console, no nothing for them. Back to the
dark ages where nothing worked by default, networks were an enterprise-
only thing, and ISPs felt entitled to charge multiples if you plugged
more than one computer at the end of their cable.
Here's a network management lesson for you:
- run DoH resolver* not on ::1, but on IP available on your LAN
- put above IP in DHCP and RA replies
- bam! every device you mentioned uses DoH to resolve
* I'm not aware of any packaged for Fedora, I'm using
https://github.com/m13253/dns-over-https myself
That's what your single-system “solution” actually means.
Using DoH today means, in practical terms, using Google-approved
resolvers, and names Google know of (bye bye private networks) because
that's the only common ground DoH apps agree on, and the only practical
way to synchronize DoH naming results with the rest of the network
world.
You seem to have some Google-fixation. I'll refrain from continuing
this thread, you seem to be arguing against protocol, instead of
reaching consensus on how to provide tools for it in Fedora.
--
Tomasz Torcz Once you've read the dictionary,
xmpp: zdzichubg(a)chrome.pl every other book is just a remix.
5:04 a.m.
Le samedi 09 novembre 2019 à 11:09 +0100, Tomasz Torcz a écrit :
On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel
wrote:
> > >
Here's a network management lesson for you:
- run DoH resolver* not on ::1, but on IP available on your LAN
- put above IP in DHCP and RA replies
- bam! every device you mentioned uses DoH to resolve
Using DoH? Nope. using evil unencrypted legacy DNS. So anything that
care for DoH as you seem to will reject the configuration
You continue advocating half-assed setups that work for your case but
not others
--
Nicolas Mailhot
5:12 a.m.
Le samedi 09 novembre 2019 à 12:04 +0100, Nicolas Mailhot a écrit :
Le samedi 09 novembre 2019 à 11:09 +0100, Tomasz Torcz a écrit :
> On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel
> wrote:
> Here's a network management lesson for you:
> - run DoH resolver* not on ::1, but on IP available on your LAN
> - put above IP in DHCP and RA replies
> - bam! every device you mentioned uses DoH to resolve
Using DoH? Nope. using evil unencrypted legacy DNS. So anything that
care for DoH as you seem to will reject the configuration
You continue advocating half-assed setups that work for your case but
not others
RFC 8484 (DoH)
3. Selection of DoH Server
The DoH client is configured with a URI Template [RFC6570], which
describes how to construct the URL to use for resolution.
Configuration, discovery, and updating of the URI Template is done
out of band from this protocol.
So where is the specification for “Configuration, discovery, and
updating of the URI Template” when delegation DoH selection to the
network admin ?
It's not specified. It does not exist. It's not adopted by any DoH app.
All the entities pushing DoH retain the possibility to refuse
implementing it if it does not fit their objectives.
DoH is not finished from a management PoW. The only actual and concrete
mecanism right now is using Google DoH whitelists.
--
Nicolas Mailhot
9:54 a.m.
On 05/11/2019 22:00, Nicolas Mailhot via devel wrote:
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
[....]
The day DoH actually gets decentralized the nowheristan state and its
ISPs will run DoH servers like everyone else and influence their
results exactly like today, and the nowheristan population will use the
result by default just like they use the state and ISP servers by
default.
DoH won't even really work here. Yes, the DNS request is encrypted and you
knock-a-whole through their firewall, you can be fairly confident the response
has not been modified (as long as the TLS connection is validated, etc, etc).
Except of the "knock-a-whole" aspect, DoT resolves exactly the same issues.
But what is even more important to realize is what happens *after* the DNS
query has been returned. You connect to the IP address provided in the
response. And if that server is encrypted but uses TLSv1.2 or older, the
hostname you are connecting to is "leaked" via the TLS negotiation (SNI
hostname is not encrypted).
The result is, you do not have any kind of privacy in regards to what services
you connect to. A DPI capable firewall will still be able to block this access.
Yes, TLSv1.3 with encrypted SNI will help to some degree, but still there IP
addresses you connect to will still provide meta data which can be used to
profile you and give an indication of what kind of sites you visit.
So claiming DoH or DoT helps privacy is in best case ignorant to privacy. In
worst case, it puts people needing privacy at risk.
If you want privacy, you need to connect to a VPN server you choose to trust.
And that VPN provider needs to find ways to circumvent any firewall blocks as
needed.
Now DoT on the other hand can have a purpose, when used between DNS servers.
For more details about DoH challenges ... please have a look at this talk:
<https://www.youtube.com/watch?v=8SJorQ9Ufm8>
--
kind regards,
David Sommerseth
11:56 a.m.
On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth <dazo(a)eurephia.org>
wrote:
Yes, TLSv1.3 with encrypted SNI will help to some degree, but still
there IP
addresses you connect to will still provide meta data which can be
used to
profile you and give an indication of what kind of sites you visit.
Well that's the whole point right there. In combination with ESNI, it's
no longer possible to tell which domain you are visiting on a
particular vhost. It's not perfect, but that's still tremendously
better than nothing. It is why Mozilla and EFF are strongly promoting
DoH.
2:59 p.m.
On Wed, Nov 06, 2019 at 11:56:13AM -0600, Michael Catanzaro wrote:
On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth
<dazo(a)eurephia.org> wrote:
> Yes, TLSv1.3 with encrypted SNI will help to some degree, but still
> there IP
> addresses you connect to will still provide meta data which can be used
> to
> profile you and give an indication of what kind of sites you visit.
Well that's the whole point right there. In combination with ESNI, it's no
longer possible to tell which domain you are visiting on a particular vhost.
It's not perfect, but that's still tremendously better than nothing. It is
why Mozilla and EFF are strongly promoting DoH.
On the one hand, thats great and good. On the other hand, all your DoH
is going to a single provider, bypassing everything else.
In any case, I will note here that firefox in Fedora is not going to
enable DoH like upstream firefox. I don't know about chromium.
I think for DoH to really be useful, it needs to be in widespread use in
all the various providers/ISPs. Hopefully that happens.
kevin
3:11 p.m.
Am 06.11.19 um 21:59 schrieb Kevin Fenzi:
In any case, I will note here that firefox in Fedora is not going to
enable DoH like upstream firefox. I don't know about chromium.
kevin
That's good news, as it takes about half an hour to make ff privacy
conform again. Each step less helps.
Best regards,
Marius
5:20 a.m.
On 06/11/2019 18:56, Michael Catanzaro wrote:
On Wed, Nov 6, 2019 at 4:54 pm, David Sommerseth
<dazo(a)eurephia.org> wrote:
> Yes, TLSv1.3 with encrypted SNI will help to some degree, but still there IP
> addresses you connect to will still provide meta data which can be used to
> profile you and give an indication of what kind of sites you visit.
Well that's the whole point right there. In combination with ESNI, it's no
longer possible to tell which domain you are visiting on a particular vhost.
It's not perfect, but that's still tremendously better than nothing. It is why
Mozilla and EFF are strongly promoting DoH.
Please just watch the talk by Paul Vixie (who is one of the really big DNS
gurus these days, even ISC BIND maintainer for quite some years). And you
will see that DoH is pointless when you have DoT. But DoT can also go much
further than DoH will, when you consider the bigger part of the DNS query chain.
Plus, ignoring the local networks DNS also has its own set of challenges when
being added directly to browsers. Like hostnames only available inside a
local network will no longer be available. But again, watch the talk, these
points are well covered there.
--
kind regards,
David Sommerseth
8:47 a.m.
On Thu, 7 Nov 2019 12:20:50 +0100
David Sommerseth <dazo(a)eurephia.org> wrote:
Please just watch the talk by Paul Vixie (who is one of the really
big DNS gurus these days, even ISC BIND maintainer for quite some
years). And you will see that DoH is pointless when you have DoT.
But DoT can also go much further than DoH will, when you consider the
bigger part of the DNS query chain.
Thank you for pointing to that talk. I found it very informative, as a
mostly ignorant user of DNS. I run knot-resolver as a local caching DNS
server, pulling from, ironically, 1.1.1.1 via the router, and bypassing
my ISP's DNS servers. Really opened my eyes.
For convenience, repeating it here.
https://www.youtube.com/watch?v=8SJorQ9Ufm8
11:32 a.m.
On Thu, 2019-11-07 at 07:47 -0700, stan via devel wrote:
On Thu, 7 Nov 2019 12:20:50 +0100
David Sommerseth <dazo(a)eurephia.org> wrote:
> Please just watch the talk by Paul Vixie (who is one of the really
> big DNS gurus these days, even ISC BIND maintainer for quite some
> years). And you will see that DoH is pointless when you have DoT.
> But DoT can also go much further than DoH will, when you consider
> the
> bigger part of the DNS query chain.
Thank you for pointing to that talk. I found it very informative, as
a
mostly ignorant user of DNS. I run knot-resolver as a local caching
DNS
server, pulling from, ironically, 1.1.1.1 via the router, and
bypassing
my ISP's DNS servers. Really opened my eyes.
The talk is right on many points, but I think it dismisses the most
essential point DoH does right: DNS is a decision of the device owner.
When you are the real owner of the device, you can configure the device
to use whatever DoH server you want. This includes company DoH servers.
We have to stop to make security products that rely on the same
mechanisms as an attacker would use.
For corporate environments use Puppet, Ansible, GPOs, MDM, whatever
your company device management you have to use at scale anyway, to
configure your preferred DoH server, which then can apply all the
measures he is talking about to protect things.
For private setups: Take the 10 minutes it takes to configure devices
properly instead of relying on easy to break network attacker-based
solutions.
And when you give a device to your kids, then it will probably just
take them one internet search to learn how to use the /etc/hosts file
in order to access evilpage.com.
I agree that DoH and DoT doesn't bring so much more privacy, but it
provides integrity to DNS that unencrypted DNS even with DNSSec is
lagging as an attack can always opt to not answer for a specific domain
name.
And whenever or not applications of the system should implement it, is
probably decided by how fast the system side will decide to deploy
encrypted DNS effectively.
--
Signed
Sheogorath
OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt
2:25 p.m.
Le jeudi 07 novembre 2019 à 18:32 +0100, Sheogorath via devel a écrit :
The talk is right on many points, but I think it dismisses the most
essential point DoH does right: DNS is a decision of the device
owner.
And the owner should be able to delegate this decision to the network
manager.
Suggesting static config is good enough outside the enterprise is a
joke. Count the number of networked things in the modern home, it grows
every years. A lot of those roam, either because they are designed to
roam (smartphones) or because people vacation, because they like to
share their stuff with friends and families, because they like to show
of. A lot of those are cheap-ass gadgets that will revert (reset) to
factory settings at the slightest problem (sometimes, just because the
battery is dead, the juice was cut, and settings are kept in memory).
Ansible or puppet are not designed to solve such generic situations.
Network management is no longer an enterprise-only concern.
Treating it as a sysadmin problem does not work.
The network happened. And not only internet side.
--
Nicolas Mailhot
6:15 p.m.
On Thu, 2019-11-07 at 21:25 +0100, Nicolas Mailhot via devel wrote:
Le jeudi 07 novembre 2019 à 18:32 +0100, Sheogorath via devel a
écrit
:
> The talk is right on many points, but I think it dismisses the most
> essential point DoH does right: DNS is a decision of the device
> owner.
And the owner should be able to delegate this decision to the network
manager.
Then let's talk on how we properly implement this delegation process
instead of asking ourselves whenever we want DoH or DoT or not.
Let's find a DHCP/RA option that indicates a DoT or DoH service is
available or something similar. Simply stating "encrypted DNS is
pointless" is nothing I consider a valid solution.
Suggesting static config is good enough outside the enterprise is a
joke. Count the number of networked things in the modern home, it
grows
every years. A lot of those roam, either because they are designed to
roam (smartphones) or because people vacation, because they like to
share their stuff with friends and families, because they like to
show
of. A lot of those are cheap-ass gadgets that will revert (reset) to
factory settings at the slightest problem (sometimes, just because
the
battery is dead, the juice was cut, and settings are kept in memory).
And how are those devices related to Fedora? I mean, our goal here
should be to do things right or at least better. When we take those IoT
devices as our standards, then we can throw away SELinux, run stone-age
kernels and we can also ignore the existence of updates for our
systems. We are Fedora, we want to lead tech towards a better
standards, not stay around in the status quo where everyone else
already is.
Ansible or puppet are not designed to solve such generic situations.
Network management is no longer an enterprise-only concern.
Treating it as a sysadmin problem does not work.
The network happened. And not only internet side.
I really hope for more IPv6 to happen (properly), so pretty much
everything becomes the internet. It makes so many things a lot easier
and a lot less security through obscurity.
--
Signed
Sheogorath
OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt
3:12 a.m.
Le samedi 09 novembre 2019 à 01:15 +0100, Sheogorath via devel a
écrit :
And the owner should be able to delegate this decision to the
network
> manager.
>
Then let's talk on how we properly implement this delegation process
instead of asking ourselves whenever we want DoH or DoT or not.
You can talk all you want it's all handwaving as long as major actors
behind DoH refuse to work on it or support it if someone else works on
it.
That’s why DoH is intrinsically centralized and rotten to the core.
DoH supporters are perfectly happy with a world where there is no
standard for delegation. And if there is no standard, classical network
effects will favor the biggest actor by default.
And how are those devices related to Fedora?
They's related to Fedora because Fedora is not a desktop-only
distribution so it *is* only concerned with the server-side and network
management part.
I really hope for more IPv6 to happen (properly), so pretty much
everything becomes the internet.
In a nutshell, that's why IPV6 adoption has been lagging for all this
time. It wants everything to be the internet, and deprecate things
people found useful. Except that's not how actual people want to use
their networks. So all the things that IPv6 authors rejected are
slowly being standardized back because that's what people need.
Regards,
--
Nicolas Mailhot
5:46 a.m.
Am 09.11.19 um 10:12 schrieb Nicolas Mailhot via devel:
That’s why DoH is intrinsically centralized and rotten to the core.
DoH supporters are perfectly happy with a world where there is no
standard for delegation. And if there is no standard, classical network
effects will favor the biggest actor by default.
A classic "Chicken &
Egg" problem. You can only support it, if enough
differen, free, reliable DoT/H Servers are out there,
which will only come, when they are requested.
In other words: someone has to make a step, and mozilla did it.
A plan:
Get NetworkManager a modul to manage DNS better:
Option Page 1:
- receive DNS via DHCP ( default )
- use DNS over TLS
- use DNS over HTTPS
- use system software proxy to manage DNS for you.
Option Page " use DNS over TLS"
- receive list of available DNS from ... and randomly autoselect
- use a fixed list of servers
Option Page " use DNS over HHTPS"
- receive list of available DNS from ... and randomly autoselect
- use a fixed list of servers
Option Page " use system software proxy"
- use nscd
- use dnssec-trigger
- use ...
.. whatever Fedora has to offer
This way, anyone can easily configure their prefered way, and RH PR
department can write a nice "we support encrypted DNS over a variose
number of protocols" news. Anyone who wants his proxy software in this
proxy list, names his default port/socket and a tool to be called for
configuration.
In addition "someone" ( now look suspicious to you rh contact ) has to
make webservice to give out trusted DO* Serverlists in a i.e. Json
format with some additional hints about ( name of service, country it's
laws it's following, commercial or not etc ) and sign that with a
fedora/rh key, so we can trust the list.
what do you all think?
best regards,
Marius
6:37 a.m.
Le samedi 09 novembre 2019 à 12:46 +0100, Marius Schwarz a écrit :
Am 09.11.19 um 10:12 schrieb Nicolas Mailhot via devel:
> That’s why DoH is intrinsically centralized and rotten to the core.
>
> DoH supporters are perfectly happy with a world where there is no
> standard for delegation. And if there is no standard, classical
> network
> effects will favor the biggest actor by default.
A classic "Chicken & Egg" problem. You can only support it, if enough
differen, free, reliable DoT/H Servers are out there,
It's *not* a chicken and egg problem.
DoH (the protocol) got standardised by the IETF. That means it had at
least two separate implementations.
DoH DHCP/RA options were NOT standardised by the IETF. That means that
while there were enough stackeholders DoH-side to work on the protocol,
they were NOT willing to work or agree on a management layer (and at
least two of them, Mozilla and Google, have and are releasing systems
and applicances, not just browsers, so it’s not as if they don’t know
about the non-browser layer).
Trying to open and standardise DoH without the by-in and involvment of
its main stakeholders is an exercise in futility. If you think that can
work, find us an app that actually produces and consumes Office Open
XML documents (the strict 2006 ECMA-376 standard, not all the non-
interoperable approximations out there).
--
Nicolas Mailhot
2:25 p.m.
On Thu, Nov 7, 2019 at 12:20 pm, David Sommerseth <dazo(a)eurephia.org>
wrote:
Please just watch the talk by Paul Vixie (who is one of the really
big DNS
gurus these days, even ISC BIND maintainer for quite some years).
And you
will see that DoH is pointless when you have DoT.
Looks like we're headed towards a DNS war. This should be interesting.
3:36 p.m.
Hi Marius,
I maintain BIND and some similar stuff. More or less, there is already
implementation quite similar to what you have described. Already in
Fedora: stubby [1]. It has central list of several resolvers and uses
them in round-robin fashion. Does not make specific order.
However, the most close solution to what is required in coordination
with DHCP is IMO dnssec-trigger. It has very complicated design
unfortunately.
Regards,
Petr
1. https://github.com/getdnsapi/stubby
On 11/5/19 3:07 PM, Marius Schwarz wrote:
Am 05.11.19 um 14:21 schrieb Florian Weimer:
>
>> ahm.. in which way, does the use of encryption, make a sourcelist for
>> dns names to ask, obsolete?
> Names or servers?
"names of domainnameservers"
>> nscd i.e. uses resolv.conf as source for the round robin server list.
> With encryption, the server address will always be 127.0.0.1 (or
> potentially in the future, a UNIX domain socket) because pretty much all
> the current DNS client software does not support encryption. Running a
> small local cache has other benefits as well, such as caching server
> reachability information.
>
running a local DNS-Cache does not make so much sense as you may think.
besides the obvious reasons like short daytime usage with poweroff at
the end,
you will run into the same kind of problems, the windows local dnscache had:
It's even harder to debug customers problems, as more caches are involved.
Countless days i had to let users flush their local dns cache, to ensure
they don't connect to something outdated.
DNS is so vital to all services, that you want to have something easy to
maintain and debug, unlike NetworkManager,
which enslaves all users to the default dns names, that came via dhcp.
Last time i checked, it does not support
round robin to increase privacy. NSCD does, and if NM lets it, it's
working good. (had it running)
If someone wants to improve privacy, some rules apply:
a) you don't ask the same server for all your questions ( Round Robin
with thousands of dnscaches world wide)
b) you build a chain of trust ( DNSSEC )
c) the entire chain encrypts the traffic
It would be ok, to have a local resolver handle this for all apps and it
mimics an unencrypted ns on 127.0.0.1:53 .
But the main problem with a+b+c is, it takes a sh*tload of overhead to a
real simple thing AND as with browsers,
has absolutely no value, because the browser will tell anyone between
himself and the target, what he is connecting to.
(see other posting).
Most people won't even gain privacy protection out of it, as outbound
dns is blocked except for the ISPs dns,
the cable/dsl box they use will just send them two dns servers, not
thousands to choose from and
in the end, the browser will give them away anyway.
From my POV, which supports the DoT as it's a good idea, "why protecting
something, that the last device sabotages anyway?"
Ok, there are more than webpages, but most used services like mail pop
imap, open one connection to a known targetport,
not hard to guess what it is and where it is. BTW, those clients do 1
dns resolve per day, they won't profit from a local cache ;)
And even if the browser would not give the dn away in SNI or Host: , it
does not make things better, as you can simply ask the internet, which
websites are hosted on a specific ip, and you get a long list of names.
Tracking a users connections makes it always possible to build profiles,
maybe not as precise as with dns data, but good enough.
My conclusion:
DoT and DoH, if not done via a browser, and not done via one single
server, are acceptable and a valid goal for a change inside Fedora,
but they won't help in privacy protection. What is needed to reach this
special goal, takes more than Fedora or Red Hat can provide.
I personally favor DoT as it would make use of the millions of dns
server available on the net. DoH is too centralized to implement for now.
best regards,
Marius
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com PGP: 65C6C973
7:09 a.m.
Am 04.11.19 um 17:40 schrieb Michael Cronenworth:
Hi,
Is there any project or team involved with improving encrypted DNS
support in Fedora? Any movement in Red Hat corporate?
- Glibc team?
The /etc/resolv.conf file needs some love. AFAIK it still does not
verify DNSSEC.
- Bind team?
Using 'stunnel' is not a real option.
- DHCP(d & c) team?
Some sort of standard for applying DoT/DoH options to resolv.conf
DoH is IMHO a waste of resources and as Browsers implement it, useless
at best, but mostly a centralization of control of users under a false
protection umbrella.
Any modern Browser will do this sequence:
User enters URL
Browser checks for domainnames
Browser sends DNS request ( over which path doesn't matter )
Opens connection to the target host
If ( HTTPS ) {
sends the domainname, he has found in the URL as SNI in plain! in
his TLS request
} else {
send the domainame in plaintext as Host: Header to the target.
}
in both cases, the result is the same. The user is trackable.
IMHO, this should be our number one priority over modules, new
spins,
or whatever paint color the bike shed needs to be today. I would like
to see DNS over TLS (DoT) with DTLS at the very least.
I support this.
best regards,
Marius
7:38 a.m.
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
DoH is IMHO a waste of resources and as Browsers implement it,
useless
at best, but mostly a centralization of control of users under a false
protection umbrella.
Any modern Browser will do this sequence:
User enters URL
Browser checks for domainnames
Browser sends DNS request ( over which path doesn't matter )
Opens connection to the target host
If ( HTTPS ) {
sends the domainname, he has found in the URL as SNI in plain! in
his TLS request
This is not true, SNI is encrypted:
https://eff.org/pl/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
--
Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg(a)chrome.pl an IP-routable hand grenade.'' -- Andrew Morton
(LKML)
7:42 a.m.
On 05/11/2019 13:38, Tomasz Torcz wrote:
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
> DoH is IMHO a waste of resources and as Browsers implement it, useless
> at best, but mostly a centralization of control of users under a false
> protection umbrella.
>
> Any modern Browser will do this sequence:
>
> User enters URL
> Browser checks for domainnames
> Browser sends DNS request ( over which path doesn't matter )
> Opens connection to the target host
>
> If ( HTTPS ) {
> sends the domainname, he has found in the URL as SNI in plain! in
> his TLS request
This is not true, SNI is encrypted:
https://eff.org/pl/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
I don't think one CDN deploying a non-standard extension can reasonably
be described as meaning that SNI is now encrypted.
Yes it is encrypted if you're using a special test version of one
specific browser and you access a site run by one of a handful of
providers that support that on the server side.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7:46 a.m.
On 05/11/2019 13:42, Tom Hughes wrote:
I don't think one CDN deploying a non-standard extension can
reasonably
be described as meaning that SNI is now encrypted.
Yes it is encrypted if you're using a special test version of one
specific browser and you access a site run by one of a handful of
providers that support that on the server side.
Looks like release Firefox does have it now, but not enabled by
default - there is a network.security.esni.enabled configuration
option that would have to be turned on.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
8:40 a.m.
Am 05.11.19 um 14:38 schrieb Tomasz Torcz:
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
> DoH is IMHO a waste of resources and as Browsers implement it, useless
> at best, but mostly a centralization of control of users under a false
> protection umbrella.
>
> Any modern Browser will do this sequence:
>
> User enters URL
> Browser checks for domainnames
> Browser sends DNS request ( over which path doesn't matter )
> Opens connection to the target host
>
> If ( HTTPS ) {
> sends the domainname, he has found in the URL as SNI in plain! in
> his TLS request
This is not true, SNI is encrypted:
https://eff.org/pl/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
It says "experimental" in sentence one in 2018 ... and this is end of
2019 connecting to EFF.org with Firefox:
Request:
15:11:04.342072 IP MYIP.46286 > vm1.eff.org.https: Flags [P.], seq
1:518, ack 1, win 502, options [nop,nop,TS val 2291965978 ecr
490558638], length 517
0x0000: 4500 0239 8492 4000 4006 f5ae c0a8 0022 E..9..@.@......"
0x0010: adef 4fc4 b4ce 01bb 52d3 1d70 a0d0 f7f6 ..O.....R..p....
0x0020: 8018 01f6 857b 0000 0101 080a 889c a01a .....{..........
0x0030: 1d3d 54ae 1603 0102 0001 0001 fc03 032e .=T.............
0x0040: 4e54 98b3 7e3d 6fc4 0a9a f788 da24 62f4 NT..~=o......$b.
0x0050: 8649 5ed0 eee5 941e fcf2 ab32 2510 f020 .I^........2%...
0x0060: 88d6 2ac2 75f3 309f 636d 07fe 8660 84e6 ..*.u.0.cm...`..
0x0070: da60 a907 d7c5 aa3e 5c58 4af5 274c 5c4c .`.....>\XJ.'L\L
0x0080: 0022 1301 1303 1302 c02b c02f cca9 cca8 .".......+./....
0x0090: c02c c030 c00a c009 c013 c014 0033 0039 .,.0.........3.9
0x00a0: 002f 0035 0100 0191 0000 0017 0015 0000 ./.5............
0x00b0: 1261 6e6f 6e2d 7374 6174 732e 6566 662e .*anon-stats.eff.*
0x00c0: 6f72 6700 1700 00ff 0100 0100 000a 000e *org*.............
0x00d0: 000c 001d 0017 0018 0019 0100 0101 000b ................
0x00e0: 0002 0100 0023 0000 0010 000e 000c 0268 .....#.........h
0x00f0: 3208 6874 7470 2f31 2e31 0005 0005 0100 2.http/1.1......
Answere:
15:11:04.517421 IP vm1.eff.org.https > MYIP.46286: Flags [.], seq
1:1441, ack 518, win 11, options [nop,nop,TS val 490558683 ecr
2291965978], length 1440
0x0000: 4500 05d4 a322 4000 2e06 e583 adef 4fc4 E...."@.......O.
0x0010: c0a8 0022 01bb b4ce a0d0 f7f6 52d3 1f75 ..."........R..u
0x0020: 8010 000b 09d2 0000 0101 080a 1d3d 54db .............=T.
0x0030: 889c a01a 1603 0300 5402 0000 5003 03ae ........T...P...
0x0040: 9213 9378 8065 5d69 d974 edc4 3a2f 85d4 ...x.e]i.t..:/..
0x0050: e7e3 46cd aa03 c317 4dde 5bb2 947c e100 ..F.....M.[..|..
0x0060: c030 0000 28ff 0100 0100 0000 0000 000b .0..(...........
0x0070: 0004 0300 0102 0023 0000 0017 0000 0010 .......#........
0x0080: 000b 0009 0868 7474 702f 312e 3116 0303 .....http/1.1...
0x0090: 0b04 0b00 0b00 000a fd00 0661 3082 065d ...........a0..]
0x00a0: 3082 0545 a003 0201 0202 1203 1919 210a 0..E..........!.
0x00b0: ca50 2c2e 4bc1 798f bffc 2094 7330 0d06 .P,.K.y.....s0..
0x00c0: 092a 8648 86f7 0d01 010b 0500 304a 310b .*.H........0J1.
0x00d0: 3009 0603 5504 0613 0255 5331 1630 1406 0...U....US1.0..
0x00e0: 0355 040a 130d 4c65 7427 7320 456e 6372 .U....Let's.Encr
0x00f0: 7970 7431 2330 2106 0355 0403 131a 4c65 ypt1#0!..U....Le
0x0100: 7427 7320 456e 6372 7970 7420 4175 7468 t's.Encrypt.Auth
0x0110: 6f72 6974 7920 5833 301e 170d 3139 3131 ority.X30...1911
0x0120: 3031 3138 3330 3436 5a17 0d32 3030 3133 01183046Z..20013
0x0130: 3031 3833 3034 365a 301d 311b 3019 0603 0183046Z0.1.0...
0x0140: 5504 0313 1261 6e6f 6e2d 7374 6174 732e U....*anon-stats.*
0x0150: 6566 662e 6f72 6730 8202 2230 0d06 092a *eff.org*0.."0...*
0x0160: 8648 86f7 0d01 0101 0500 0382 020f 0030 .H.............0
0x0170: 8202 0a02 8202 0100 be74 c8c0 c04e d886 .........t...N..
0x0180: 6fb4 90f7 d65b c1be 0d7d eece be45 6161 o....[...}...Eaa
0x0190: c71f 544d 8fd7 ab3c 63bd 4ce5 b3dc f5c8 ..TM...<c.L.....
TLS stands for "Transport Layer Security" and it does exactly that, not
more.
If you see the initial response, you get a cert. The cert contains the
domainnames it's signed against: gotcha.
As the IETF page with the rfc for ESNI is not loading ( server down? ) i
refer to cloudflares projectpage... they store a public key in .. tada
.. DNS.
Which brings us back to the point, that we don't have too many DNSSEC
aware apps out there... we are going in cycles.. :(
The solution for the ESNI problem would have been, a two-level HTTPS
exchange:
1. Layer a SERVER Cert signed for the IP ( because thats not a secret )
2. Layer after a session they has been negotiated, a normal old school
request would have been sent.
Result: some bits more overhead, but finally, a !safe! TLS exchange.
... seufz..
best regards,
Marius
1647
days inactive
1652
days old
45 comments
17 participants
participants (17)
-
David Sommerseth -
Florian Weimer -
Jan Pokorný -
Julen Landa Alustiza -
Kevin Fenzi -
Marius Schwarz -
Martin Sehnoutka -
Michael Catanzaro -
Michael Cronenworth -
Nicolas Mailhot -
Petr Mensik -
Sam Varshavchik -
Sheogorath -
stan -
Stephen John Smoogen -
Tom Hughes -
Tomasz Torcz