4 ms·

> If you are sure that you don't want your IoT devices to be reachable from the internet, don't use the internet protocol to talk to them, don't use DNS, web br

> If you are sure that you don't want your IoT devices to be reachable from the internet, don't use the internet protocol to talk to them, don't use DNS, web browsers, etc. What utter nonsense. TCP/IP works fine on a local network DNS works fine on a local network HTTP(S) works fine on a local network Web Browsers work fine on a local network After all the internet is nothing more than a collection of connected networks. If I have no need for anything within my local network (or subset of that network) to be routable from the internet then I put a firewall in the way, it doesn't mean I don't use the same tools and protocols.

phicoh 9y ago
Actually, TCP/IP on a local network will make mobile devices think they are on a captive portal. DNSSEC will prevent you from serving local answers for signed zones. The DNS root zone is signed. So the IETF at the moment has a hard time figuring out which zones need to stay not signed to allow these kinds of local answers. HTTP is not secure, so that is going the way of telnet. HTTPS is what we are discussing here. Without a valid cert, don't expect browsers to support you much longer. Yes, you can create your own little internet island. But don't complain if any software fails to work in that environment.
- deadbunny 9y ago
  > TCP/IP on a local network will make mobile devices think they are on a captive portal. No, that's the phone doing a HTTP call to a server on the internet to try and work out if it's a captive portal, all TCP/IP still functions perfectly fine within an internal network with no WAN access. > DNSSEC will prevent you from serving local answers for signed zones. The DNS root zone is signed. So the IETF at the moment has a hard time figuring out which zones need to stay not signed to allow these kinds of local answers. The devices are on a local network, they're not making requests to things outside the network. Even if you do need outside access for resolution you can still happily use a DNS forwarder with your local DNS served up locally with any outside DNS (including DNSSEC) queries being forwarded where they need. > HTTP is not secure, so that is going the way of telnet. That's neither here nor there, it still works fine in the context of a local network. > HTTPS is what we are discussing here. Without a valid cert, don't expect browsers to support you much longer. A cert is as valid as my cert store thinks it is, again, still works on an internal network. > Yes, you can create your own little internet island. But don't complain if any software fails to work in that environment. By "own internet island" you mean a local network? Sure it's more advanced than your nan's local network but it's still a local network in which the IP part of TCP/IP still works absolutely fine. Maybe you come from the land where your mongo instance needs a public IP, or that your lightbulbs can be used to pivot onto your home network. I don't. This is basic network design. Maybe the shitty software/hardware you're running shouldn't assume it will always be connected to the internet directly.
collinmanderson 9y ago
Sure, as a power user, it can all be done. You can also manually trust a self-signed cert. I wouldn't recommend it for the masses though.
- deadbunny 9y ago
  I was rebutting the blatantly wrong "don't expect IP to work". Yes it's not your mum's network, but then I never said it was.
  - kuschku 9y ago
    But that's the whole point. The goal is that you can build a device that your grandma can put at home, which never connects to a remote server, which she can connect to from her browser, which just works, never shows an annoying HTTPS warning, never requires enabling custom CAs, and provides all functionality of the browser, without being marked as "not secure". That is the goal: All the functionality of e.g. a Nest device, without ever sending a single packet outside of your LAN. (Disclaimer: For my own IoT projects, of course I use a special domain with DNS delegation and Let's Encrypt certificates, and HSTS preloaded)
    - collinmanderson 9y ago
      > never connects to a remote server, which she can connect to from her browser, which just works, never shows an annoying HTTPS warning, never requires enabling custom CAs, and provides all functionality of the browser, without being marked as "not secure". Right, do you have a proposal for how to accomplish this? If you don't want to require an internet connection, I think trusting a self-signed cert is the best way to go, otherwise owning a domain name + letsencrypt is good if you're ok connecting to the internet.
      - kuschku 9y ago
        I don't think you'll be able to explain your grandma how to trust a self signed certificate. The alternative would be HTTP, but that's "not secure" anymore. There are situations where trust on first use or out of bands verification are the only option. This is one of them.

phicoh 9y ago

Actually, TCP/IP on a local network will make mobile devices think they are on a captive portal. DNSSEC will prevent you from serving local answers for signed zones. The DNS root zone is signed. So the IETF at the moment has a hard time figuring out which zones need to stay not signed to allow these kinds of local answers. HTTP is not secure, so that is going the way of telnet. HTTPS is what we are discussing here. Without a valid cert, don't expect browsers to support you much longer. Yes, you can create your own little internet island. But don't complain if any software fails to work in that environment.

deadbunny 9y ago
> TCP/IP on a local network will make mobile devices think they are on a captive portal. No, that's the phone doing a HTTP call to a server on the internet to try and work out if it's a captive portal, all TCP/IP still functions perfectly fine within an internal network with no WAN access. > DNSSEC will prevent you from serving local answers for signed zones. The DNS root zone is signed. So the IETF at the moment has a hard time figuring out which zones need to stay not signed to allow these kinds of local answers. The devices are on a local network, they're not making requests to things outside the network. Even if you do need outside access for resolution you can still happily use a DNS forwarder with your local DNS served up locally with any outside DNS (including DNSSEC) queries being forwarded where they need. > HTTP is not secure, so that is going the way of telnet. That's neither here nor there, it still works fine in the context of a local network. > HTTPS is what we are discussing here. Without a valid cert, don't expect browsers to support you much longer. A cert is as valid as my cert store thinks it is, again, still works on an internal network. > Yes, you can create your own little internet island. But don't complain if any software fails to work in that environment. By "own internet island" you mean a local network? Sure it's more advanced than your nan's local network but it's still a local network in which the IP part of TCP/IP still works absolutely fine. Maybe you come from the land where your mongo instance needs a public IP, or that your lightbulbs can be used to pivot onto your home network. I don't. This is basic network design. Maybe the shitty software/hardware you're running shouldn't assume it will always be connected to the internet directly.

collinmanderson 9y ago

Sure, as a power user, it can all be done. You can also manually trust a self-signed cert. I wouldn't recommend it for the masses though.

deadbunny 9y ago
I was rebutting the blatantly wrong "don't expect IP to work". Yes it's not your mum's network, but then I never said it was.
- kuschku 9y ago
  But that's the whole point. The goal is that you can build a device that your grandma can put at home, which never connects to a remote server, which she can connect to from her browser, which just works, never shows an annoying HTTPS warning, never requires enabling custom CAs, and provides all functionality of the browser, without being marked as "not secure". That is the goal: All the functionality of e.g. a Nest device, without ever sending a single packet outside of your LAN. (Disclaimer: For my own IoT projects, of course I use a special domain with DNS delegation and Let's Encrypt certificates, and HSTS preloaded)
  - collinmanderson 9y ago
    > never connects to a remote server, which she can connect to from her browser, which just works, never shows an annoying HTTPS warning, never requires enabling custom CAs, and provides all functionality of the browser, without being marked as "not secure". Right, do you have a proposal for how to accomplish this? If you don't want to require an internet connection, I think trusting a self-signed cert is the best way to go, otherwise owning a domain name + letsencrypt is good if you're ok connecting to the internet.
    - kuschku 9y ago
      I don't think you'll be able to explain your grandma how to trust a self signed certificate. The alternative would be HTTP, but that's "not secure" anymore. There are situations where trust on first use or out of bands verification are the only option. This is one of them.