blokada
blokada copied to clipboard
blokadaorg
Support DNS-over-TLS / DNS-over-HTTPS
With more dns servers like Cloudflares supporting encrypted DNS, would be nice if that could be supported through blokada? Not sure how doable it is/how much blokada relies on android's internal logic for DNS requests, but it would be nice if it would work, not everyone has a rooted device with support for DNScrypt
Hi. I completely agree with you. DNS requests are normally not encrypted meaning that they can be tracked or redirected to a dangerous site. Encrypting the traffic through HTTPS/DNSCrypt protocol would be a major improvement on both a privacy and security.
Seconded! I live in a country where the government is poisoning our DNS. I'd really appreciate it if Blokada somehow can listen to non-53 port. It'll help unrooted devices poised to not receive Android P update a lot. I once asked DNS66 dev to do it and the dev seemed to think it's achievable, although the project now seems to hit a wall.
FWIW Android P is coming with DNS over HTTPS built-in, but I'm not sure if Blokada messes with it in any way.
I've just done some tests and unfortunately, the "private DNS" settings of Android P seem incompatible with Blokada (and VPN's in general).
Even when Blokada is set to use the "default DNS" of the device, it reverts back to the default DNS given by DHCP rather than the private DNS the user specified.
When cloudflare is explicitly selected in Blokada, it uses the standard DNS lookup instead of DNS-over-TLS (hardly unexpected).
I think DNS-over-TLS needs to be baked into Blokada itself.
Don't know about Android coding but there mention of an API in an Android Dev blog post: https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
Maybe it is possible to send the dns request to Pie's Private DNS through this API? Make a new DNS option in the Blokada list to use Pie's Private DNS?
@iron2000 looking at the api, seems like the only thing it does is returning True or False based on wether Android's current DNS is encrypted or not, don't see anything related to changing/setting up a secure DNS connection
@jeroen7s That's true, the API isn't very useful. But from what I understood from reading it, using Android's regular DNS query system will automatically encrypt the requests. Perhaps adding an option to have Blokada use native DNS would be sufficient?
DNSCrypt may be the way to add not only encrypted DNS, but to also include DNS validation. All the resolvers are OpenDNS, but unlike the official Cisco ones, many do not log. 32 currently with DNSSec including Cloudflare https://github.com/jedisct1/dnscrypt-proxy Some use filters, most do not. The list comes as a CSV file so clients can easily filter wanted/unwanted resolvers
google has released a new app to "protect against government censorship" it's basically just an app to change DNS to google/cloudflare and adding an encrypted layer onto it using DNS-over-https they also released the source code, so it might be usefull to take a look at it to implement DNS-over-https in blokada? anyway source code is here: https://github.com/Jigsaw-Code/Intra
As far as I can see, all that Intra app does is change the DNS in your droid to ones that use DNSSec. It does not add any authentication
First line of the readme specifically mentions it uses dns-over-https Maybe it uses dns-sec to authenticate the dns-over-https URL? I'm assuming the readme is accurate
I wonder how Blokada works with Android 9 internal DoT implementation: https://security.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
Cloudflare released an app which supports DoH and DoT. https://blog.cloudflare.com/1-thing-you-can-do-to-make-your-internet-safer-and-faster/
then help us to implement it :) you can access the source code, hurry up! Or if you can't let us know if you have a developer who can join our team and can assist with coding.
To clarify, Authentication is not the same as DoT or DoH, or DNSSec. They "encrypt domain name lookups and prevent manipulation by your network."
It does not authenticate the DNS, so does not protect against DNS spoofing or "Man-in-the-middle" attack which can also be using DoT/DoH/DNSSec.
For authentication the client needs to have a separate list of keys for the resolvers, just like browsers use the keys in a trusted store of certificates.
DNSCrypt uses DoH uses Cloudflare, Quad9, OpenDNS and more. Load balances to use the fastest from multiple resolvers some of the resolvers use blocklists so can be used for blocking malware or adult sites.
I am actually wondering if, as nobody has yet made a distributable DNSCrypt app, that perhaps you could make it as another security app to offer and compete with the cloudflare/google app? Or as the google playstore version of Blokada is limited to just manage DNS, it could also be the app to put DNSCrypt in.
@Dr-Flay dnscrypt isnt needed anymore with DoH / DoT. All three ways encrypt the DNS data. Also yes encrypted DNS doesn't protect against spoofing but against MitM
@beerisgood Perhaps read my comment again. DNSCrypt adds the missing "Authentication" as well as encryption. DNS spoofing, is a MitM attack. This is becoming more common.
Encryption will not stop you getting encrypted lookups via a bad DNS. Authentication will add validation and verification, on top of the standard encryption. Google (cloudflare) are not offering authentication. (also it is Google so do you really trust them?)
Idk where you got that DNS-over-https doesn't include authentication, HTTPS is an authenticated and encrypted protocol
Certificate authorities are used to verify if the server you're talking to is legit, and not some man in the middle
https isn't an authenticatuon. A TLS cert just proves that the host you connect to is the one you really wanna connect (like the ID card for humans)
"proves that the host you connect to is the one you really wanna connect to" - how is that not authenticating (verifying) the DNS server is not a middleman
that's verification. Authentication is when you use username and password, or a keytab on KDC or AD server, proving you have access to the given service. With TLS cert, no authentication happens, just a handshake between the server and client. Read about how a TLS connection is built up if you want the details.
Using certificates is also authentication, server authenticates to the user using a valid certificate, it's not only authentication when a user proves it's identity to a server, but also when a server proves it's identity to a user. In relation to user validating to a DNS server, I really don't see what valid use-case there is in a user authenticating to a DNS server? Unless the server wants to store dns request logs per user-account across multiple devices or something like that
Anyway, what @Dr-Flay said is just incorrect, both DoH and DoT provide protection against MitM attacks by authenticating the server
The problem is that certificates are minted for domains. If the user has a trusted key chain that matches the IP addresses, then you can validate you are on the correct IP as well as domain. It is possible that the google/cloudflare client has this extra, but I can find anything in the blurb about it, just traditional cert style authentication.
Yes DoT has optional authentication and it is enforced in DoH, but as far as I see they only solve half of the problem.
Same issue for an HTTPS website that may even be using DNSSec but has not registered the DANE/TLS details (very common). Hooray the domain shows a valid cert authenticated by a 3rd party \o/ ....but cannot be matched to the registered IP so could be a faked/injected domain.
As I say if these new clients are also matching the cert to the domains, and IPs to the domains everything is groovy, but in than case someone can point me at a reference.
However, even if users are using DNSSec, most websites do not, and those that do generally do not configure it properly, it still allows for MitM attacks. To be honest it is all rather a moot point, as currently no browsers will report the mismatch error or try to block access. The reason certs work for sites is because browsers act upon the info in them. With DNSSec nothing does anything about it. Our browsers should be showing DNSSec errors on most of the HTTPS sites we all use regularly but they don't. https://dnssec-name-and-shame.com/domain/github.com
The thing is DNSsec is barely used, so it's disabled bu default in most browsers and operating systems Dns-sec is correctly configured for cloudflare: https://dnssec-name-and-shame.com/domain/cloudflare-dns.com So they shouldn't be able to MitM Cloudflares DoH connection
I don't really understand this part:
Hooray the domain shows a valid cert authenticated by a 3rd party \o/ ....but cannot be matched to the registered IP so could be a faked/injected domain.
If a malicious server somehow manages to hijack a servers DNS, how would that server get a valid certificate for HTTPS encryption for that domain without somehow stealing the private key from the original domain?
@izzyos have you ever considered that kar may have maybe a life besides blockada? Gotta feed the family somehow
@animeking9901 we all have a life, we all work and we all wanna build good products. enough with this stupid old argument.
I agree with @animeking9901. Blokada is FOSS project, so if you, @izzyos, can't contribute code (like this more complex requested feature), maybe you should donate some money to this project:
https://blokada.org/api/v3/content/en/donate.html