3 ms·

DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely

DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service. Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution.

acdha 6y ago
> DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service. This problem goes back a lot further than that — even prior to having CDNs in common usage you had plenty of different clients sharing IP space at hosting companies and the really malicious stuff just using compromised computers. It's also not fully covering the threat model here: for example, if you are concerned about privacy there are whole classes of device which you simply cannot allow because blocking one feature simply means that the vendor will run everything through the same endpoints required for the device to work. > Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution. Perfect is the enemy of the good but you have to also think about the asymmetry here. Trying to hijack DNS is only useful when you control the network but neither the client or server. Trying to stop malware by politely asking them to play nicely is a losing game and the IoT devices many people worry about have entire teams devoted to bypassing you as well (e.g. if any significant number of people tried to block a TV from reporting your viewing activity, the endgame is that viewing history and software updates would both go through samsung.com, not that they'll give up millions of dollars in revenue). That leaves you with cases where you do control the client and thus have less invasive alternatives such as installing an ad blocker or using a different browser.
- yardstick 6y ago
  > Trying to hijack DNS is only useful when you control the network but neither the client or server. This is a very common scenario in retail and SME businesses where you can’t control the on site hardware, eg fuel pumps or CCTV or cash registers or footfall counters or vending machines or whatever, and you can’t control what IPs they talk to. But you still have an obligation to minimise their network access. Unfortunately they use services hosted on the cloud in dynamic IPs, so you either need to MITM TLS (can’t, no way to change the trusted CA list in these devices), or you need to MITM DNS / SNI. It’s not perfect security, and ideally the business simply wouldn’t buy such poorly securable products, but technology decisions are very rarely vetoed by security considerations, especially when cost is a factor. This is an example of the appropriate level of security for the business risk appetite. Telling the business to buy products that can be locked down perfectly is normally a non-starter.
  - acdha 6y ago
    Again, though, this is only forcing them to understand how their network has always worked rather than changing the situation. If the vendor chooses to bypass the local DNS, you won’t know about it no matter whether DoH exists.
jiggawatts 6y ago
The biggest mistake I see in public cloud fundamental architecture is that it uses IPv4 end-to-end, instead of just as a compatibility add-on to native IPv6 networking. Literally all of the security issues caused by the public cloud network architecture instantly evaporate with IPv6, as well as much of the configuration complexity. No more private networks with non-routable addresses! Instead you get a public-routable IPv6 block. No more split-routing issues. No more "gateways" or "peerings" or "service endpoints". No more Private DNS Zones that may or may not work across virtual network boundaries. No more copying DNS records into on-premises Active Directory DNS. Every VM can get a globally unique address. So can every service, of any type! No more conflicts. No need to carefully "carve up" and "allocate" addresses. Just let the system take care of it... No more sharing IPs with other customers. Every resource, no matter how tiny can get a dedicated address. Got an S3 bucket with 1KB of files in it? You get your own IP! Every VM or service sees the real client IP, not the reverse proxy IP. No need for SNI, ESNI, or even host headers since every web server can have a dedicated IP. No reverse proxy means that load-balancers can simply set up the TCP handshake and then everything runs directly at wire speed. There is never a need to "scale" a load balancer. The IPv6 addresses are consistent, globally. The IP address of the cloud VM is the address you register on-premises to SSH to it. No NAT magic involved at any point. Adding a private link (e.g.: ExpressRoute) doesn't change your address ranges. They're the same, only the routes change. This would be a completely transparent change to your firewall rules of whitelisting setup. Etc... PS: The current Azure IPv6 architecture reproduces all of the limitations of their IPv4 architecture. They even NAT the addresses! You literally cannot have any of the above, ever, with Azure using IPv6 as it is now. They even limit the number of IPv6 addresses to further restrict you. If they do fix it, you'll have to redo your entire IPv6 setup. It's insanity.
- Reelin 6y ago
  Thanks for spelling it out like that - I think I might see the bigger picture here now. DoH (which incorporates DNSSEC under the hood) to protect the name lookup. IPv6 to provide unique addresses for every single service you connect to. The complete removal of SNI (as a security threat) and ESNI (as unnecessary complexity). Pi-hole type filtering is then implemented based on IP blocks instead of DNS queries. Any unrecognizable IP address is default denied. Tracking, analytics, and ads could still be proxied by a remote host, but that can already happen anyway. Of course, your ISP (or VPN, or anyone else along the network path) could employ the exact same approach to determine the services you connect to. Which leads me right back to DoH being largely pointless and Tor or similar being a hard requirement for actual privacy. Unless I'm missing something?

acdha 6y ago

> DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service. This problem goes back a lot further than that — even prior to having CDNs in common usage you had plenty of different clients sharing IP space at hosting companies and the really malicious stuff just using compromised computers. It's also not fully covering the threat model here: for example, if you are concerned about privacy there are whole classes of device which you simply cannot allow because blocking one feature simply means that the vendor will run everything through the same endpoints required for the device to work. > Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution. Perfect is the enemy of the good but you have to also think about the asymmetry here. Trying to hijack DNS is only useful when you control the network but neither the client or server. Trying to stop malware by politely asking them to play nicely is a losing game and the IoT devices many people worry about have entire teams devoted to bypassing you as well (e.g. if any significant number of people tried to block a TV from reporting your viewing activity, the endgame is that viewing history and software updates would both go through samsung.com, not that they'll give up millions of dollars in revenue). That leaves you with cases where you do control the client and thus have less invasive alternatives such as installing an ad blocker or using a different browser.

yardstick 6y ago
> Trying to hijack DNS is only useful when you control the network but neither the client or server. This is a very common scenario in retail and SME businesses where you can’t control the on site hardware, eg fuel pumps or CCTV or cash registers or footfall counters or vending machines or whatever, and you can’t control what IPs they talk to. But you still have an obligation to minimise their network access. Unfortunately they use services hosted on the cloud in dynamic IPs, so you either need to MITM TLS (can’t, no way to change the trusted CA list in these devices), or you need to MITM DNS / SNI. It’s not perfect security, and ideally the business simply wouldn’t buy such poorly securable products, but technology decisions are very rarely vetoed by security considerations, especially when cost is a factor. This is an example of the appropriate level of security for the business risk appetite. Telling the business to buy products that can be locked down perfectly is normally a non-starter.
- acdha 6y ago
  Again, though, this is only forcing them to understand how their network has always worked rather than changing the situation. If the vendor chooses to bypass the local DNS, you won’t know about it no matter whether DoH exists.

jiggawatts 6y ago

The biggest mistake I see in public cloud fundamental architecture is that it uses IPv4 end-to-end, instead of just as a compatibility add-on to native IPv6 networking. Literally all of the security issues caused by the public cloud network architecture instantly evaporate with IPv6, as well as much of the configuration complexity. No more private networks with non-routable addresses! Instead you get a public-routable IPv6 block. No more split-routing issues. No more "gateways" or "peerings" or "service endpoints". No more Private DNS Zones that may or may not work across virtual network boundaries. No more copying DNS records into on-premises Active Directory DNS. Every VM can get a globally unique address. So can every service, of any type! No more conflicts. No need to carefully "carve up" and "allocate" addresses. Just let the system take care of it... No more sharing IPs with other customers. Every resource, no matter how tiny can get a dedicated address. Got an S3 bucket with 1KB of files in it? You get your own IP! Every VM or service sees the real client IP, not the reverse proxy IP. No need for SNI, ESNI, or even host headers since every web server can have a dedicated IP. No reverse proxy means that load-balancers can simply set up the TCP handshake and then everything runs directly at wire speed. There is never a need to "scale" a load balancer. The IPv6 addresses are consistent, globally. The IP address of the cloud VM is the address you register on-premises to SSH to it. No NAT magic involved at any point. Adding a private link (e.g.: ExpressRoute) doesn't change your address ranges. They're the same, only the routes change. This would be a completely transparent change to your firewall rules of whitelisting setup. Etc... PS: The current Azure IPv6 architecture reproduces all of the limitations of their IPv4 architecture. They even NAT the addresses! You literally cannot have any of the above, ever, with Azure using IPv6 as it is now. They even limit the number of IPv6 addresses to further restrict you. If they do fix it, you'll have to redo your entire IPv6 setup. It's insanity.

Reelin 6y ago
Thanks for spelling it out like that - I think I might see the bigger picture here now. DoH (which incorporates DNSSEC under the hood) to protect the name lookup. IPv6 to provide unique addresses for every single service you connect to. The complete removal of SNI (as a security threat) and ESNI (as unnecessary complexity). Pi-hole type filtering is then implemented based on IP blocks instead of DNS queries. Any unrecognizable IP address is default denied. Tracking, analytics, and ads could still be proxied by a remote host, but that can already happen anyway. Of course, your ISP (or VPN, or anyone else along the network path) could employ the exact same approach to determine the services you connect to. Which leads me right back to DoH being largely pointless and Tor or similar being a hard requirement for actual privacy. Unless I'm missing something?