5 ms·

APs are going to be the great new app platform, but also a very clear security problem. They have now grown so much spare capacity they can host a lot of extra

APs are going to be the great new app platform, but also a very clear security problem. They have now grown so much spare capacity they can host a lot of extra interesting services. The noises from China suggest some people in companies like Xiaomi worked this out a while ago. Fundamentally we need to move to a home networking model that involves isolating all clients completely (especially cameras and smart TVs), and using AP hosted services to mediate interaction between them and the Internet at large. This will involve needing to trust the AP, but will have the advantage of being able to deploy slightly less trustworthy devices at the very edge.

toomuchtodo 2y ago
Can you ensure this level of assurance without requiring an independent review of router firmware? If it is managing security boundaries, how do you know if you trust it? And how do you ensure that trust is maintained over device lifetime as firmware updates are shipped? Hard problem to solve by building and maintaining long run "people, process, tech" systems.
- fidotron 2y ago
  That's kind of my point - it's inevitable that we will end up having to take the security of the AP enormously more seriously than we have. The AP will end up needing cellphone style updates and chain of trust integrity checks for the firmware. The reason this is inevitable is the alternative hasn't worked. Cloud based IoT has been a disaster in both the atrocious edge device security and cloud service bait and switch burning customer confidence in the whole concept. Most people are not going to deploy dedicated servers in their house, but an AP absolutely. The HomeAssistant and Frigate ecosystems demonstrate the demand for functionality is there, but they are very much enthusiast type tools.
  - toomuchtodo 2y ago
    Strongly agree, I just don't see evidence there is any appetite for spending the resources needed to accomplish this. I would very much like there to be, but, you know. No one likes to spend until the place is already on fire. If this is the fire ("never let a crisis go to waste"), we should try to spend what's required to do what is needed. (a component of my work is software supply chain security)
    - fidotron 2y ago
      > Strongly agree, I just don't see evidence there is any appetite for spending the resources needed to accomplish this. Yeah, that is the problem, and I gave up on waiting for it, so kicked off an exploration of the problem space https://github.com/atomirex/umbrella https://github.com/atomirex/umbrella (Hitting video handling first because it is one of the major headaches). I come from the intersection of embedded/mobile/games and saw what a dumpster fire that was, and am under no illusions this will be solved either fast or by any existing group.
      - deleted 2y ago
        [deleted]
kbolino 2y ago
I like the idea of isolating every client, or certain clients at least, but I don't see why this needs special apps or services. Just treat these clients as existing on their own VLAN segments and either get rid of the GTK (forcing broadcast/multicast to go through the AP) or generate a different one for each such segment (separating the broadcast domains).
- fidotron 2y ago
  Clients shouldn't connect to the Internet by default, and when they do it should be domain/IP whitelisted only. For example, an IoT lightswitch in your home should only talk to what looks like an MQTT broker in the AP. It doesn't need to have any concept what that topic it publishes to does. Similarly, the receiving light doesn't need to know what caused it. This way those devices literally never need any external network access at all. I started working on this idea by playing with OpenWrt hosted video relays, and learned that it works, and am now extending it: https://github.com/atomirex/umbrella https://github.com/atomirex/umbrella Right now I am on HN procrastinating when I should be producing a video of ingesting from a TP Link security camera (really) into a webrtc SFU on the AP, sending it to another SFU, and watching the result.
  - kbolino 2y ago
    I like this vision, but I'm not optimistic about it coming to fruition. IoT vendors want their devices phoning home over the Internet, it gives them traceability and platform lock-in.
  - simoncion 2y ago
    > ...when they do it should be domain/IP whitelisted only. In practice, this will work very poorly. Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... which doesn't really stop anything. I work at a BigCo that tries to do what you're proposing and it works so, so badly. Thankfully, we can turn off the "security" software that does this on our workstations. Unfortunately, cannot do the same for our software that runs on datacenter-hosted hardware that IT manages. > Clients shouldn't connect to the Internet by default... I have a couple of VLANs on my LAN that don't provide Internet access just for this reason.
jalk 2y ago
> fundamentally we need to move to a home networking model that involves isolating all clients completely (especially cameras and smart TVs) That is currently solved by using separate SSID's on individual VLANs (i.e. main, guest, iot) and firewall rules "mediate" the connection between the VLANs. I'm handrolling this with OpenWRT on APs and main router (NanoPI R5C) with ISP cable router is in bridge mode. Can't say it was easy to set up though

toomuchtodo 2y ago

Can you ensure this level of assurance without requiring an independent review of router firmware? If it is managing security boundaries, how do you know if you trust it? And how do you ensure that trust is maintained over device lifetime as firmware updates are shipped? Hard problem to solve by building and maintaining long run "people, process, tech" systems.

fidotron 2y ago
That's kind of my point - it's inevitable that we will end up having to take the security of the AP enormously more seriously than we have. The AP will end up needing cellphone style updates and chain of trust integrity checks for the firmware. The reason this is inevitable is the alternative hasn't worked. Cloud based IoT has been a disaster in both the atrocious edge device security and cloud service bait and switch burning customer confidence in the whole concept. Most people are not going to deploy dedicated servers in their house, but an AP absolutely. The HomeAssistant and Frigate ecosystems demonstrate the demand for functionality is there, but they are very much enthusiast type tools.
- toomuchtodo 2y ago
  Strongly agree, I just don't see evidence there is any appetite for spending the resources needed to accomplish this. I would very much like there to be, but, you know. No one likes to spend until the place is already on fire. If this is the fire ("never let a crisis go to waste"), we should try to spend what's required to do what is needed. (a component of my work is software supply chain security)
  - fidotron 2y ago
    > Strongly agree, I just don't see evidence there is any appetite for spending the resources needed to accomplish this. Yeah, that is the problem, and I gave up on waiting for it, so kicked off an exploration of the problem space https://github.com/atomirex/umbrella https://github.com/atomirex/umbrella (Hitting video handling first because it is one of the major headaches). I come from the intersection of embedded/mobile/games and saw what a dumpster fire that was, and am under no illusions this will be solved either fast or by any existing group.
    - deleted 2y ago
      [deleted]

kbolino 2y ago

I like the idea of isolating every client, or certain clients at least, but I don't see why this needs special apps or services. Just treat these clients as existing on their own VLAN segments and either get rid of the GTK (forcing broadcast/multicast to go through the AP) or generate a different one for each such segment (separating the broadcast domains).

fidotron 2y ago
Clients shouldn't connect to the Internet by default, and when they do it should be domain/IP whitelisted only. For example, an IoT lightswitch in your home should only talk to what looks like an MQTT broker in the AP. It doesn't need to have any concept what that topic it publishes to does. Similarly, the receiving light doesn't need to know what caused it. This way those devices literally never need any external network access at all. I started working on this idea by playing with OpenWrt hosted video relays, and learned that it works, and am now extending it: https://github.com/atomirex/umbrella https://github.com/atomirex/umbrella Right now I am on HN procrastinating when I should be producing a video of ingesting from a TP Link security camera (really) into a webrtc SFU on the AP, sending it to another SFU, and watching the result.
- kbolino 2y ago
  I like this vision, but I'm not optimistic about it coming to fruition. IoT vendors want their devices phoning home over the Internet, it gives them traceability and platform lock-in.
- simoncion 2y ago
  > ...when they do it should be domain/IP whitelisted only. In practice, this will work very poorly. Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... which doesn't really stop anything. I work at a BigCo that tries to do what you're proposing and it works so, so badly. Thankfully, we can turn off the "security" software that does this on our workstations. Unfortunately, cannot do the same for our software that runs on datacenter-hosted hardware that IT manages. > Clients shouldn't connect to the Internet by default... I have a couple of VLANs on my LAN that don't provide Internet access just for this reason.

jalk 2y ago

> fundamentally we need to move to a home networking model that involves isolating all clients completely (especially cameras and smart TVs) That is currently solved by using separate SSID's on individual VLANs (i.e. main, guest, iot) and firewall rules "mediate" the connection between the VLANs. I'm handrolling this with OpenWRT on APs and main router (NanoPI R5C) with ISP cable router is in bridge mode. Can't say it was easy to set up though