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.
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.
With all due respect, over the past fifteen years of trying to secure corporate networks, we've learned the hard way that this simply isn't a realistic goal. Having a hard outer shell and a squishy center just leaves the entire network vulnerable, because it's simply not possible to isolate yourself from the badness of the outside world. As soon as you let anyone in who's ever spoken to the hostile outside world, they bring the hostile outside world in with them.
We can't keep pretending that we can keep home networks isolated from the rest of the world when many of the computers in those networks move freely between the global Internet and the private home intranet. All connected devices are part of the global Internet whether or not we want them to be, and whether or not their connections are persistent.
Most people have no clue about computer security and don't want to get one. Tomorrow's grandmas will know as little about how their computers are attacked as today's grandmas.
And they don't want to know. They want technology that is safe to use.
We know from experience that a network where devices trust each other is a disaster waiting to happen. So let's kill that model. All devices have to survive in the open internet. Because if they don't, somebody will figure a way to attack them.
I LOVE the idea of NAT-less global internet. It's why I love IPv6. At that level anything that wants to participate should be secure and "go Chrome" for leading the charge. I even think firewalls for global IPv6 are stupid. If you're global you're global no amount of silly packet filtering rules is gonna change that.
But that's not the end all. I don't want my entire house to stop working because I got a new ISP and I have a few days of down time. Or more like because my ISP went down because they oversell bandwidth and haven't updated their routing hardware in 15 years. Maybe I don't want my file server with all my family photos globally addressable. Maybe I don't want my kids on the global internet at certain times. The point is I know what's best for my house. Im sick of the old IPv4 mindset where the only reasonable model is centralized global trust (see we agree that's been the status quo).
Explain more how this would work.
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.
But that means that other customers can get a trusted certificate for the exact same ip address, right?
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.
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.
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.
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)
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.
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.
E.g., imagine some UPnP-style broadcast where a device announces a public key, human-readable name and some type/capability information. Browsers listen for broadcasts and show users a notification once they discover an unseen device. Once confirmed, they can identify the device by its public key and also use it to establish encrypted connections.
You could also define out-of-band methods to share the key, e.g. via an on-device wifi hotspot, NFC, a USB plug or a QR code printed on the device.
Mozilla's Web-of-Things spec seems to show at least a willingness to work on this. Though right now they seem to re-solve exactly all the already solved problems and tackle none of the unsolved.
...or you could simply treat HTTP in local networks as a secure origin and be done with it.
> ...or you could simply treat HTTP in local networks as a secure origin and be done with it.
I think this is a lot harder than it sounds. What's a "local network". Is a coffee shop or public wifi a local network? How does the browser know? How do you know a rogue IoT device isn't doing ip spoofing?
If self-signed is not an option, then I think an internet connection and domain name are required. (Which seems to me is totally fine. That's the whole point of IoT)
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.
Criminals in Hong Kong can’t teleport to my door. Local security for locks is fine because the threat is always local.
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?
It seems to me the best options are either trusting a self-signed cert (on every computer that needs access) or pay for a domain name and use letsencrypt to get a cert. I do think it's unfortunate that you now need to pay money just to do things like this on your own network, but I don't see a better way. It's either paying for a domain name or needing to explicitly trust the device.
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)