4 ms·

It’s progress if you control your devices, or you don’t control your network. I don’t. Like most people I can control my network. I have all sorts of crap on

by iso947 6y ago

It’s progress if you control your devices, or you don’t control your network. I don’t. Like most people I can control my network. I have all sorts of crap on my network from Bose and amazon and Nintendo and Apple etc on my IoT vlan. Without going to a monk style digital life aka RMS, the best bet is to segment them into a secure network and limit what they can communicate with. The DOH Culture and the like takes away my freedoms.

JoshTriplett 6y ago
Then complain about devices that hardcode settings and don't allow changing them, rather than complaining about people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way.
- xg15 6y ago
  Complain to who exactly? > people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way. In this case, standardization makes a huge difference. Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the packets, as described in this subthread. Any more interception-proof solutions would have involved designing a custom network protocol, running a custom server and implementing custom bootstrapping logic to connect the device to the server - and even then, the traffic would stand out enough than an admin could still block or redirect it easily enough. With DoH, there are publicly accessible servers that accept requests over plain HTTPS: This means, someone who wants to keep their ads from being blocked does not need to run any server infrastructure and does not need to fiddle with network code at all - they can just drop in a DoH client library, hardcode a list of public DoH servers and client certs and be done. This is absolutely a game-changer.
  - JoshTriplett 6y ago
    > With DoH, there are publicly accessible servers that accept requests over plain HTTPS Which is a good thing for end users on balance. The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such; any such mechanism completely breaks the security properties this is trying to achieve. Ultimately, your choice with uncooperative devices is "block the device or don't" (in addition to isolating it on a separate network), along with "replace it with a cooperative device". Stop telling people they need to stop using encryption so that your local network interception will keep working, because your local network interception is indistinguishable from other people's local network interception. This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security. There are enough outside opponents of Internet security; let's not start holding back security ourselves because it makes our own hacks stop working. We have enough work to do fighting for the ability to keep the Internet secure against real adversaries. We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.
    - Reelin 6y ago
      > there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them" That's not what I see at all. I see people pointing out that DoH hurts privacy and reduces control for end users by providing a convenient turnkey solution for device vendors to bypass filtering at the network level. I also see it pointed out that DoH could have been specified in a way that facilitated filtering for the local network. Given that it's so obviously possible, the fact that it wasn't speaks volumes. Note that (IIUC) your ISP can still see which sites you visit because TLS still transmits the FQDN in plaintext (https://security.stackexchange.com/questions/86723 https://security.stackexchange.com/questions/86723). Even if that stopped happening tomorrow, the destination IP would still be visible (not quite as bad but still reveals a huge amount of information). On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result. As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit. I don't find that to be very compelling in light of the immediate downsides.
SAI_Peregrinus 6y ago
This isn't new to DoH. Malware has used alternatives to DNS for getting command & control server IPs for decades. IRC used to be common, for example.
- iso947 6y ago
  IRC easilly slotted and controlled.
  - SAI_Peregrinus 6y ago
    Yes. Which is why it's no longer as popular. The point is that malicious actors have never followed the system's preferences on how to look up server IPs, so why the hell should they start now? DNS blocking hasn't worked up to now, why complain that it's suddenly broken?

by iso947 6y ago

JoshTriplett 6y ago

Then complain about devices that hardcode settings and don't allow changing them, rather than complaining about people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way.

xg15 6y ago
Complain to who exactly? > people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way. In this case, standardization makes a huge difference. Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the packets, as described in this subthread. Any more interception-proof solutions would have involved designing a custom network protocol, running a custom server and implementing custom bootstrapping logic to connect the device to the server - and even then, the traffic would stand out enough than an admin could still block or redirect it easily enough. With DoH, there are publicly accessible servers that accept requests over plain HTTPS: This means, someone who wants to keep their ads from being blocked does not need to run any server infrastructure and does not need to fiddle with network code at all - they can just drop in a DoH client library, hardcode a list of public DoH servers and client certs and be done. This is absolutely a game-changer.
- JoshTriplett 6y ago
  > With DoH, there are publicly accessible servers that accept requests over plain HTTPS Which is a good thing for end users on balance. The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such; any such mechanism completely breaks the security properties this is trying to achieve. Ultimately, your choice with uncooperative devices is "block the device or don't" (in addition to isolating it on a separate network), along with "replace it with a cooperative device". Stop telling people they need to stop using encryption so that your local network interception will keep working, because your local network interception is indistinguishable from other people's local network interception. This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security. There are enough outside opponents of Internet security; let's not start holding back security ourselves because it makes our own hacks stop working. We have enough work to do fighting for the ability to keep the Internet secure against real adversaries. We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.
  - Reelin 6y ago
    > there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them" That's not what I see at all. I see people pointing out that DoH hurts privacy and reduces control for end users by providing a convenient turnkey solution for device vendors to bypass filtering at the network level. I also see it pointed out that DoH could have been specified in a way that facilitated filtering for the local network. Given that it's so obviously possible, the fact that it wasn't speaks volumes. Note that (IIUC) your ISP can still see which sites you visit because TLS still transmits the FQDN in plaintext (https://security.stackexchange.com/questions/86723 https://security.stackexchange.com/questions/86723). Even if that stopped happening tomorrow, the destination IP would still be visible (not quite as bad but still reveals a huge amount of information). On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result. As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit. I don't find that to be very compelling in light of the immediate downsides.

SAI_Peregrinus 6y ago

This isn't new to DoH. Malware has used alternatives to DNS for getting command & control server IPs for decades. IRC used to be common, for example.

iso947 6y ago
IRC easilly slotted and controlled.
- SAI_Peregrinus 6y ago
  Yes. Which is why it's no longer as popular. The point is that malicious actors have never followed the system's preferences on how to look up server IPs, so why the hell should they start now? DNS blocking hasn't worked up to now, why complain that it's suddenly broken?