4 ms·

If you are on a trusted network or have a VPN into a trusted network this is not an issue, you can run your own recursive resolver. The real issue is the traffi

If you are on a trusted network or have a VPN into a trusted network this is not an issue, you can run your own recursive resolver. The real issue is the traffic between your resolver and the authoritative servers. Using someone else's resolver (secure transport or not) just changes who you're leaking the information to, not the fact that you're leaking.

tyingq 7y ago
Wouldn't you be much less personally identifiable one hop upstream?
tptacek 7y ago
This sounds profound but isn't really saying much, is it? At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to (which is to say, who you choose to trust). And, in the DoH/DNSCrypt case, almost nobody trusts their ISP, so these protocols are valuable.
- vinniejames 7y ago
  ISPs can still see the IP your requests resolves to, and in many cases can still track this info. Unless the site is using shared IP, like many behind caching services, etc
  - mantap 7y ago
    To your caveat, I can access thepiratebay even though it is supposedly IP blocked in the UK because the courts are not willing to order a block of the whole cloudflare IP range. With so many websites using cloud hosting, it has become very hard for the authorities to block IP ranges. DNS is really the last bastion of government interference. The UK is supposed to be rolling out a nation-wide porn block at some point but it will be totally defeated by encrypted DNS.
    - deleted 7y ago
      [deleted]
    - deleted 7y ago
      [deleted]
    - throwawaydoh 7y ago
      My Indian ISP blocks certain sites. I use Firefox and has DNS over HTTPS with CloudFlare enabled. I also use CloudFlare's 1.1.1.1 DNS in my router. The sites are still blocked. Firefox shows the error "Secure Connection Failed. An error occurred during a connection to 'site url'. PR_CONNECT_RESET_ERROR". When I search for this error, one of the first results say "this behavior is fairly typical for DPI firewalls". To anyone knowledgeable about this: How can I confirm if my ISP is using DPI?
      - StreamBright 7y ago
        https://security.stackexchange.com/questions/108985/is-it-possible-to-detect-dpi-deep-packet-inspection https://security.stackexchange.com/questions/108985/is-it-po...
      - tgragnato 7y ago
        Find an (allegedly) blocked website that is using CloudFlare and has TLS 1.3 enabled. In about:config set network.trr.mode=3, network.security.esni.enabled=true, security.OCSP.enabled=0, security.tls.version.max=4, security.tls.version.min=4. Exit, open Firefox again; if the website loads, then your ISP is using a DPI middlebox.
        throwawaydoh 7y ago
        Thank you. Unfortunately, I wasn't able to find a blocked site that has TLS 1.3 enabled. I checked 3 blocked sites after enabling the options you suggested. They were still blocked. I confirmed all 3 didn't have TLS 1.3 by testing them with ssllabs ssltest. All had results show TLS 1.3 as "No".
        7y ago
- the8472 7y ago
  Fundamentally you have 3 problems 1. securing client - recursive resolver traffic 2. trusting the recursive resolver 3. securing recursive-authoritative traffic. 1. and 2. can both be solved by running your own resolver, either locally, on your gateway or on a VPS reachable via VPN. But doing so makes you more vulnerable to 3. since fewer devices will be pooled behind a single resolver. Thus fixing 3 gives fundamentally a better improvement than futzing around with 1 or 2 where you're still at the mercy of a 3rd party. If you're serious about privacy then DoH/DNSCrypt-via-quad9/cloudflare/etc. just seem like a distraction. I mean sure, encrypting that traffic by default is not bad, but it's not a fundamental improvement. Also, I wouldn't say I trust my ISP, but at least it is under a GDPR jurisdiction. All the big resolvers that advertise encryption are under US jurisdiction, which makes any privacy promises seem hollow.
- xg15 7y ago
  > At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to (which is to say, who you choose to trust). Except in practice, you as an end-user seldomly have enough information or knowledge to determine if you should trust an entity or not - in fact, is often already expert knowledge to know how many entities are involved. Which is why practically, this question is decided by who has the most power - such as Mozilla in this case deciding all their users should trust Cloudflare. You're absolutely right, in the end, trust is what everything boils down to. I'd consider this an open issue and one of the root causes of many of the internet's problems.
- zzzcpan 7y ago
  > At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to They don't. As you can leak all your information to a single party or leak smallest necessary bits of information to each of many independent parties to the point where no single party can make any use of it or even decode it alone. Naturally for DNS encrypting communications to authoritative servers can actually improve privacy, while encrypting communications to a big centralized third party resolver and using it only has a negative effect on privacy.
troquerre 7y ago
DNS traffic is often resolved through ISPs even if you use a VPN. https://security.stackexchange.com/questions/13900/if-i-use-a-vpn-who-will-resolve-my-dns-requests https://security.stackexchange.com/questions/13900/if-i-use-...
- the8472 7y ago
  That's configurable and depends on your VPN use. If you just want to reach some internal corporate network ranges and have everything else go directly to the internet that's perfectly fine. If you're using a VPN for privacy reasons you have to set it up properly of course. On linux network namespaces can help with that where you can make sure that default namespace goes through your VPN and your ethernet device gets moved to a separate namespace that applications don't even see by default.
chewz 7y ago
DNSCrypt-proxy allows to send queries to random upstream DNS server or to better half of them. Spreading your queries along many servers makes them difficult to analyze. [1] https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/example-dnscrypt-proxy.toml https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscr...

tyingq 7y ago

Wouldn't you be much less personally identifiable one hop upstream?

tptacek 7y ago

This sounds profound but isn't really saying much, is it? At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to (which is to say, who you choose to trust). And, in the DoH/DNSCrypt case, almost nobody trusts their ISP, so these protocols are valuable.

vinniejames 7y ago
ISPs can still see the IP your requests resolves to, and in many cases can still track this info. Unless the site is using shared IP, like many behind caching services, etc
- mantap 7y ago
  To your caveat, I can access thepiratebay even though it is supposedly IP blocked in the UK because the courts are not willing to order a block of the whole cloudflare IP range. With so many websites using cloud hosting, it has become very hard for the authorities to block IP ranges. DNS is really the last bastion of government interference. The UK is supposed to be rolling out a nation-wide porn block at some point but it will be totally defeated by encrypted DNS.
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]
  - throwawaydoh 7y ago
    My Indian ISP blocks certain sites. I use Firefox and has DNS over HTTPS with CloudFlare enabled. I also use CloudFlare's 1.1.1.1 DNS in my router. The sites are still blocked. Firefox shows the error "Secure Connection Failed. An error occurred during a connection to 'site url'. PR_CONNECT_RESET_ERROR". When I search for this error, one of the first results say "this behavior is fairly typical for DPI firewalls". To anyone knowledgeable about this: How can I confirm if my ISP is using DPI?
    - StreamBright 7y ago
      https://security.stackexchange.com/questions/108985/is-it-possible-to-detect-dpi-deep-packet-inspection https://security.stackexchange.com/questions/108985/is-it-po...
    - tgragnato 7y ago
      Find an (allegedly) blocked website that is using CloudFlare and has TLS 1.3 enabled. In about:config set network.trr.mode=3, network.security.esni.enabled=true, security.OCSP.enabled=0, security.tls.version.max=4, security.tls.version.min=4. Exit, open Firefox again; if the website loads, then your ISP is using a DPI middlebox.
      - throwawaydoh 7y ago
        Thank you. Unfortunately, I wasn't able to find a blocked site that has TLS 1.3 enabled. I checked 3 blocked sites after enabling the options you suggested. They were still blocked. I confirmed all 3 didn't have TLS 1.3 by testing them with ssllabs ssltest. All had results show TLS 1.3 as "No".
        7y ago
the8472 7y ago
Fundamentally you have 3 problems 1. securing client - recursive resolver traffic 2. trusting the recursive resolver 3. securing recursive-authoritative traffic. 1. and 2. can both be solved by running your own resolver, either locally, on your gateway or on a VPS reachable via VPN. But doing so makes you more vulnerable to 3. since fewer devices will be pooled behind a single resolver. Thus fixing 3 gives fundamentally a better improvement than futzing around with 1 or 2 where you're still at the mercy of a 3rd party. If you're serious about privacy then DoH/DNSCrypt-via-quad9/cloudflare/etc. just seem like a distraction. I mean sure, encrypting that traffic by default is not bad, but it's not a fundamental improvement. Also, I wouldn't say I trust my ISP, but at least it is under a GDPR jurisdiction. All the big resolvers that advertise encryption are under US jurisdiction, which makes any privacy promises seem hollow.
xg15 7y ago
> At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to (which is to say, who you choose to trust). Except in practice, you as an end-user seldomly have enough information or knowledge to determine if you should trust an entity or not - in fact, is often already expert knowledge to know how many entities are involved. Which is why practically, this question is decided by who has the most power - such as Mozilla in this case deciding all their users should trust Cloudflare. You're absolutely right, in the end, trust is what everything boils down to. I'd consider this an open issue and one of the root causes of many of the internet's problems.
zzzcpan 7y ago
> At some point, most Internet protocol privacy issues boil down to who you're willing to leak information to They don't. As you can leak all your information to a single party or leak smallest necessary bits of information to each of many independent parties to the point where no single party can make any use of it or even decode it alone. Naturally for DNS encrypting communications to authoritative servers can actually improve privacy, while encrypting communications to a big centralized third party resolver and using it only has a negative effect on privacy.

troquerre 7y ago

DNS traffic is often resolved through ISPs even if you use a VPN. https://security.stackexchange.com/questions/13900/if-i-use-a-vpn-who-will-resolve-my-dns-requests https://security.stackexchange.com/questions/13900/if-i-use-...

the8472 7y ago
That's configurable and depends on your VPN use. If you just want to reach some internal corporate network ranges and have everything else go directly to the internet that's perfectly fine. If you're using a VPN for privacy reasons you have to set it up properly of course. On linux network namespaces can help with that where you can make sure that default namespace goes through your VPN and your ethernet device gets moved to a separate namespace that applications don't even see by default.

chewz 7y ago

DNSCrypt-proxy allows to send queries to random upstream DNS server or to better half of them. Spreading your queries along many servers makes them difficult to analyze. [1] https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/example-dnscrypt-proxy.toml https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscr...