9 ms·

Though there are a couple of technical options to make this work, the thing I realised many years ago is that if you want to use internet technology you need to

by phicoh 9y ago

Though there are a couple of technical options to make this work, the thing I realised many years ago is that if you want to use internet technology you need to be connected to the internet. Anything else is just an endless headache. 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. Just create a new local protocol (or switch back to IPX)

dcow 9y ago
It really feels like you're throwing in the towel. The internet is designed specifically to allow federation between forests of hosts. That's what routers do. Browser vendors need to get their heads out of the fucking cloud and stop coercing people into relying solely on global TLS. I think TLS is wildly misunderstood. The whole global certificate thing only works for global communication. Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships... to make informed decisions about the trust relationships you want to establish. Browsers need to facilitate this not do everything possible to prevent you from owning your trust. If your browser is only able to communicate globally that's not the internet's fault. It's not TLSs fault (TLS is designed to allow clients to choose who they trust). That a failure of your browser to support your diverse use case.
- collinmanderson 9y ago
  > Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships... to make informed decisions about the trust relationships you want to establish. Explain more how this would work.
  - dcow 9y ago
    Part of setting up an account with a web service or iot device provider or whatever should be acquiring their certificate authority. However, instead of having a single bucket OS level root trust store, browsers empower users to whitelist the sites they trust that authority to well have authority over. You trust googles ca for google.com. Or maybe you don't. At the application level, trust should be managed by the application provider and the user. Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. As a user you're either still using a browser or you've at this point switched to their native app or you've got their JS helpers loaded or whatever. Their application logic can manage all the certificate crap so that users are minimally encumbered by it. If you're talking to local network devices their application logic would issue certificates for whatever scope of IPv6 addresses you're using. Maybe your fancy device is running dns, their thing issues certs for your scope's site, etc. You can even do mutual TLS now because their authority can issue installs of their app their own certificates. Browsers should support client certs too. Navigating to foo.com using a scoped IPv6 address? You're prompted to select the identity you wish to use. Your browser remembers your choice for that scope. The CA is only valid for your blessed names, scope aware.
    - collinmanderson 9y ago
      > Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. But that means that other customers can get a trusted certificate for the exact same ip address, right?
- phicoh 9y ago
  If you like tilting at windmills then go ahead. Since forever people have written software that assumes a global internet. However today the situation is much worse. The global internet is a very hostile environment. Everybody who writes software that has to work on the internet has to assume the worst. If there are modes in a piece of software that assume the network can be trusted, then you can be sure that some attacker will try to activate that mode. You cannot assume that the users of a piece of software have any idea how the internet works. If they can solve an immediate problem by disabling security, they will. So, over time just about any piece of software that wants to support secure use on the internet will come with built-in trust anchors that are very hard to change. In browsers this trend is quite visible. But the same trend, though less visible is going on in DNS. E-mail is a bit of a mess. But the basic features are there. Just not a lot of adoption. To sum it up, users don't want to know about internet security. They want their devices to work securely at a random open wifi network. Devices have a hard time figuring out if they are in a trusted environment. So the best way forward is to assume all environments are untrusted and require encryption everywhere.
  - dcow 9y ago
    My issue was with you suggesting people abandon security if they don't want a public internet connection. I think the global TLS system works great when you're in a global context. But now the internet has proliferated and it's infecting people's homes. It turns out people _don't want_ to be in that hostile global context when they're at home. They want a context that is private. They want to isolate their home from the firehouse of global bullshit out there. I think we've passed an inflection point and we're seeing a revival of attention to home networking. Sure for the last 15 years all I connected to my wifi was my laptop and that's pretty useless without the global internet. But now people have IoT things. Door locks, ovens, toilet paper, you name it. Why the hell would anyone want those things phoning home to a remote server all the time? Why does it even need to be publicly routable? Maybe it does need limited connectivity so strong interactive controls allowing you to federate whatgoes in and out are necessary. More than ever the _integrity_ of your home is also the integrity of your network. Your network is an appliance now. It is the lifeblood of your home. People deserve to be able to administrate their personal enclaves as they see fit and do it securely. The best way to prevent someone from remotely unlocking my doors is to eliminate the remote path to the door lock. Did you forget that we've come rather far in securing later 2? People _can_ and _should_ trust their home network. Not wrecklessly, but private networks are not a fairy tale. Finally finally, don't patronize users. The users of today are tomorrow's grandmas. It's not unreasonable to expect we can slowly adapt user expectations and understanding surrounding the security of their software. I'm not saying you don't have a point, but I think it's a disservice to users to treat them all like idiots.
collinmanderson 9y ago
I totally agree. Either have it securely connected to the internet, or not at all. The fact that something is on your LAN is just an implementation detail and shouldn’t be relied upon for security.
- dcow 9y ago
  Is the fact that your physical door locks and keys are only unique to your local region very much an implementation detail? No it's not. It's conceptually the same, but keys and locks are not globally secure. They're only locally secure. Also IPv6: everything gets a globally routable address. Great so why do we need anything else? Well it turns out that in order to support all the different modes of network operation and all the different topologies and use cases, the Internet Protocol needs to support non-global scopes too. Arguing you can't have e.g. link-local security is absurd and rally quite green, from a networking professionals perspective. Oh also IPSEC is part of IPv6 not just an afterthought like it was for IPv4. This makes it even more likely we'll see trusted network scopes sooner rather than never.
  - JumpCrisscross 9y ago
    > It's conceptually the same, but keys and locks are not globally secure. They're only locally secure Criminals in Hong Kong can’t teleport to my door. Local security for locks is fine because the threat is always local.
    - collinmanderson 9y ago
      > Criminals in Hong Kong can’t teleport to my door. They might be able to hijack a different IoT device on the network. The more IoT devices, the greater the attack surface. What if you have guests over and they happen to have a bad virus on their computer or their phone?
    - dcow 9y ago
      That is basically my point. People need to have ways to create local enclaves so it's impossible for packets to ever make their way into your zone. And wonxe you do that, local security is perfectly reasonable and desirable.
deadbunny 9y ago
> 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.

by phicoh 9y ago

dcow 9y ago

It really feels like you're throwing in the towel. The internet is designed specifically to allow federation between forests of hosts. That's what routers do. Browser vendors need to get their heads out of the fucking cloud and stop coercing people into relying solely on global TLS. I think TLS is wildly misunderstood. The whole global certificate thing only works for global communication. Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships... to make informed decisions about the trust relationships you want to establish. Browsers need to facilitate this not do everything possible to prevent you from owning your trust. If your browser is only able to communicate globally that's not the internet's fault. It's not TLSs fault (TLS is designed to allow clients to choose who they trust). That a failure of your browser to support your diverse use case.

collinmanderson 9y ago
> Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships... to make informed decisions about the trust relationships you want to establish. Explain more how this would work.
- dcow 9y ago
  Part of setting up an account with a web service or iot device provider or whatever should be acquiring their certificate authority. However, instead of having a single bucket OS level root trust store, browsers empower users to whitelist the sites they trust that authority to well have authority over. You trust googles ca for google.com. Or maybe you don't. At the application level, trust should be managed by the application provider and the user. Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. As a user you're either still using a browser or you've at this point switched to their native app or you've got their JS helpers loaded or whatever. Their application logic can manage all the certificate crap so that users are minimally encumbered by it. If you're talking to local network devices their application logic would issue certificates for whatever scope of IPv6 addresses you're using. Maybe your fancy device is running dns, their thing issues certs for your scope's site, etc. You can even do mutual TLS now because their authority can issue installs of their app their own certificates. Browsers should support client certs too. Navigating to foo.com using a scoped IPv6 address? You're prompted to select the identity you wish to use. Your browser remembers your choice for that scope. The CA is only valid for your blessed names, scope aware.
  - collinmanderson 9y ago
    > Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. But that means that other customers can get a trusted certificate for the exact same ip address, right?
phicoh 9y ago
If you like tilting at windmills then go ahead. Since forever people have written software that assumes a global internet. However today the situation is much worse. The global internet is a very hostile environment. Everybody who writes software that has to work on the internet has to assume the worst. If there are modes in a piece of software that assume the network can be trusted, then you can be sure that some attacker will try to activate that mode. You cannot assume that the users of a piece of software have any idea how the internet works. If they can solve an immediate problem by disabling security, they will. So, over time just about any piece of software that wants to support secure use on the internet will come with built-in trust anchors that are very hard to change. In browsers this trend is quite visible. But the same trend, though less visible is going on in DNS. E-mail is a bit of a mess. But the basic features are there. Just not a lot of adoption. To sum it up, users don't want to know about internet security. They want their devices to work securely at a random open wifi network. Devices have a hard time figuring out if they are in a trusted environment. So the best way forward is to assume all environments are untrusted and require encryption everywhere.
- dcow 9y ago
  My issue was with you suggesting people abandon security if they don't want a public internet connection. I think the global TLS system works great when you're in a global context. But now the internet has proliferated and it's infecting people's homes. It turns out people _don't want_ to be in that hostile global context when they're at home. They want a context that is private. They want to isolate their home from the firehouse of global bullshit out there. I think we've passed an inflection point and we're seeing a revival of attention to home networking. Sure for the last 15 years all I connected to my wifi was my laptop and that's pretty useless without the global internet. But now people have IoT things. Door locks, ovens, toilet paper, you name it. Why the hell would anyone want those things phoning home to a remote server all the time? Why does it even need to be publicly routable? Maybe it does need limited connectivity so strong interactive controls allowing you to federate whatgoes in and out are necessary. More than ever the _integrity_ of your home is also the integrity of your network. Your network is an appliance now. It is the lifeblood of your home. People deserve to be able to administrate their personal enclaves as they see fit and do it securely. The best way to prevent someone from remotely unlocking my doors is to eliminate the remote path to the door lock. Did you forget that we've come rather far in securing later 2? People _can_ and _should_ trust their home network. Not wrecklessly, but private networks are not a fairy tale. Finally finally, don't patronize users. The users of today are tomorrow's grandmas. It's not unreasonable to expect we can slowly adapt user expectations and understanding surrounding the security of their software. I'm not saying you don't have a point, but I think it's a disservice to users to treat them all like idiots.

collinmanderson 9y ago

I totally agree. Either have it securely connected to the internet, or not at all. The fact that something is on your LAN is just an implementation detail and shouldn’t be relied upon for security.

dcow 9y ago
Is the fact that your physical door locks and keys are only unique to your local region very much an implementation detail? No it's not. It's conceptually the same, but keys and locks are not globally secure. They're only locally secure. Also IPv6: everything gets a globally routable address. Great so why do we need anything else? Well it turns out that in order to support all the different modes of network operation and all the different topologies and use cases, the Internet Protocol needs to support non-global scopes too. Arguing you can't have e.g. link-local security is absurd and rally quite green, from a networking professionals perspective. Oh also IPSEC is part of IPv6 not just an afterthought like it was for IPv4. This makes it even more likely we'll see trusted network scopes sooner rather than never.
- JumpCrisscross 9y ago
  > It's conceptually the same, but keys and locks are not globally secure. They're only locally secure Criminals in Hong Kong can’t teleport to my door. Local security for locks is fine because the threat is always local.
  - collinmanderson 9y ago
    > Criminals in Hong Kong can’t teleport to my door. They might be able to hijack a different IoT device on the network. The more IoT devices, the greater the attack surface. What if you have guests over and they happen to have a bad virus on their computer or their phone?
  - dcow 9y ago
    That is basically my point. People need to have ways to create local enclaves so it's impossible for packets to ever make their way into your zone. And wonxe you do that, local security is perfectly reasonable and desirable.

deadbunny 9y ago

> 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.