Hacker News new | past | comments | ask | show | jobs | submit login

Don't put devices on your network if you don't want to give them network access. And don't block technologies and protocols that help people protect themselves just because they also help devices protect themselves from you MITMing their connections. If you want to run a device reverse-engineering lab you have more work to do to break the security of a device.

Also remember that if you can break the security of a device, so could an ISP router. The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile.

How many people are using custom local plaintext DNS as a measure to analyze local devices on their network? How many more people are having their whole network's DNS usage analyzed by their ISP and anyone their ISP sells data to? The defaults are designed to be the right choice for people who don't change the defaults.




"The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile."

Thanks for this - I had not thought of that.

Looks like I'll be keeping my "smart" TV off the network forever then (my old LG used to send a network request whenever I pressed any button on the remote)! And all my Android devices, Windows 10 devices and my Apple TV and MacBook too. (This is only partially sarcasm - I can't really trust anything these days it seems...). The amount of dialling-out they all do is astronomical. The only solution appears to be going full 1980s and not being on the network. The dream is over.

At least my Raspberry Pi can be trusted. Other than the GPU chipset...


This is precisely why many of us use Linux and put up with some of the inconveniences or doing so - it’s more trustworthy. (And it gets more convenient as more people start using it.)


the irony is that almost all of the smart devices use linux....


They sure do, but it’s a Linux instance that the manufacturer has control over rather than the user. (Which is the real problem, more than just what tech is being used.)


> treat the intermediate network between them and the servers they talk to as hostile

Unfortunately they also treat the user as hostile and untrusted. Your phone, browser, OS, or TV treat you as hostile when they send data to the manufacturer and give you no way of assessing yourself or actually controlling this. We have standards and protocols that ensure the data is kept perfectly secure and inscrutable between your device and the manufacturer but absolutely nothing is put in place to give you any control over this. Your choice is binary: use it or not. Every security decision seems to work out better for those companies than for the user.

In this case both DoH and DoT provide the required security for the users but one of them takes a little bit of control away from them.


The problem is that the device (or website) also treats the owner and legitimate user as untrusted and obfuscates the content of the traffic in a way that makes everything completely opaque for them. The device/site only trusts its manufacturer which makes any device that completely obscures its traffic from its owner feel more like a Trojan horse. This is how you end up with questionable telemetry and data leaks for example.

What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.


In what way does this argument not also suggest that the device should use plaintext HTTP so that you can intercept all its other traffic?


What I want is a key to my own house, not an open door. Right now using a lot of software and IoT devices feels like buying a house but the builders keep the only key.


> Don't run devices on your network you don't trust.

This advice is about as practical as "Do not use ISPs and their forwarders that you don't trust.". Which is to say, not much. Let us know about your experience with smart TVs and similar devices, and how much you trust them.


> Don't run devices on your network you don't trust.

Oh, is that all?

How about I trust the devices until a secretary clicks on a (spear)phishing link that runs a zero-day. Then what? The host is compromised so I can no longer trust any end-device monitoring software on it, and now the network traffic is opaque.

And that doesn't even get into things like academia where students and visiting researchers bring devices of unknown providence. If if they're on DMZed networks, they could be spewing garbage onto the Internet and getting my CIDR range blacklisted.


So you're counting on malware's continued use of plaintext DNS as part of your network's security strategy?


If anything hits port 53 on the outgoing gateway, and it's not from our recursive servers, then we know that network element needs to be looked at: either it's mis-configured or malicious.

Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.

* https://en.wikipedia.org/wiki/Domain_generation_algorithm

* https://en.wikipedia.org/wiki/Botnet#Domains

If malware is connecting to hard-coded IPs then there's nothing we can do about that.

So yes: monitoring DNS for suspicious activity is part of our security strategy.


Then your security strategy definitely needs improvements, since malware often uses hardcoded IPs to bypass DNS proxying/forwarding that corporate networks use. Seriously, this argument could be used to say we should be using HTTP instead of HTTPS, but anyone doing security knows if they really need that level of introspection they need to MITM HTTPS traffic with a MITM proxy. If you care that much, you also need to MITM DoH/DoT traffic.


DNS sniffing takes care of a lot of low-hanging fruit.


Given that Cisco has a major product, Umbrella, that is sold as a part of enterprise security strategy I'd say that more than the OP is considering DNS filtering / monitoring as part of a network security strategy.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: