7 ms·

> As much hassle as things like DoH can be for securing and enforcing policy on a network, it’s about time it became ubiquitous enough that governments can’t le

> As much hassle as things like DoH can be for securing and enforcing policy on a network, it’s about time it became ubiquitous enough that governments can’t leverage DNS for their own purposes anymore. A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Currently, most clients using DoH/DoT use one of a small handful of providers. Cloudflare, Google, Quad9, etc. A motivated government could block those endpoints pretty easily. Of course, a client using encrypted DNS could just refuse to work when encryption is blocked, rather than falling back to traditional DNS. But that could mean the client is unusable in the country implementing the block. This sort of reminds me of when Kazakhstan announced they were going to MITM all TLS sessions within the country, and all citizens would need to manually install a root cert. Google, Apple, and Mozilla chose to completely block their root cert, so it would be unusable even if users chose to go along with it. https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a... Seems like the browser devs won that political standoff, but would they fight the same battle if DoH/DoT was blocked?

klingoff 2y ago
If we make sure clients support proxies what are they going to do about all the proxies that may allow the DoH server list and may be the only way to do something else?
zarzavat 2y ago
This is the way. Few governments have the resources to play cat and mouse with OS or browser devs. Just look at the fuss over manifest v3, it shouldn’t be a big deal - just fork chromium and patch manifest v2 back in again - but it is because there’s no “just patching” chromium, it’s like a train.
- moi2388 2y ago
  [flagged]
  - Timshel 2y ago
    Humm, no: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#filtering-capabilities-which-cant-be-ported-to-mv3 https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...
    - moi2388 2y ago
      Uhm, yes. You can still apply rules with regard to all requests and then dynamically adept them. You just can’t do it before the request hits the browser, so you can’t pretend to be a vpn inside the browser. Blocking or redirecting all requests, based on dynamic values, adapting all headers through webrequest and not showing any ads and removing them from the page is still possible with service workers and content scripts. The only issue is with regards to “static” rules and modifying them before they hit the browser. After that you can still do everything you could before. The only issue is bandwidth, but this should always have been an app to intercept all network requests instead of something inside the browser (like a vpn adblocker)
      - zarzavat 2y ago
        If you use a VPN^ to block ads then the VPN needs to be able to see inside your TLS session. Moreover, you still need an adblocker inside the browser process to do DOM manipulation, etc. For example, the element picker. It’s technically possible to bifurcate an adblocker like that but it’s an ugly setup and you would only do it if a gun was held to your head by an ad monopoly. That said, it may be a good idea in the current situation. ^ This is really stretching the meaning of ‘VPN’!
        moi2388 2y ago
        But you can totally still block ads based on element picker and do DOM manipulation. That’s not an issue. The only two things you cannot do is declare them as static rules (well you can but not unlimited), and look and modify every header before it hits the browser. And yes, you could have an app with a browser extension like Adblock already did for years without issues. You could also have only a browser extension and have all the user functionality you have now, the only difference being it just slightly slower, and you still having the network load the ads (but not the page you’re on). A bit annoying? Sure. But it’s hardly the severe problem it’s being made out to be.
em-bee 2y ago
A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Currently, most clients using DoH/DoT use one of a small handful of providers. Cloudflare, Google, Quad9, etc. A motivated government could block those endpoints pretty easily. not if DNS is hosted on the same servers as eg google search itself. then they would have to block google search in order to block DNS.
- brookst 2y ago
  …or use higher-level packet analysis to filter DoH.
  - ronsor 2y ago
    That kind of DPI is computationally expensive to the point China doesn't even do it much.
    - myrandomcomment 2y ago
      OMG, they very much do. It is not on 100% of the traffic but at any given time a more then smaller % is subject to DPI.
    - inkyoto 2y ago
      Not anymore and mainland Chinese manufacturers sell them on in large numbers to autocratic governments. Such devices have a pretty simple architecture: the highly performant data plane where DPI is implemented in the hardware (using either ASIC's or FPGA's – don't have enough information), and the control plane. The control plane comes with a SDK of sorts that DPI appliance users can use to tailor the appliance to their environment and that is used to «refine» the data plane behaviour, i.e. sending down / updating DPI pattern matching / processing rules.
  - zamadatix 2y ago
    With HTTP/3 there isn't much higher level packet analysis to do between anything useful in the headers being encrypted and the session being reused. All you see is there is a 443 UDP session to a Google server and encrypted packets keep getting sent back and forth... which looks exactly like any other HTTP/3 session to a Google server. I think the weak points are wholly untechnical e.g. Google would often give in to protect the $$$ they make in a region.
Sophira 2y ago
> A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Unencrypted DNS also has to be bootstrapped by a well-known set of IPs. None of the current DNS propagation system would work if it wasn't for the hardcoded IPs for the root DNS servers at *.root-servers.net. And, of course, end-user devices still need an IP to query for DNS, it's just that it's almost always supplied automatically via DHCP or similar.

klingoff 2y ago

If we make sure clients support proxies what are they going to do about all the proxies that may allow the DoH server list and may be the only way to do something else?

zarzavat 2y ago

This is the way. Few governments have the resources to play cat and mouse with OS or browser devs. Just look at the fuss over manifest v3, it shouldn’t be a big deal - just fork chromium and patch manifest v2 back in again - but it is because there’s no “just patching” chromium, it’s like a train.

moi2388 2y ago
[flagged]
- Timshel 2y ago
  Humm, no: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#filtering-capabilities-which-cant-be-ported-to-mv3 https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...
  - moi2388 2y ago
    Uhm, yes. You can still apply rules with regard to all requests and then dynamically adept them. You just can’t do it before the request hits the browser, so you can’t pretend to be a vpn inside the browser. Blocking or redirecting all requests, based on dynamic values, adapting all headers through webrequest and not showing any ads and removing them from the page is still possible with service workers and content scripts. The only issue is with regards to “static” rules and modifying them before they hit the browser. After that you can still do everything you could before. The only issue is bandwidth, but this should always have been an app to intercept all network requests instead of something inside the browser (like a vpn adblocker)
    - zarzavat 2y ago
      If you use a VPN^ to block ads then the VPN needs to be able to see inside your TLS session. Moreover, you still need an adblocker inside the browser process to do DOM manipulation, etc. For example, the element picker. It’s technically possible to bifurcate an adblocker like that but it’s an ugly setup and you would only do it if a gun was held to your head by an ad monopoly. That said, it may be a good idea in the current situation. ^ This is really stretching the meaning of ‘VPN’!
      - moi2388 2y ago
        But you can totally still block ads based on element picker and do DOM manipulation. That’s not an issue. The only two things you cannot do is declare them as static rules (well you can but not unlimited), and look and modify every header before it hits the browser. And yes, you could have an app with a browser extension like Adblock already did for years without issues. You could also have only a browser extension and have all the user functionality you have now, the only difference being it just slightly slower, and you still having the network load the ads (but not the page you’re on). A bit annoying? Sure. But it’s hardly the severe problem it’s being made out to be.

em-bee 2y ago

A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Currently, most clients using DoH/DoT use one of a small handful of providers. Cloudflare, Google, Quad9, etc. A motivated government could block those endpoints pretty easily. not if DNS is hosted on the same servers as eg google search itself. then they would have to block google search in order to block DNS.

brookst 2y ago
…or use higher-level packet analysis to filter DoH.
- ronsor 2y ago
  That kind of DPI is computationally expensive to the point China doesn't even do it much.
  - myrandomcomment 2y ago
    OMG, they very much do. It is not on 100% of the traffic but at any given time a more then smaller % is subject to DPI.
  - inkyoto 2y ago
    Not anymore and mainland Chinese manufacturers sell them on in large numbers to autocratic governments. Such devices have a pretty simple architecture: the highly performant data plane where DPI is implemented in the hardware (using either ASIC's or FPGA's – don't have enough information), and the control plane. The control plane comes with a SDK of sorts that DPI appliance users can use to tailor the appliance to their environment and that is used to «refine» the data plane behaviour, i.e. sending down / updating DPI pattern matching / processing rules.
- zamadatix 2y ago
  With HTTP/3 there isn't much higher level packet analysis to do between anything useful in the headers being encrypted and the session being reused. All you see is there is a 443 UDP session to a Google server and encrypted packets keep getting sent back and forth... which looks exactly like any other HTTP/3 session to a Google server. I think the weak points are wholly untechnical e.g. Google would often give in to protect the $$$ they make in a region.

Sophira 2y ago

> A caveat of encrypted DNS is that it has to be bootstrapped via traditional, unencrypted DNS or via a well-known set of IPs. Unencrypted DNS also has to be bootstrapped by a well-known set of IPs. None of the current DNS propagation system would work if it wasn't for the hardcoded IPs for the root DNS servers at *.root-servers.net. And, of course, end-user devices still need an IP to query for DNS, it's just that it's almost always supplied automatically via DHCP or similar.