Thanks. I will keep you updated.
In a hostile environment. Getting anything done is hard. Unable to help for the time being.
Why bother with encrypted DNS at all? Encrypting DNS queries doesn’t actually add any real privacy or security benefits.
Security:
-
When using HTTPS and unencrypted DNS, you still cannot be MITM’ed. My browser expects a valid TLS certificate for the website I’m visiting regardless of what the DNS query gave me.
-
When not using HTTPS and using encrypted DNS, you can still be MITM’ed. The attacker doesn’t need to mess with DNS.
Privacy:
- Encrypted DNS alone doesn’t hide the domain names you visit. That can still be gotten from SNI or the IP address.
If anything, this will worsen security by increasing attack surface and by taking away focus from other, more important issues.
The only reason it has been pushed so hard in other projects is for marketing purposes.
Also see:
It’s not only about encrypted DNS. More important goal of this ticket is to provide DNSSEC (authenticated DNS). Many ISP provided DNS servers nowadays still do not offer DNSSEC. With an DNS-enhancement opt-in package users could get an option to easily enable system wide DNSSEC. DNS being encrypted on top of that since for example by using DNSCrypt is only a bonus on top.
- SNI: true but that may in the future no longer be the case thanks to ESNI (encrypted SNI)? Reference:
- IP: When behind cloudflare (or similar) that might be no longer applicable too? Would be ironic. Shared hosting might then be a privacy advantage.
Indeed.
Depends. On first visit of the website could be victim to sslstrip.
- sslstrip can be prevented if the website signed up to be added to the HSTS preload list.
- Btw also
DNS Certification Authority Authorization (CAA) Policy
can help.
(related: DNS Certification Authority Authorization (CAA) Policy / DNSSEC for whonix.org / ssllabs.com test results / OCSP ERROR: Exception: connect timed out [http://r3.o.lencr.org] / Must-Staple)
Even if using HTTPS and encrypted DNS there could still be MITM attempts. In absence of 1) (HSTS preload) and 2) (CAA policy) there are still risks.
Right. My biggest worry is DoH centralizes DNS traffic at a few DoH resolvers
. Increases centralization. If Firefox/Chrome enable that by default, and then DoH resolvers start with censorship, effectively fewer users can get access to information. Yes, there would be options to circumvent this and some would succeed but the net effect is that fewer people will have access. Censorship doesn’t become totally useless just because it’s not 100% efficient.
However, DNS-over-HTTPS isn’t what was previously implemented in this ticket which was was DNSCrypt instead.
If DNS-over-HTTPS in Firefox/Chrome gets enabled by default then whatever this opt-in package would do would be much less effective. It would then be for system traffic except from usual major sources of traffic, the browsers.
Related:
True, eSNI would fix that but it’s not really used currently.
Maybe, although it’d be circumstantial and even then, there is still OCSP. There are probably other things that I haven’t thought of that leak this too. Would be good to do some of our own testing.
This study showing how esni is useful in some aspects in china:
And OCSP is a challenge need to be fixed as @madaidan said:
https://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-not-private/
I need to ask in the CF or FF forum/chat to see if they have or working on solution to that… ← (no need to ask as the ocsp stapling will be the answer)
Looks good. What about DNSSEC?
Some domains support it. Other’s don’t. Therefore probably nobody is setting their browsers or programs to only accept authenticated DNS replies.
This paper is nice as its relative to show aspects of clearnet DNS flaws and advantages of GNS.
This tool looks cool for system DNS.
maybe this can be added to ESNI advantages and compromises:
DNSSEC seems more useful in theory. Under the assumption that DNSSEC cannot be stripped similar to sslstrip… [1] [2]
DNSSEC can transmit information signed/authenticated information. (DNSSEC root trust key… [3]) Some such information can be potentially very worthwhile.
- CAA policy:
- CAA policy is written in DNS which can restrict which CA can issue certificates.
(DNS Certification Authority Authorization (CAA) Policy / DNSSEC for whonix.org / ssllabs.com test results / OCSP ERROR: Exception: connect timed out [http://r3.o.lencr.org] / Must-Staple) - CAA policy is similar to CA pinning. Unfortunately, CAA policy is only consumed by CA authorities to check if they are allowed to issue a certificate for a website. A malicious/hacked CA might ignore it. But then there is nowadays certificate transparency logs so such CA would be spotted and expelled. I recognize that doesn’t help the victims of successful MITM in case of a compromised CA.
- Unfortunately browsers do not check CAA policy from DNS. [4]
- CAA policy is written in DNS which can restrict which CA can issue certificates.
- DANE TLSA [5] [6]
- In short: use DNS (authenticated by DNSSEC) to authenticate the TLS certificate.
- Not an option for browsers yet, or ever(?) but perhaps good for mail servers? Didn’t investigate that.
- Other seemingly less important DNS entries such as SPF, DKIM, DMARC.
Can browsers such as Firefox, Chrome, Tor Browser verify DNSSSEC and can these be DNSSEC striped
in their current default configuration? If yes, are fixes planned? I mean, if a domain was DNSSEC signed and the signature was stripped, would these browsers reject the connection?
[1] Let’s call that DNSSEC strip
?
[2]
[3] Ignoring the issue of who is holding the highest hierarchy DNSSEC root signing key. At least it is a different key holder than the many trusted key holders in the TLS CA system.
[4] public key infrastructure - Why don't browsers check CAA records to help ensure a certificate is valid? - Information Security Stack Exchange
[5] Dev/About Infrastructure - Kicksecure
[6]
It’s in Debian.
https://packages.debian.org/search?keywords=dnscrypt
Kicksecure was previously enabling it by default. Considering an opt-in package to easily enable it.
I think it’s better to download the package from here - Release 2.0.44 · DNSCrypt/dnscrypt-proxy · GitHub
Unpack.
Run:
$ sudo ./dnscrypt-proxy
Thus, it can be used when needed.
Can be installed as a service.
I don’t see any reason for this. And there are reasons against that:
Unbound
(in Debian [archive]) is a is a validating, recursive, and caching DNS resolver with DoT and DoH support
However, at time of writing the Debian Unbound
package does not enable DoH [archive].
In context of censorship circumvention, routing DoT over Tor is possible and fast enough according to the DoHoT: making practical use of DNS over HTTPS over Tor [archive].
Root name servers [archive] do not support encryption yet [archive].
Wouldn’t it be possible to use DNSSEC and DoT within systemd instead?