That would be good. I didn’t like breaking the host metapackage when I removed it.
DNSCurve is another one.
systemd-resolvd has basic support for DNSSEC and DoT, but it is not suited for Kicksecure. There are no hardening options and It can’t authenticate DoT servers. Might not be too bad if resolvd was given a pointer to a local daemon that was better. I will look around and report back later.
DNSCrypt hasn’t been submitted to the IETF, but everything else is good. It is better in regards to security and privacy issues, and has more options for authentication. An updated version of the protocol adds a relaying feature for anonymity. Dnscrypt-proxy is the only Debian solution for clients.
DNS over TLS is recognized by the IETF. It is a wrapper for regular DNS requests. There are are disadvantages for Kicksecure using it. DoT is vulnerable to security issues, monitoring/blocking, and fingerprinting. There are performance issues. Unbound, Knot resolver, Stubby, and systemd-resolvd support DoT. Systemd-resolvd DoT connections are opportunistic and will automatically downgrade connections to plaintext.
DNS over HTTPS is also recognized by the IETF, and it has less problems than DoT. It can be used easily within applications and should have good performance. Dnscrypt-proxy is the only debian package that can enable system-wide use, but Github has some projects that use Curl for that purpose.
All three solutions are supported by industry (Google, Cloudflare, Quad9) and community (i.e. smaller company and hobbyists) servers. DoT seems to have the least amount of community support, but there is no complete list and I might have missed some. By the way, Quad9 has direct links to law enforcement in the UK and US.
Is there anything I can do to help troubleshoot dnscrypt?
That would be good. Set it up, use it, document, fix, propose solutions.
Understood. I need to give it a low priority, but I will work on it when I can.
@Patrick I looked at DNSCrypt in Kicksecure VM (current packages). It works. (My problem was a restrictive firewall.) Hope to look at a baremetal later in case there are any differences.
Like claimed, dnscrypt made only a single request to Quad9, then went to configured servers after that. Tunneling requests through tor works, but dnscrypt-proxy handshakes with servers in the clear. Bad from a correlation standpoint for those who want to use that method. (There are also some fingerprinting issues created by the client, but IMO not important unless clearnet connections can be stopped.)
DNSCrypt-proxy bootstraps much faster than tor does, so I tried modifying “wants” in /lib/systemd/system/dnscrypt-proxy.service.d/ so that dnscrypt would wait until Tor has bootstrapped. It did, but dns servers still connected to in the clear. Not sure how to proceed.
Also, some of the dns servers are down. That will be a problem, no matter how many times a list is made. Another implementation of dnscrypt can autoselect servers with ‘no filter’, ‘no log’, and ‘require dnssec’ provisions. Maybe dnscrypt-proxy can do this as well? That would reduce maintenance burden.
Thoughts?
If anyone has any problems with dnscrypt, tell me.
Interesting. I guess DNSCrypt by default will cause too many issues.
Bad. Shouldn’t do this. That would be a bug in DNSCrypt if it ignores the proxy sometimes. Could you please report this upstream against DNSCrypt?
That would be a good fix for reliability / connectivity / usability but functional Tor shouldn’t be a requirement for non-leaking (not using Tor) DNSCrypt.
Big issue indeed. I guess ISP provided DNS servers will always be more reliable than DNSCrypt network provided DNS servers.
Dunno. But that would be good.
Nah, the firewall responsible only allowed Tor-specific outgoing ports, and it’s very restrictive. Not many people use that, and I had forgotten that’s why I had the problem.
Maybe. I would like to start doing bug reports, but I don’t have accounts yet.
Right. It was part of my process to see if DNSCrypt would only use tor.
That would be debatable. ISP servers can give unwanted redirect, do blacklist, and use information for commercial purposes. Some ISPs are probably more reliable than others. The most reliable are going to be 8.8.8.8, 1.1.1.1, etc.
Good news is that dnscrypt-proxy can import lists of servers (i.e. from Github) and I believe should honor those provisions. I’ll report back on that soon.
Dnscrypt-proxy can autoselect servers from the source file and they obey directives like ‘require_nofilter=true’, so it should make maintenance easier.
I made some changes to kicksecure.toml. Take a look and let me know if it is useful. This revision has no preselected servers, along with some other changes. I have added other source lists which are disabled, but they should interest some users. These lists have a single point of failure because they are maintained by the same guy, but there are mirrors. I included some for each source list.
I also added a section for DNSCrypt’s “anonymized DNS” feature. It is an end-user configurable option so it’s disabled. Notes for all of that. I also added a note about that proxy obedience bug in the tor section.
I haven’t tested anonymized dns yet, nor the other sources lists. I made sure the sigs and addresses are correct.
# Empty listen_addresses to use systemd socket activation
listen_addresses = []
## https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/example-dnscrypt-proxy.toml
## Server List Discussion
## https://forums.whonix.org/t/use-dnscrypt-by-default-in-kicksecure-not-whonix/8117/3
#server_names = [
#]
force_tcp = true
require_dnssec = true
require_nolog = true
require_nofilter = true
## Tunnel through Tor. Requires "force_tcp".
## Handshakes use a direct connection due to a bug in dnscrypt-proxy.
proxy = "socks5://127.0.0.1:9050"
## Anonymized DNS. Must be chosen manually.
## Server name accepts ( * ) as a wildcard.
## https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-DNS
#[anonymized_dns]
#routes = [
# { server_name='example-server-1', via=['anon-example-1', 'anon-example-2'] }
#]
## debugging
#cache = false
#log_level = 0
[query_log]
file = '/var/log/dnscrypt-proxy/query.log'
[nx_log]
file = '/var/log/dnscrypt-proxy/nx.log'
[sources]
[sources.'public-resolvers']
urls = ['https://download.dnscrypt.info/resolvers-list/v3/public-resolvers.md', 'https://dnsr.evilvibes.com/public-resolvers.md', 'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md']
cache_file = '/var/cache/dnscrypt-proxy/public-resolvers.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
refresh_delay = 72
prefix = ''
## Opennic is a non-national alternative to ICANN. Not compatible with DNSSEC.
# [sources.'opennic']
# urls = ['https://download.dnscrypt.info/dnscrypt-resolvers/v3/opennic.md', 'https://dnsr.evilvibes.com/opennic.md', 'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/opennic.md']
# cache_file = '/var/cache/dnscrypt-proxy/opennic.md'
# minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
# refresh_delay = 72
# prefix = 'opennic'
## Tor Onion DNS servers. Currently the only provider is Cloudflare.
# [sources.'onion-services']
# urls = ['https://download.dnscrypt.info/dnscrypt-resolvers/v3/onion-services.md', 'https://dnsr.evilvibes.com/onion-services.md', 'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/onion-services.md']
# cache_file = '/var/cache/dnscrypt-proxy/onion-services.md'
# minisign_key: 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
# refresh_delay = 72
# prefix = 'onion-dns'
## Anonymized DNS relays.
# [sources.'relays']
# urls = ['https://download.dnscrypt.info/resolvers-list/v3/relays.md', 'https://dnsr.evilvibes.com/relays.md', 'https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/relays.md']
# cache_file = '/var/cache/dnscrypt-proxy/relays.md'
# minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
# refresh_delay = 72
# prefix = 'dnscrypt-relay'
#### meta start
#### project Kicksecure
#### category networking and dns
#### description
## DNSCrypt configuration
#### meta end
Yes, very helpful!
Now that DNSCrypt enabling was removed from kicksecure-network-conf, do you think you could invent a new package with name dnscrypt-enable?
Thank you!
I have never done that before. Can you provide me with a link to resources that can guide me?
I don’t know any good Debian package creation tutorials. Lots of online tutorials focus on compiled code which is a lot harder to get right than shipping shell scripts / configuration files which Whonix is doing.
Building documentation:
And how the file placement looks like can be inferred from many Whonix packages. List:
Looking at examples might be easier than trying to write it in an abstract way.
Also https://gitlab.com/whonix/kicksecure-network-conf is a nice, simple example.
You’d have to “undo” in a new repository:
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:
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.
Indeed.
Depends. On first visit of the website could be victim to sslstrip.
DNS Certification Authority Authorization (CAA) Policy can help.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)