Open rugk opened 8 years ago
adrelanos
commented
8 years ago DNSCrypt does not encrypt end-to-end. It moves the trust from ones ISP to the server running DNSCrypt.
I am not convinced this is worth being installed by default in Qubes.
Do we want to get into the business of judging that some server does a better job at not spying on DNS than users ISPs? That is such an individual choice. More so, which server one trusts.
rugk
commented
8 years ago DNSCrypt does not encrypt end-to-end
Depends on how you define it. It encrypts end-to-end from DNS server to client.
It moves the trust from ones ISP to the server running DNSCrypt.
Wrong. It moves trust from no trust at all (= anyone can hijack/modify it) to (at least) some DNS server provider the user chooses to use&trust.
Do we want to get into the business of judging that some server does a better job
No, users can (& should) choose the servers by themselves. DNSCrypt includes a list of supported servers.
better job at not spying on DNS
Also with DNSCrypt the dns server hoster can "spy" on DNS. That's not the issue here. The issue is that anyone can spy and modify on DNS requests as they are usually unencrypted.
than users ISPs
Also ISPs could run a dnscrypt dns server. :wink:
That is such an individual choice. More so, which server one trusts.
Yes, and that's why users must choose the server to trust. DNSCrypt is about the connection to this server, which should be secured.
adrelanos
commented
8 years ago What does it actually protect against? Against weak adversaries, who would read cleartext DNS requests but that are not motivated to break Tor? That is a fundamental decision if such weaker defenses are worth going for. For serious hiding of DNS traffic, traffic should be routed through Tor.
It moves trust from:
To:
Qubes wants to become more usable. That includes coming with safe defaults. And not asking users any questions where they are likely to make bad choices.
Which server should present in the question? All from this list?
https://raw.githubusercontent.com/jedisct1/dnscrypt-proxy/master/dnscrypt-resolvers.csv
And should a gui be invented that runs at first boot where the user should choose?
I am reasonable advanced user, and I wouldn't know why I should trust one of these servers from this list more than another or more than my ISP. Being presented with such a choice at first boot would be confusing.
I'd have to set up my own DNSCrypt server. But then I would have to trust the ISP of the server more than my own ISP. There may be situations where one individually judges that this is useful. But I doubt we should make that decision by default for all users.
Perhaps have a list of "good" and "bad" countries? As in known to tamper with DNS traffic. Censorship, perhaps malicious redirects. Then automatically redirect DNS from "bad" countries to "good" countries?
Or when users state they are using an untrusted network, automatically encrypt and redirect their DNS traffic to some server?
It sounds nice at first, but it's a rabbit hole.
rugk
commented
8 years ago For serious hiding of DNS traffic, traffic should be routed through Tor.
Of course, but this if for daily use.
And should a gui be invented that runs at first boot where the user should choose?
You're right, that's not a good idea. I mean maybe you can also implement this feature as "disabled by default" and when users inform themself about DNSCrypt they can use.
Or when users state they are using an untrusted network, automatically encrypt and redirect their DNS traffic to some server?
This might be an idea.
In any case I think it is a clear advantage that DNS requests are protected "in the last mile" from the DNS server to the client, as this is usually the weakest link. As explained on the project website DNSCrypt protects this part against attacks such as modification of the requests.
InnovativeInventor
commented
7 years ago It could be an option that can be set up by users who are interested in DNSCrypt
adubois
commented
6 years ago No arm is stacking tor with it? or is there? If you want I can document it, I just need to migrate my blog posts: http://bowabos.blogspot.co.uk/2013/11/how-to-set-up-dnscrypt-proxy-on-qubes-os.html
adrelanos
commented
2 years ago Linking all the DNS security related ticket together:
adrelanos
commented
2 years ago @rugk:
DNSCrypt provides confidentially, integrity and protects against sniffing DNS queries, which are by default unencrypted and unauthenticated allowing DNS redirection attacks.
DNSCrypt might not be validating DNSSEC signatures yet: https://github.com/DNSCrypt/dnscrypt-proxy/issues/167#issuecomment-367689381
To clarify, as feature request, created: https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1954
I'd suggest you to integrate DNSCrypt into Qubes OS. Preferably so that all VMs automatically use this as a DNS resolver.
DNSCrypt provides confidentially, integrity and protects against sniffing DNS queries, which are by default unencrypted and unauthenticated allowing DNS redirection attacks. It uses the well-known and -tested library NaCl (respectively it's fork Libsodium).