search

DNSCrypt / dnscrypt-proxy

dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols.
https://dnscrypt.info
ISC License
11.39k stars 1.01k forks source link

WARNING: DNScrypt's new built in DoS/De-Anonamization exploit #1255

Closed ravenise closed 4 years ago

ravenise commented 4 years ago

New option in the [anonymized_dns] section: skip_incompatible, to ignore resolvers incompatible with Anonymized DNS instead of using them without a relay.

Calling all Hackers: DNScrypt now includes an auto de-anonamyzing/DoS CVE, any DNScrypt server or MITM can exploit with a simple DoS/de-anonamization attack by simply blocking or not responding to packets over 1500 bytes.

This can be exploited by a MITM, middle box blocking packets over 1500 bytes between the anonamous relay and DNScrypt server.

ravenise commented 4 years ago

Via MITM, the built in exploit can be used to DoS/de-anonamize users using any Dnscrypt server over relays. Not just so called "incompatible" servers.

ravenise commented 4 years ago

The current versions of the dnsdist load balancer (presumably used by quad9, cleanbrowsing, qualityology, freetsa.org, ffmuc.net, opennic-bongobow, sth-dnscrypt-se, ams-dnscrypt-nl and more) is preventing queries over 1500 bytes from being received over UDP. Temporary workarounds have been introduced to improve reliability with these resolvers for regular DNSCrypt. Unfortunately, anonymized DNS cannot be reliable until the issue is fixed server-side. dnsdist authors are aware of it and are working on a fix already have a fix.

If this feature exploit is not removed then clearly you have intentionally compromised and broke your software to prevent anonymity and deny service to anyone using relays.

ibksturm commented 4 years ago

@ravenise men, whats your problem? keep calm, drink a cold beer and go back to version 2.39

jedisct1 commented 4 years ago

Using any old dnscrypt-proxy version, try resolving big.stdc.org using one of these resolvers, via any relay.

You won't get any response, just a timeout. With a web browser you would get an error page and reloading or rebooting would never fix it. If you inspect the network traffic, you will see that these servers didn't send anything back.

Try with a different resolver and the same relay, or, really, any other configuration, and you will instantaneously get the DNS response.

This is due to a bug in the software these particular servers are running.

The bug has been found and fixed today.

As soon as they deploy a version without the bug, these servers can be used via relays. They will always return responses to valid queries instead of timing out.

Automatically falling back to a direct connection when this issue is detected allows people to have something reliable with the same security as DoH instead of a half-broken DNS service. And this can be disabled with the skip_incompatible parameter.

If you are happy with something that will never resolve some of your DNS queries, you can stick to version 2.0.39, as the only improvements in the current version are to work around that bug, which has implications beyond relaying (resolution may stop working after a couple large responses are received).

For anonymization, you can also use Tor instead of DNS relays. The bug is related to UDP, and Tor uses TCP.

Meanwhile, it's been a long road, but I'm really happy that the root cause of that long standing issue has been finally found and fixed, and that we have a client proxy that can detect and skip half-working configurations.