4 ms·

That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traff

That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy.

acdha 6y ago
You’ll note that I mentioned a proxy. That’s why: you need to force all traffic through a proxy you control or you’re just hoping that a client doesn’t use hard-coded IPs or an outside API of some source. If your network allows the client to send traffic to port 443 anywhere, any blocking is on the honor system.
- gnu8 6y ago
  My question here is how are you going to install your root certificate on a $300 smart TV? Or, if that is not required because the TV does not verify DoH certificates, how bad is that for security (which we already know is awful on these devices)?
  - acdha 6y ago
    This comes back to the core decision: do you care about controlling the network enough to block access? If the device can't be managed / is no longer supported the safest choice is not to allow it online at all. Different people will have different risk tolerances – it might make sense to put, say, a remote-control power switch on an IoT no-man's land network but if it has access to personal information or cameras/microphones it's not unreasonable to say it should just be blocked unless you're actively using those features.
  - fiddlerwoaroof 6y ago
    Well, it’d just block internet access there. I wonder if it’s possible to push a root to an Apple TV
    - nemosaltat 6y ago
      The Checkrain jailbreak [0] supports several Apple TVs, so I’d bet you could use use certbot to obtain a LetEncrypt [1] cert for it. Of course, jailbreaking opens up other security issues, so it goes back to what you can tolerate. [0] https://checkrain.org/ https://checkrain.org/ [1] https://letsencrypt.org/getting-started/ https://letsencrypt.org/getting-started/
    - ArchOversight 6y ago
      I know that you can install iOS profiles onto the Apple TV, I have done this for 802.1x support, which included a CA root for the 802.1x controller. I would imagine you can use this to push any certificate that you can also push to an iOS/iPadOS/macOS device.
      - fiddlerwoaroof 6y ago
        This is what I was thinking about.
rsync 6y ago
"That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy." This is a very good point and I am dealing with this myself on my home networks. Like any household/family we have some number of dubious/untrusted devices that still need Internet access. By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS. DoH breaks all of this. I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them". Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ... This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...
- acdha 6y ago
  > By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS. This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective. > Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query. It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.
  - rsync 6y ago
    "This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective." If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers. That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...
gsich 6y ago
Right now you can block the common IPs for the DoH servers and be fine.

acdha 6y ago

You’ll note that I mentioned a proxy. That’s why: you need to force all traffic through a proxy you control or you’re just hoping that a client doesn’t use hard-coded IPs or an outside API of some source. If your network allows the client to send traffic to port 443 anywhere, any blocking is on the honor system.

gnu8 6y ago
My question here is how are you going to install your root certificate on a $300 smart TV? Or, if that is not required because the TV does not verify DoH certificates, how bad is that for security (which we already know is awful on these devices)?
- acdha 6y ago
  This comes back to the core decision: do you care about controlling the network enough to block access? If the device can't be managed / is no longer supported the safest choice is not to allow it online at all. Different people will have different risk tolerances – it might make sense to put, say, a remote-control power switch on an IoT no-man's land network but if it has access to personal information or cameras/microphones it's not unreasonable to say it should just be blocked unless you're actively using those features.
- fiddlerwoaroof 6y ago
  Well, it’d just block internet access there. I wonder if it’s possible to push a root to an Apple TV
  - nemosaltat 6y ago
    The Checkrain jailbreak [0] supports several Apple TVs, so I’d bet you could use use certbot to obtain a LetEncrypt [1] cert for it. Of course, jailbreaking opens up other security issues, so it goes back to what you can tolerate. [0] https://checkrain.org/ https://checkrain.org/ [1] https://letsencrypt.org/getting-started/ https://letsencrypt.org/getting-started/
  - ArchOversight 6y ago
    I know that you can install iOS profiles onto the Apple TV, I have done this for 802.1x support, which included a CA root for the 802.1x controller. I would imagine you can use this to push any certificate that you can also push to an iOS/iPadOS/macOS device.
    - fiddlerwoaroof 6y ago
      This is what I was thinking about.

rsync 6y ago

"That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy." This is a very good point and I am dealing with this myself on my home networks. Like any household/family we have some number of dubious/untrusted devices that still need Internet access. By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS. DoH breaks all of this. I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them". Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ... This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...

acdha 6y ago
> By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS. This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective. > Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query. It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.
- rsync 6y ago
  "This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective." If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers. That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...

gsich 6y ago

Right now you can block the common IPs for the DoH servers and be fine.