5 ms·

Most b2b gear will play well with a proxy server, and that will allow you to explicitly mitm everything going to the internet. Just don't allow anything else ou

Most b2b gear will play well with a proxy server, and that will allow you to explicitly mitm everything going to the internet. Just don't allow anything else out. One annoying problem is certificate pinning, if you have deices that join your network and others, but it's doable. The real problem is devices sold to consumers that don't allow you to install custom certs or allow you to configure a proxy. There should probably be a law that says every network device should have a means for the owner to decrypt the traffic on the fly.

candiddevmike 5y ago
Maybe with some locally installed b2b software, but any kind of hardware device or appliance has trusted root CAs. Unless you have access to one of those, nothing will trust your MitM setup (at least, I couldn't get Nest equipment to connect via a MitM proxy). Maybe there could be some kind standard DHCP option for a trusted root CA on the network. For user controlled devices (i.e. phones), they wouldn't trust it, but any kind of vendor managed device would. Probably too naive of a solution.
- NavinF 5y ago
  That totally defeats the purpose of TLS. On most home networks, any device can act as a DHCP server. Indeed, a lot of those “limit internet time for kids” devices depend on ARP and/or DHCP spoofing to work. I’m glad the security model of the last couple of decades (trust every device on the LAN) is slowly dying. Oh and adding a nerdy feature to home routers is never gonna happen. Consider how long it took for IPv6 to be enabled by default.
- wildmanx 5y ago
  A problem is that the easier you make it to sneak in other trusted root CAs, the more you open attack surfaces which malicious parties can exploit. As a device manufacturer that uses certificate pinning, do you really want to trust whatever cheap crap router people have at home to provide a trusted root CA? Let's say that one gets hacked (which happens too often..), you are now also wide open. Sure, it's the owners responsibility, and with certificate pinning that's not configurable, you are depriving responsible owners of the possibility to decrypt their own traffic, but we at least need to acknowledge that there is a balance to strike here, and it's not obvious what the perfect solution would be. Maybe an opt-out of certificate pinning that is so "hard" to reach that it's really only for power users that know what they are doing. (And with "hard" I mean more than some window popping up that says "Are you sure you want to do this? You'll void all warranty blah blah" -- people have already been conditioned to just click away certificate warnings in their browser; the same people would just click anything to just go on with their lives..)
  - EvanAnderson 5y ago
    A physical switch on the device would be a good solution. Physical access is mostly "game over" anyway.
    - wildmanx 5y ago
      It needs to be something that requires certain skill. Maybe a dip switch inside the enclosure. Average Joe won't dare and it's too much work anyway. At least if you just try random things to get your IoT device to work if something is off. I'd love to have that.
      - dec0dedab0de 5y ago
        It could just be a text file that you have to modify with vi over ssh. Even if the SSH server is only available if configured through the scary pop up in the gui, maybe even require a public key be uploaded for authentication. Not too difficult, yet technical enough that no one is going to do it without thinking.
        EvanAnderson 5y ago
        The point of a physical switch would be to restrict access to someone with physical access-- ideally the owner.
        wildmanx 5y ago
        Also guarantees that you may need to break some seal that then can be proof for tampering, warranty-wise. (Which otoh some users may not like.)
  - userbinator 5y ago
    There is no "balance", this is purely a question of ownership. If I can't inspect or modify the traffic, it's not mine, I'm just "renting" perpetually.
- dec0dedab0de 5y ago
  Now for the last 7 years I've been more on the dev side of devops, but I can't remember seeing any network appliances being sold for "enterprise" that didn't have an option to enter a proxy for updates, or cloud services, or whatever it needed to phone home for. This could also be that for the last 15 years I've been working for very large non-tech companies that just wouldn't budge on giving a random network appliance direct access to the internet. So the vendors either added the feature for us, or those features didn't work, and maybe we didn't buy it at all. I just did some quick searches and found proxy settings for F5, juniper, cisco, infoblox, and tufin appliances. Now if the problem is that they have an option to configure a proxy, but don't trust your internal cert for the proxy itself, then the answer is to use a publicly signed cert on your internal proxy server. Even if it's just a let's encrypt one. It does feel dirty using public namespace for something that is only ever internal, but it works fine.
- technofiend 5y ago
  Decrypting traffic arguably allows you to rewrite traffic as part of the proxy process. So (for example) Samsung's advertising by using DNS over HTTPS would be defeated. As nice as it would be I don't really see IOT manufacturers offering up a niche feature that would potentially lessen revenue. Outliers like HN readers aside consumers haven't really revolted over progressively more invasive monitoring via their IOT devices.

candiddevmike 5y ago

Maybe with some locally installed b2b software, but any kind of hardware device or appliance has trusted root CAs. Unless you have access to one of those, nothing will trust your MitM setup (at least, I couldn't get Nest equipment to connect via a MitM proxy). Maybe there could be some kind standard DHCP option for a trusted root CA on the network. For user controlled devices (i.e. phones), they wouldn't trust it, but any kind of vendor managed device would. Probably too naive of a solution.

NavinF 5y ago
That totally defeats the purpose of TLS. On most home networks, any device can act as a DHCP server. Indeed, a lot of those “limit internet time for kids” devices depend on ARP and/or DHCP spoofing to work. I’m glad the security model of the last couple of decades (trust every device on the LAN) is slowly dying. Oh and adding a nerdy feature to home routers is never gonna happen. Consider how long it took for IPv6 to be enabled by default.
wildmanx 5y ago
A problem is that the easier you make it to sneak in other trusted root CAs, the more you open attack surfaces which malicious parties can exploit. As a device manufacturer that uses certificate pinning, do you really want to trust whatever cheap crap router people have at home to provide a trusted root CA? Let's say that one gets hacked (which happens too often..), you are now also wide open. Sure, it's the owners responsibility, and with certificate pinning that's not configurable, you are depriving responsible owners of the possibility to decrypt their own traffic, but we at least need to acknowledge that there is a balance to strike here, and it's not obvious what the perfect solution would be. Maybe an opt-out of certificate pinning that is so "hard" to reach that it's really only for power users that know what they are doing. (And with "hard" I mean more than some window popping up that says "Are you sure you want to do this? You'll void all warranty blah blah" -- people have already been conditioned to just click away certificate warnings in their browser; the same people would just click anything to just go on with their lives..)
- EvanAnderson 5y ago
  A physical switch on the device would be a good solution. Physical access is mostly "game over" anyway.
  - wildmanx 5y ago
    It needs to be something that requires certain skill. Maybe a dip switch inside the enclosure. Average Joe won't dare and it's too much work anyway. At least if you just try random things to get your IoT device to work if something is off. I'd love to have that.
    - dec0dedab0de 5y ago
      It could just be a text file that you have to modify with vi over ssh. Even if the SSH server is only available if configured through the scary pop up in the gui, maybe even require a public key be uploaded for authentication. Not too difficult, yet technical enough that no one is going to do it without thinking.
      - EvanAnderson 5y ago
        The point of a physical switch would be to restrict access to someone with physical access-- ideally the owner.
        wildmanx 5y ago
        Also guarantees that you may need to break some seal that then can be proof for tampering, warranty-wise. (Which otoh some users may not like.)
- userbinator 5y ago
  There is no "balance", this is purely a question of ownership. If I can't inspect or modify the traffic, it's not mine, I'm just "renting" perpetually.
dec0dedab0de 5y ago
Now for the last 7 years I've been more on the dev side of devops, but I can't remember seeing any network appliances being sold for "enterprise" that didn't have an option to enter a proxy for updates, or cloud services, or whatever it needed to phone home for. This could also be that for the last 15 years I've been working for very large non-tech companies that just wouldn't budge on giving a random network appliance direct access to the internet. So the vendors either added the feature for us, or those features didn't work, and maybe we didn't buy it at all. I just did some quick searches and found proxy settings for F5, juniper, cisco, infoblox, and tufin appliances. Now if the problem is that they have an option to configure a proxy, but don't trust your internal cert for the proxy itself, then the answer is to use a publicly signed cert on your internal proxy server. Even if it's just a let's encrypt one. It does feel dirty using public namespace for something that is only ever internal, but it works fine.
technofiend 5y ago
Decrypting traffic arguably allows you to rewrite traffic as part of the proxy process. So (for example) Samsung's advertising by using DNS over HTTPS would be defeated. As nice as it would be I don't really see IOT manufacturers offering up a niche feature that would potentially lessen revenue. Outliers like HN readers aside consumers haven't really revolted over progressively more invasive monitoring via their IOT devices.