- We'd like to make an IoT gateway that you can use from a browser.

- To get access to necessary APIs, we have to provide it via HTTPS.

- The get HTTP we need a certificate. Because no one is going to pay for it, we'll use Let's Encrypt.

- To get a Let's Encryt cert, we need a verifyable hostname on the public internet. Ok, let's offer subdomains on mozilla-iot.com.

- To verify that hostname, Let's Encrypt needs to talk to the gateway. Ok, let's provide a tunnel to the gateway.

- Now the gateway is exposed to the internet and could be hacked. So we need to continously update it to close vulnerabilities.

So in the end all your IoT devices are reachable from the internet. But hey, you can use Firefox to turn your lights on!

In simple terms it allows you to setup a TLS session by both sides proving they know the secret password, without either side exposing it, thus MITM is unable to capture it, it is an alternative to the cert model that works very well for network local devices.

But of course Chrome and firefox both have zero interest in supporting this use case despite TLS-SRP kicking around for ages now, they'd much rather have you connect to your own devices via a mediated cloud gateway server, for your own safety of course.

1. Should most people have access to a domain they control?

2. Should there be a standard for nonroutable / nonpublic domains? (.lan and .localdomain are two of which I'm generally aware)

3. How should browsers deal with hosts and/or domains which are not and can not be on the public Internet?

4. How the hell did we get into this mess?

I'm kicking around the notion of relaxing various aspects of the problem domain and seeing where we end up. It's mind-numbingly bad, though.

Note that domains don't solve the problem of a third-party controlling your point-of-access or presence, they only move it elsewhere.

I'd say that in the world we live in, getting a domain is as useful as getting a passport. It costs a bit of money to get and renew and is a bit of a hassle, but it opens a lot of doors.

I think that's the point. Creating friction that scares normie users when people are using web UIs on local networks puts non-cloud based products at a disadvantage against the centralized giants.

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)

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.

I think fundamentally your issue here is with secure contexts, not with the site labeling. In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts.

Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages.

> Still, the app will forever be marked as insecure. Although it isn't. It is trivial for the user to verify that the connection is secure by comparing the certificate fingerprint with that displayed by the server program she just started.

Is it, though? Assuming your server hasn't been compromised (nobody is monitoring it to make sure!), and assuming that the self-signed cert cannot be easily exfiltrated, and assuming that they don't do the same thing the next time they get an ugly warning from chase-bank.ru because they're sure that it's spurious -- then maybe?

While that might be an option now, it's not going to be viable. Browser vendors have agreed to make all new JS APIs -- mostly independent of their security implications -- available to secure contexts only [1]. Even now, you cannot use the Crypto API -- which is entirely implementable in plain JS, albeit slower and with higher energy consumption -- without secure contexts. Or you cannot raise the IndexedDB storage limit for your application above a certain threshold without a secure context (which is exactly my problem, I want users to be able to temporarily store a few hundred MB on their mobile device).

> Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages.

I completely agree. I understand the implications of me doing this and I honestly don't want to.

I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.".

That would solve the problem, no landing page from my application required.

> Is it, though?

You're right, there are a lot of assumptions I'm making here. However, I see no reason why my local HTTPS site should be displayed as less secure (red cross, red text in the URL bar) than a local HTTP site.

[1] https://blog.mozilla.org/security/2018/01/15/secure-contexts...

Exactly, that's why browsers are trying to move in the direction of making HTTP sites appear as less secure.

> I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.".

I totally agree it's a UX issue, but I don't see a good solution. Unfortunately your browser doesn't know if you're on "your own network infrastructure" and not at a coffee shop. It needs to be on the safe side and assume it's not a trusted network.

Maybe the browser should require you to type in the fingerprint of the key.

[1] https://github.com/w3ctag/design-principles/pull/75

I don't know if this problem is soluble -- at least a self-signed certificate would mean that the certificate would have to be exfiltrated in order to do this, assuming the browsers key the indexedDB to the certificate fingerprint, which would indicate a degree of compromise that most likely means that the data could be stolen directly from the device.

If you don't mind being more specific, what kind of data would you be storing on the phone? Is it just for caching purposes? It seems like it might be better for the data to be fetched from the device on demand rather than stored on the phone, even if this causes a performance hit, to avoid the possibility of leaking the data to untrusted parties.

Sure, my particular use-case is a media management/playback application (think web-based audio player; like Plex, Ampache, Spotify) that is intended to be used with a large personal library of audio files (in the order of a hundred thousand files, about 1 TB of data). The application has an offline-mode (via ServiceWorkers, everything being REST, content addressed and infinitely cacheable), where the connected client can request to "pin" a certain playlist/filter. Upon request, all media files with that filter will be transcoded/downloaded onto the client and are available even when having no connection. So it's not really any data that needs to be kept secure (still, all media blobs are encrypted anyhow to allow public caching -- for internet hosted instances -- without having to fear IP issues).

As for your particular hassle, it makes sense to me for a browser to mark sites that mix http/https as insecure from the point of view that once the data is on the plain http page you can no longer be sure that it won't be handed off over an unencrypted connection some place else by some rogue javascript.

Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. Say, a method for routers to discover certificates announced by devices on the network to list them in its management interface where you can enable or disable them.

That would be idiotic not just because unrusted parties can use those addresses, but more importantly because those are more or less terrible hacks that should be avoided completely if possible. You rather should have globally unique addresses on your internal network if you can, which would just break this.

> Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks.

That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. It's the internet, not "the home network and the cloud".

What is needed is a way to establish a trust relationship between two devices that you have control over. Where those devices happen to be connected to the internet should be absolutely irrelevant. There might be an argument to be had to maybe support for a simplified peering procedure on a local network might be a good idea--but the point is that once the trust trelationship is established, you should be able to move your client device to a different network on the other side of the planet and still be able to talk to your device on your home network.

Seems quite unavoidable with IPv4, or what is the hack you're referring to specifically?

> That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network.

What is the reason against? It's not like the idea of a privately managed network in which you trust all peers is novel or rare. Most people have a network in their home that they manage for themselves or for their family. It's the perfect scope for IoT devices.

> It's the internet, not "the home network and the cloud".

That's an interesting notion, but unfortunately does not reflect reality of use or the design of existing internet protocols, or even the very core concept of the internet: interconnected networks. I have a private network at home. My means to connect devices on this network to the internet is via a gateway which is assigned a single globally unique internet address by my service provider, and a locally unique address on the private network.

If at some point every device has its own global address and is accessible globally, it will be more accurate to assume that something is insecure if it communicates in the plain, but we're not there yet. What the browser is doing now is pretty much assuming an arbitrary level of "better safe than sorry".

> What is needed is a way to establish a trust relationship between two devices that you have control over.

Say, by sharing sharing keys over a network under your control, certified and authorized by a device you trust for pretty much everything else on that network?

> Where those devices happen to be connected to the internet should be absolutely irrelevant.

Agreed, but the current conundrum is that they need to be connected to the internet if you want to use a central certificate authority.

Well, yes, for most people it unfortunately is. But imagine if your are one of the lucky ones who do have global IPv4 addresses everywhere. And now someone sells you a product that tells you "sorry, nice IPv4 network that you have there, but you have to install NAT and an RFC1918 network to use this IPv4 product". Not very sensible, is it? Same applies for IPv6 and ULA, obviously.

> What is the reason against?

What would be a reason for limiting the usefulness of your devices?

> It's not like the idea of a privately managed network in which you trust all peers is novel or rare.

Which is fine, but not a sensible assumption to make in an IP product. If you want to use it in a privately managed, trusted network, of course you should be able to, but the idea that an IP device should just refuse to work over IP if your IP happens to extend beyond your LAN is idiotic. That should be a matter of the network's policy, not of the device's hard-coded policy.

> That's an interesting notion, but unfortunately does not reflect reality of use or the design of existing internet protocols, or even the very core concept of the internet: interconnected networks.

Erm ... that's completely backwards? It unfortunately does not reflect the current use of IPv4 in particular due to NAT everywhere, but that certainly was not part of "the design of existing internet protocols", that was a hack due to lack of addresses.

What was before the internet were separate local (and sometimes not so local) networks: You had all kinds of link-layer protocols, and then various higher-level protocols, usually specific to a given link-layer. The whole point of the internet was to add a common abstraction to all of those link layers protocols, precisely to eliminate any distinction between local or remote, ethernet or token ring, modem or ISDN, GSM or CDMA, an addressing layer that erased the distinction: If you had an IP address and the thing you wanted to communicate with had an IP address, you could, even if you were on token ring, your WAN link was ISDN, the backbone was ATM, the peer's WAN link was a dial-in modem and their LAN was ethernet. The point of IP is that you don't have to care, any IP address is as good as any other.

> I have a private network at home. My means to connect devices on this network to the internet is via a gateway which is assigned a single globally unique internet address by my service provider, and a locally unique address on the private network.

Well, yes, unfortunately, that is the case nowadays. That is not how IP was meant to be used, and it's causing massive problems. If it weren't for lack of addresses, your home network should have a globally unique /24 or something (and it did, back in the day).

> If at some point every device has its own global address and is accessible globally, it will be more accurate to assume that something is insecure if it communicates in the plain, but we're not there yet. What the browser is doing now is pretty much assuming an arbitrary level of "better safe than sorry".

Not sure I am getting your point!?

> Say, by sharing sharing keys over a network under your control, certified and authorized by a device you trust for pretty much everything else on that network?

Well, arguably you totally should not trust your router, they tend to be crap security-wise.

But in any case, my point was that at most that should be a pairing mechanism. So, once the trust relationship is established, there should be no need to stay on the local network for further secure communication.

> Agreed, but the current conundrum is that they need to be connected to the internet if you want to use a central certificate authority.

Well, yes?! But the solution is not to hard-code policies that prevent full use of IP.

Are you arguing from the assumption that my suggestions and any other form of establishing trust are mutually exclusive? If you're that lucky guy with a global address for your lightbulb, by all means use what's at your disposal to establish a trusted encrypted link between the device and the user in a convenient way. Not sure how that would prevent the vast majority using these on private networks with a different method of authentication and different criteria for trust.

> Erm ... that's completely backwards? It unfortunately does not reflect the current use of IPv4 in particular due to NAT everywhere, but that certainly was not part of "the design of existing internet protocols", that was a hack due to lack of addresses.

So, given the limited address range, it was clearly not designed for every person in the world to have an address, not to mention every appliance in your kitchen. The internet has grown rather organically and has adopted a broader use case. The infrastructure, protocols and best practices used on the internet now reflect this unanticipated use case.

> Well, yes, unfortunately, that is the case nowadays. That is not how IP was meant to be used, and it's causing massive problems. If it weren't for lack of addresses, your home network should have a globally unique /24 or something (and it did, back in the day).

How it was meant to be used is an artefact that stopped mattering some time in the 80s.

> Not sure I am getting your point!?

The point is that flagging plain http websites as "unsafe" makes a lot of assumptions about my network. They're not necessarily unsafe. In one case, it's on my apartment-wide LAN. In another case, it's connected by ethernet directly to the client. Neither of these are particularly exotic topologies.

> But in any case, my point was that at most that should be a pairing mechanism. So, once the trust relationship is established, there should be no need to stay on the local network for further secure communication.

Why not both?

> Well, yes?! But the solution is not to hard-code policies that prevent full use of IP.

Agreed? I'm not sure where you got the idea that I think that any of these things should prevent the full use of IP. Certainly not from anything I've said.

Well, if that were a standardized way to establish trust, that necessarily would lead to vendors adopting it at the cost of suporting other kinds of setups?

Also, it is very problematic to overload not globally routable addresses (also often misleadingly called "private addresses") with security semantics. While many home setups do have a sort-of security boundaries around RFC1918 subnets, there is absolutely no guarantee that that is the case. So not only would such a mechanism break "sane" (i.e., NAT-free) setups, it also would make otherwise perfectly fine and useful setups risky. Have a VPN link to another company that also uses RFC1918 space or ULA, and suddenly your IoT stuff starts trusting that other company. Or even just if you happen to have departments that aren't supposed to trust each other, and that happen to have a common ULA prefix, and now some devices simply assume trust where none is implied/make it impossible to use otherwise perfectly fine setups because of unjustified trust assumptions. Or simply a guest on your network. Or ... whatever else that can share non-globally routed address space with you without any trust implied.

> So, given the limited address range, it was clearly not designed for every person in the world to have an address, not to mention every appliance in your kitchen. The internet has grown rather organically and has adopted a broader use case.

Well, yes, but that wasn't because it was intended to be used with NAT, or anything else that was not a globally routable address for every device, but because it wasn't expected to gain that many users.

> The infrastructure, protocols and best practices used on the internet now reflect this unanticipated use case.

Which is an argument for what exactly? Especially with regards to IPv6 and ULA?

> How it was meant to be used is an artefact that stopped mattering some time in the 80s.

Why would that have stopped then? Again, in particular with regards to IPv6, which does not have the address scarcity that might have justified use of NAT and non-globally routed address space as a temporary workaround?

> The point is that flagging plain http websites as "unsafe" makes a lot of assumptions about my network.

... just as not doing so does? If anything, it would be arbitrary to just exempt certain prefixes from security policies when there is not normative basis for such an exemption. I happen to have only globally routable IPv6 addresses on my LAN, but my LAN is indeed trusted, both wired and WiFi, using distinct /64s. But I also have a guest WiFi that is in the same IPv6 /48, which is not trusted. And I have a VPN link to a customer of mine that uses RFC1918 address space, which is absolutely not trusted.

So, yes, it is "better safe than not safe". But it's exactly the opposite of arbitrary, in that it does not make any assumptions about your network, it provides security no matter what the details of your network, and using the exact same policy for everything. And it's hardly "better safe than sorry", given that this is all a result of being very sorry about all the crap that resulted from lack of security so far.

> They're not necessarily unsafe. In one case, it's on my apartment-wide LAN. In another case, it's connected by ethernet directly to the client. Neither of these are particularly exotic topologies.

Yeah, and how is your browser supposed to know that?

> Why not both?

What both?!

> Agreed? I'm not sure where you got the idea that I think that any of these things should prevent the full use of IP. Certainly not from anything I've said.

The question is not whether it should, but whether it would. Suppose browsers were to implement a policy of "RFC1918 and ULA are considered safe unencrypted and -authenticated". What would vendors of devices do? I guess we can agree that they would use that policy for config access, as it simplifies the design of their devices, right? Now, that would cover 99%+ of their current user base. Which probably means they won't bother providing an alternative mechanism. Which means (a) you can't use their devices in other setups and (b) their users are locked into such setups, which makes it impossible for, say, router vendors, to build more useful networking products that use the full potential of IP.

So on one hand you believe that supporting one standard will necessarily come at the cost of supporting another (I don't), and you agree that what I suggested might cover 99%+ of the current user base, yet you favor a solution that depends on global addresses, something which definitely doesn't come close to 99% of potential users?

> Also, it is very problematic to overload not globally routable addresses (also often misleadingly called "private addresses") with security semantics.

Well, if you want to be really anal about it you could call them "addresses which fall into one of the address ranges allocated for private use", but you're just splitting hairs.

> While many home setups do have a sort-of security boundaries around RFC1918 subnets, there is absolutely no guarantee that that is the case.

There is no guarantee, but that's different from saying that it's inherently unsafe.

> Which is an argument for what exactly? Especially with regards to IPv6 and ULA?

It's a reflection on how the internet is built. It doesn't matter that in the ideal network, everything might have an address, when pretty much every device is behind some kind of NAT. IPv6? Come back when it's widely adopted.

> Why would that have stopped then? Again, in particular with regards to IPv6, which does not have the address scarcity that might have justified use of NAT and non-globally routed address space as a temporary workaround?

It stopped mattering because of address exhaustion and slow adoption of IPv6. Now, NAT is an integral part of the internet. I'm not trying to justify it or state this as a matter of preference—I'd definitely prefer having a ton of IPv6 addresses over the single IPv4 address I actually have—I'm just laying things out as they are, and how they are for the vast majority of consumers.

> ... just as not doing so does?

No. Flagging a website as "safe" when it can not be established that it is safe is at least as wrong as flagging it as "unsafe" when it can not be established as being unsafe. What I'm suggesting, not flagging it in any particular way at all, would be taking a neutral stance. IMO, the practice of calling HTTPS sites "secure" is itself potentially misleading to consumers. It is only secure in a very specific sense, likely not in the broader sense a layman would consider.

> Yeah, and how is your browser supposed to know that?

The question I stop at is "why is my browser supposed to know that?"

> What both?!

Both a way of verifying and distributing certificates network-wide in a LAN and for those certificates to be usable globally.

> The question is not whether it should, but whether it would. Suppose browsers were to implement a policy of "RFC1918 and ULA are considered safe unencrypted and -authenticated". What would vendors of devices do?

The premise of my suggestion is that the browsers won't back down from indiscriminately marking plain HTTP sites as insecure, hence "Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks."—so suppose they would support such a method. Would that be better or worse than current practice?

> Which probably means they won't bother providing an alternative mechanism. Which means (a) you can't use their devices in other setups and (b) their users are locked into such setups, which makes it impossible for, say, router vendors, to build more useful networking products that use the full potential of IP.

That's a load of conjecture. I'm not sure how to respond except with a bunch of other conjecture, so I'll refrain.

So, you think vendors who have covered 99%+ of their userbase with a solution will generally also implement an alternative that is way more complicated for the remaining 1%?

> and you agree that what I suggested might cover 99%+ of the current user base, yet you favor a solution that depends on global addresses, something which definitely doesn't come close to 99% of potential users?

No, I favor a solution that does not depend on the global (non-)routability of an address, i.e., a solution that works for 100% of users.

> Well, if you want to be really anal about it you could call them "addresses which fall into one of the address ranges allocated for private use", but you're just splitting hairs.

But that is still equally misleading. There is nothing "private" about those addresses, and in particular nothing "more private" than globally routable addresses. Anyone can use those addresses, all the RFC essentially says is that you won't collide with addresses allocated by RIRs, but they might collide with other administrative domains that choose to use the same prefix. That doesn't mean that you cannot use them on a WAN, or between companies, or really anywhere where you can agree with all participating networks on the allocations. All it means is you have to expect collisions if you connect previously separate administrative domains, and that you cannot expect yout ISP to announce them for you on the public internet, that's it.

Also, just as you can use non-globally routable addresses between networks, you can use globally routable addresses for private networks, and you should if you can (which in practice means when you build an IPv6 network): Even if you build a network that is not intended to be connected to the internet at all, if you do have a globally routable IPv6 prefix allocated for your organization, you should number that network with addresses from that prefix.

> There is no guarantee, but that's different from saying that it's inherently unsafe.

No, it's actually not. "unsafe" does not mean "you will hurt yourself", it means "it has not been established that you won't hurt yourself".

> It's a reflection on how the internet is built. It doesn't matter that in the ideal network, everything might have an address, when pretty much every device is behind some kind of NAT. IPv6? Come back when it's widely adopted.

So, for the question of how to achieve (as close as possible to) an ideal network, it doesn't matter what the ideal network would look like?! Or do you think we should just wait until device vendors have screwed up IPv6 before we try to enforce some sensible policy?

> It stopped mattering because of address exhaustion and slow adoption of IPv6. Now, NAT is an integral part of the internet. I'm not trying to justify it or state this as a matter of preference—I'd definitely prefer having a ton of IPv6 addresses over the single IPv4 address I actually have—I'm just laying things out as they are, and how they are for the vast majority of consumers.

So ... because noone uses IPv6, you suggested to use ULA as an indicator for security?! I am not sure I follow ...

> No. Flagging a website as "safe" when it can not be established that it is safe is at least as wrong as flagging it as "unsafe" when it can not be established as being unsafe.

No, you don't establish "unsafety", that is the default assumption. The only way to establish that something is unsafe is to show after the fact that someone got hurt, which is just completely useless as a security mechanism.

> What I'm suggesting, not flagging it in any particular way at all, would be taking a neutral stance.

Wouldn't a neutral stance be to instead display a security status of "security unknown" (which is obviously equivalent to insecure)? "Not flagging it in any particular way" simply means that the user makes an assumption one way or another, not that the user thinks "it is unknown whether this is secure".

> IMO, the practice of calling HTTPS sites "secure" is itself potentially misleading to consumers. It is only secure in a very specific sense, likely not in the broader sense a layman would consider.

Well, yeah, but that is not really relevant to the question about warning about an insecure situation. Just because there are insecure situations that you cannot warn about, does not mean that therefore warning about other insecure situations isn't useful. Really, it makes much more sense to warn about insecure situations (which means, situations not known to be secure against certain types of attacks deemed relevant in the respective context) than to in display anything that says "this is secure", as security is alway relative to specific attacks, not a global property.

> The question I stop at is "why is my browser supposed to know that?"

Because your browser should help you protect your personal data that you process using your browser? I mean, I don't think it should know that, it should just enforce the same encryption requirements everywhere, but you seem to disagree with that because there are networks where your personal data is secure without encryption--in which case, your browser would either have to give up the goal of protecting your personal data, or it would have to know about which parts of your network are secure without encryption.

> Both a way of verifying and distributing certificates network-wide in a LAN and for those certificates to be usable globally.

Well, that would be a pairing mechanism then?! (Which still should not overload global routability with security semantics.)

> The premise of my suggestion is that the browsers won't back down from indiscriminately marking plain HTTP sites as insecure, hence "Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks."—so suppose they would support such a method. Would that be better or worse than current practice?

It depends on the mechanism? Yes, centralized certificate management for your own devices would be useful, but it should not in any way overload the routability of addresses. If you want to use the LAN as a semi-trusted key exchange mechanism, that probably should happen at the ethernet layer. Or maybe with a one-hop TTL on the IP layer. You have to detect whether you are on the same LAN, not whether you are using an RFC1918/ULA prefix, because not all LANs use RFC1918/ULA, and nor all RFC1918/ULA are limited to a LAN, let alone a trusted LAN.

> That's a load of conjecture. I'm not sure how to respond except with a bunch of other conjecture, so I'll refrain.

It is mostly an observation of what always happens in such situations.

Not necessarily, but the designer of a standard could take both use cases into account.

> No, I favor a solution that does not depend on the global (non-)routability of an address, i.e., a solution that works for 100% of users.

What, more precisely? Of course taking into consideration that 100% of users might not even have an internet connection. One thing I'd like is for devices to a their key signature printed on a sticker. Then I can verify the signature, log in and generate a new key and password, generate a certificate that I can install myself or sign up with a service like Let's Encrypt.

> But that is still equally misleading. There is nothing "private" about those addresses, and in particular nothing "more private" than globally routable addresses.

No, it's not misleading to say that they are allocated for private use. Your ISP drops connections to these addresses because they respect RFC1819 and don't route to the private address ranges. Even if they didn't, these address ranges are still allocated for private use, and your ISP is Wrong. They're only routable in the sense that IP would technically allow it, but the internet is not simply IP but a collection of standards and best practices.

And sure, "private" has a very broad meaning. A browser could very well flag a certificate that was distributed from a private address as such and let the user decide whether they trust that source.

> Also, just as you can use non-globally routable addresses between networks, you can use globally routable addresses for private networks, and you should if you can (which in practice means when you build an IPv6 network): Even if you build a network that is not intended to be connected to the internet at all, if you do have a globally routable IPv6 prefix allocated for your organization, you should number that network with addresses from that prefix.

Sure. But again, "in practice means when you build an IPv6 network", i.e. not a typical consumer, for how long more? In an enterprise there are already many different ways to solve the problem of authentication, certificate signing and encryption. Consider that the average internet user doesn't even have a registered domain name or a static IP allocation.

> No, it's actually not. "unsafe" does not mean "you will hurt yourself", it means "it has not been established that you won't hurt yourself".

So everything on the web should be flagged by the browser as unsafe? I don't know how the browser can ever safely establish that I won't hurt myself. "Unsafe" and "safe" are two sides of a subjective, blurry line, at best a reasonable assumption and at worst an arbitrary handwave.

IMO, the browser is taking what should be exact descriptions of the nature of the connection and water them down to vague, misleadingly simplified concepts. The browser could tell me that my connection to a site is unencrypted, that it is encrypted with an uncertified key, or that it's not encrypted, and when you click them they could show a help text describing what that means exactly, the possible consequences of using the service and details on the key and certificate if applicable. When I click the "Secure" badge in Chrome, I don't even get to see which CA signed it, or a public key.

"Secure" and "Insecure" mean just that, rather impossible things for a browser to verify, and something that a user unfamiliar with the underlying technology may interpret as an authoritative rating of the provider of the service as a whole, when in reality there are many more aspects to take into a count in deciding whether a site is secure or insecure.

> So, for the question of how to achieve (as close as possible to) an ideal network, it doesn't matter what the ideal network would look like?!

Well, it involves IPv6, we can start there. We're talking about a new security policy that a major browser seems to want to implement shortly, definitely much more shortly than full IPv6 rollout.

> Or do you think we should just wait until device vendors have screwed up IPv6 before we try to enforce some sensible policy?

This is a very loaded question, given that we still disagree on whether a solution that works well both for globally routable and NATed devices is possible.

> So ... because noone uses IPv6, you suggested to use ULA as an indicator for security?! I am not sure I follow ...

I never said that no one uses IPv6, so I agree that you don't follow.

> No, you don't establish "unsafety", that is the default assumption. The only way to establish that something is unsafe is to show after the fact that someone got hurt, which is just completely useless as a security mechanism.

Let's say that I see your ladder. It's broken, so I tell you that it's unsafe. Unreasonable assumption? You take it down and bring another ladder. I don't see it, but I tell you it's unsafe. You see it and can clearly say that it isn't. Is it unsafe? Is it reasonable for me to tell you that it is unsafe? "Unsafety" isn't the default assumption that a browser makes (and with regards to plain HTTP in particular still isn't in the version of Chrome I'm using).

> Wouldn't a neutral stance be to instead display a security status of "security unknown" (which is obviously equivalent to insecure)? "Not flagging it in any particular way" simply means that the user makes an assumption one way or another, not that the user thinks "it is unknown whether this is secure".

Maybe that's actually the better option. But no, "security unknown" in that sense is not equivalent to insecure. As an extreme, I could create a network with an Ethernet cable between two off-grid devices that I control in a faraday cage. On the other end of the extreme, someone could be tapping a cable far away from my computer and figure out what connections I make regardless of encrypted data. Somewhere in between the two extremes, close to the likely, the party that I establish a secure connection too could be sharing our communication with other parties.

> Because your browser should help you protect your personal data that you process using your browser?

We've already established that the browser can't know it, so is the browser a fundamentally flawed concept?

> Well, that would be a pairing mechanism then?! (Which still should not overload global routability with security semantics.)

Yes? The only part you seem to disagree with is the possibility of having a router in a local network (and yes, local networks exist) facilitate and streamline the exchange.

> If you want to use the LAN as a semi-trusted key exchange mechanism, that probably should happen at the ethernet layer.

So again, a perfect application for a router? The router is in a perfect position to verify that I am on its network.

> It is mostly an observation of what always happens in such situations.

Yes, as evident from the absolute lack of overlapping authentication and encryption standards...

> On the other end of the extreme, someone could be tapping a cable far away from my computer and figure out what connections I make regardless of encrypted data. Somewhere in between the two extremes, close to the likely, the party that I establish a secure connection too could be sharing our communication with other parties.

Which is in no way in conflict with saying "this is insecure". That is in conflict with saying "this is secure", because that implies "... against this specific set of threats", which is not understood by the average user. So, yes, I agree, browsers should generally avoid telling users that something "is secure", but it is perfectly fine to say "this is insecure".

> We've already established that the browser can't know it, so is the browser a fundamentally flawed concept?

No, it's just a subjective entity as all entities in the world are, and so it has to determine risks based on incomplete information, as all entities in the world have to. Also, it's not strictly true that it cannot know that, but it cannot know that without you telling it. It might well be possible to have an option where you could tell your browser "this set of addresses is safe to talk to unencrypted and unauthenticated".

> Yes? The only part you seem to disagree with is the possibility of having a router in a local network (and yes, local networks exist) facilitate and streamline the exchange.

No, I disagree primarily with overloading the semantics of "private addresses", and with mechanisms that only allow communication in a local network. "private addresses" is neither reliably indicative of nor a required property of "within the same local network".

But also, a mechanism that does not depend on being on the same local network for pairing would be preferable.

> So again, a perfect application for a router? The router is in a perfect position to verify that I am on its network.

OK ... how?

> Yes, as evident from the absolute lack of overlapping authentication and encryption standards...

... implemented in the same product, where one of them would always have been enough to meet the requirements of 99% of potential users, and the others would have taken considerably more effort to implement?

> Not necessarily, but the designer of a standard could take both use cases into account.

Which doesn't help if it's a separate mechanism. If 1% of the work gets you to the goal in 99% of the cases, that's what vendors will do. Whether that fulfills the requirements of some standard or not does not matter.

> What, more precisely?

I am not making any suggestions as to the solution.

> Of course taking into consideration that 100% of users might not even have an internet connection.

So, if the device is one that does not inherently need global internet connectivity to be useful, then, yeah, things should work without global internet connectivity.

> One thing I'd like is for devices to a their key signature printed on a sticker. Then I can verify the signature, log in and generate a new key and password, generate a certificate that I can install myself or sign up with a service like Let's Encrypt.

Well, a fixed key is a problem, but other than that, yeah, an out-of-band path for key exchange sounds good.

> No, it's not misleading to say that they are allocated for private use. Your ISP drops connections to these addresses because they respect RFC1819 and don't route to the private address ranges. Even if they didn't, these address ranges are still allocated for private use, and your ISP is Wrong. They're only routable in the sense that IP would technically allow it, but the internet is not simply IP but a collection of standards and best practices.

OK, let's get this straight: What does "private" mean? It's a word with a whole lot of only partially overlapping definitions. For the purposes of this discussion, it is important to distinguish the aspect of "independent from official entities" from the aspect of "not revealed to the public", i.e. "providing privacy". RFC1918 addresses are only private in the former sense: You can allocate and use them without coordinating with RIRs or your ISP. However, they have absolutely nothing to do with the latter sense of providing privacy. That is why it is misleading to call them "private addresses": People understand that to mean that they are defined to provide some sort of secrecy or privacy or protection from the public or something along those lines, which they don't. It's not wrong, because there is a different meaning of "private" that fits exactly what RFC1918 are defined to be used for, but it is misleading because it leads people to assume that it encompasses more than that.

Also, whether ISPs do it or not doesn't really matter. What matters is that RFC1918 address space is in fact routed between networks that are not intended to trust each other. And that is perfectly within the uses intended in RFC1918. The RFC isn't concerned with home networks, really, but with "enterprises", and it defines "an enterprise" to be the scope of an RFC1918 allocation. Nowhere does it say that that implies any sort of trust or security relationship between machines within such an allocation. And also, in practice, it is common to link RFC1918 networks of different "enterprises" together, as a sort-of "meta-enterprise", where a trust relationship is even less likely.

The only thing that is "private" about RFC1918 addresses is that you can allocate them without coordination with IANA/RIRs/ISPs, and that you cannot expect an ISP to route them for you on the global internet. There is no privacy specified in the RFC.

> And sure, "private" has a very broad meaning. A browser could very well flag a certificate that was distributed from a private address as such and let the user decide whether they trust that source.

How does it matter for this whether the address is "private" (i.e., allocated without coordination with IANA/RIRs/ISPs)?

> Sure. But again, "in practice means when you build an IPv6 network", i.e. not a typical consumer, for how long more?

Erm, most IPv6 use is by consumers, with ~ 20% adoption based on google users?! Not sure whether that's quite "typical" yet, but certainly not unusual either. Most user devices support IPv6, and increasingly, ISPs are rolling out IPv6 to their customers with new subscriptions, which tends to come with new routers, which means that at that point their network is using IPv6 for all services that support it.

> Well, it involves IPv6, we can start there. We're talking about a new security policy that a major browser seems to want to implement shortly, definitely much more shortly than full IPv6 rollout.

Yes, and that is the only way to do it. If you wait until after full IPv6 rollout, you will have to work around assumptions that device vendors by then will have made based on the browser's behaviour, which means it only gets harder to implement. If you want to have any hope of success, you have to act now, when your actions can shape what device vendors will do.

> This is a very loaded question, given that we still disagree on whether a solution that works well both for globally routable and NATed devices is possible.

You have so far failed to even show a solution that works better for NATed devices than non-NATed ones.

> I never said that no one uses IPv6, so I agree that you don't follow.

Replace "noone" with "essentially noone" if you want to get my point.

> Let's say that I see your ladder. It's broken, so I tell you that it's unsafe. Unreasonable assumption? You take it down and bring another ladder. I don't see it, but I tell you it's unsafe. You see it and can clearly say that it isn't. Is it unsafe? Is it reasonable for me to tell you that it is unsafe?

Unsafety is not a(n objective) property of the ladder, it's a (subjective) state of your knowledge. The ladder will only either fail or not (that is an objective fact about the ladder). Even a ladder with partially broken steps might still hold up, and a ladder that is all new and shiny can still have some manufacturing defect that causes it to fail on first use. The former is good to use, the latter is not. But that is a useless concept if your goal is to minimize harm because you only know that after the fact. So, what we use instead is a concept of "unsafety". Statements about unsafety are an expression of our knowledge about something. So, the ladder with broken steps is considered unsafe, because based on what we generally know about the statistical properties of ladders with broken steps, they are known to have an increased failure rate. But then, you might apply load tests to that ladder and establish that it does carry the loads required reliably if you avoid the obviously broken steps, in which case it can be considered not unsafe. Mind you, nothing has changed about the ladder, only our knowledge about it has changed. Similarly for the new and shiny ladder, those are generally considered not unsafe because of what we statistically know about new and shiny ladders, and maybe about how ladders are tested after manufacturing. But then, you could test that as well, and maybe find that it breaks apart under light load, at which point you would change to considering it unsafe. Again, nothing has changed about the ladder, it's all about the knowledge you have about it. And the tests I suggested are not the end of that process of discovering the unsafety of a thing. You might still do other tests yet and come to yet another conclusion (like, I dunno, the testing conditions were unnecessarily harsh, and under more realistic usage conditions the opposite conclusion is appropriate).

Now, not knowing anything about the ladder is just another state of knowledge. And if your goal is to minimize harm, then the default is not to assume safety. Again, that is in no way a statement about the ladder. That does not mean the ladder won't hold up. That only means that the ladder is not known (to you!) to hold up. It is always and exclusively a statement about your knowledge about the ladder.

This is not about answering the question "will the ladder fail?", this is about answering the question "is it known to the best of our understanding that the ladder will not fail under some generally expected load conditions?". If the answer to that is "no", then that is reason to be cautious, and that is why the browser warns you/is going to warn you.

You can of course argue that your goal is not to minimize harm, in which case the default assumption does not apply ... but then the whole discussion is pointless, as you are then essentially just saying "if you don't care about minimizing harm, there is no problem with trusting unencrypted connections (of some sort or another)". True, but not my goal, and obviously also not the goal of those people implementing the change.

> Maybe that's actually the better option. But no, "security unknown" in that sense is not equivalent to insecure. As an extreme, I could create a network with an Ethernet cable between two off-grid devices that I control in a faraday cage.

Yes, you could. But the browser doesn't know that. Therefore, its subjective determination is "this is not known to me to protect your private data", and that is what it is telling you. If you know better, that's fine, but the browser doesn't, so it warns you. If you don't know better, you better should listen to what your browser is telling you if your goal is to minimize harm. If you do know better, why do you care that your browser warns you based on its incomplete knowledge about the world?

B) Scopes are exactly: "the global internet and the home".

Considering those things why should it be absurd if I want to secure my home scope at the application layer too? IPv6 is literally designed to allow for this. Browsers are the things that are being stubborn.

If IPv6 is just a terrible collection of hacks then we need a new version and fast before everyone get stuck on v6 for the next 50 years....

1. global addresses,

2. rotating temporary global addresses,

3. universal local addresses (one for each site), and

4. a link-local address (required).

The first 3 now technically reside in the global scope. ULAs used to be called site-local and had their own scope, but they were restructured to basically be fancy UUIDs and their scope abolished and merged with the global scope. Link-local is still its own scope.

Although both are globally scoped, there's a difference between a global IPv6 address and a ULA. The global is globally routeable and prefixes are organized regionally and delegated to allow hierarchical routing while ULAs have arbitrary prefixes (not suitable for global routing) and are not supposed to be forwarded to interfaces outside their subnet.

So to answer your question, for local communications in your home that you didn't want leaving your network, you would use ULAs. You could use link-local addresses if your home was all on the same l2 link, but the generally preferred solution is to use ULAs so you don't leak protocol details upwards and so you can leverage l3 tunnels.

Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS. If you want DNS on your home site you simply run a local DNS server that resolves your local names and is configured to forward unknown names to the global DNS.

IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution.

Well, not disagreeing that you can have those, but why are you mentioning that specifically for "global addresses", but not for ULA?

> while ULAs have arbitrary prefixes (not suitable for global routing)

How are ULA prefixes different from PI allocations as far as suitability for global routing is concerned?

> and are not supposed to be forwarded to interfaces outside their subnet.

Would you mind pointing to the normative source for this forwarding policy?

> Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS.

Would you mind pointing to the normative source for this?

> IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution.

But you said that ULA are global scope (which they are, I agree), so what does this have to do with scoped addresses?

Also, which void exactly does killing NAT leave that needs filling (and that then supposedly is filled by ULA)?

To communicate out of a https secured web mailer to a local IP and Port where a security card reader driver would respond they registered bealocalhost.de which resolves to 127.0.0.1. To prevent mixed content errors they then shipped the private key for a https certificate for bealocalhost compiled into the card reader driver.

Obviously after someone noticed that the cert got instantly revoked...

There is no way to build a device with HTTPS that allows the user to distrust the maker of the device.

Edit: before I get responses "you can never distrust the maker" — on HTTP I can audit the device, install it, and keep it in the local network forever, trusting it for decades. On HTTPS it needs to be online every 3 months, and the owner could very well intercept it at that time.

It'd be much better if DANE would already be supported, as the DHCP server can send you to a DNS resolver returning key info for local IPs, which in turn could use the corresponding certs.

Trying to add security in such an environment is... useless.

TL;DR: If you can MitM a system at the root, you can already break basically anything relevant.

Meanwhile, routers are generally known to be insecure, and who knows how many viruses my guests bring onto my Wifi network when they ask to connect.

Set up a DNS server that, for a domain of 10-0-0-1.$rand.X.com returns 10.0.0.1

Generate DNS challenges for your domain, issue lets encrypt certificates for said domain.

Viola, private, local, publicly-trusted, SSL-encrypted.

Have http://10.0.0.1/ redirect to https://10-0-0-1.$rand.x.com/

The biggest issue with this is getting LetsEncrypt to issue you enough certificates.

PS: this idea is somewhat borrowed from Plex.

But, yes, there needs to be an easier way to say, yes, please trust this certificate. (Like how ssh prompts you the first time)

This isn't as big of a problem as you'd like to believe. IMHO.

In general, how can I get all the functionality e.g. a Nest device may provide, while staying purely within of my 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)

Do you also expect a regular end-user to install their own electrical outlets ?

The internet is just too important to leave to amateurs, look at how much damage badly configured home networks and computers are causing already. This stuff needs to be secured properly.

You also didn't need a drivers license when cars just became available, but now there are shitloads of cars we have to make sure drivers are capable before letting them drive. Same goes for network-connected equipment.

That way people are then motivated to hire a professional. Also, people making devices will be motivated to not use a default "admin" password because customers will start saying "uh, this smart toaster cost me hundreds of dollars when I plugged it in."

A ridiculous proposition given the current state of technology? Also yes.

If it happens, implemented in turnkey devices (such as SOHO routers) in a way that enhances vendor control rather than empowering home users with the option to use their own domain names and certs? Likely, that's the trend these days and doesn't show signs of receding.

The last line is kinda a tangent, but if that came to be the case, I would no longer be on board with the idea every device should have a FQDN.

Edit: And don't get me wrong, I'm totally for TLS on the local network; but there should be an easy way for users to permanently mark self-signed certificates from a local address as secure.

If someone wants to run it in a network with no access to the DNS, you can just tell them to put that in their hosts file (or whatever local DNS setup they are using).

I'm not sure I agree that that's where ux need improvement. Microsoft already have a pretty "easy" solution for pushing locally trusted ca certs, but only in an "enterprise" environment.

Most/all Linux distros will allow pushing to /etc/ssl/certs/ca-certificates (via eg /usr/local/share/ca-certificates and update-ca-certificates).

But that doesn't help as long as browsers work hard to be "special", and manage their own trust.

Being able to mark some nets as trusted/local might help - both with :::1 and with vpns.

If so, that I would try something like this :

- get a domain if you don’t have one

- configure a subdomain (like myhomeserver.mydomain.tld) to that IP on the DNS (A record)

- get a Let’s encrypt certificate using DNS validation

- install the certificate on the local server

I haven’t tested this with certificates, but we used to do this back in the days to avoid configuring local DNS on some small companies networks

You don't need to buy "domains", but certainly for a commercial project that makes loads of things which need names it would make sense to own a sub-domain to put all the names in.

You also don't need to "connect to the internet just for DNS lookup" unless you really want to. The point of using DNS names isn't that you can look them up in DNS, it's that they're are a unique hierarchy with a central authority.

There _are_ alternatives to DNS names but none of them have a trustworthy and working PKI today so you can't use them to secure anything you build. Maybe building a trustworthy PKI is hard?

If you insist upon using Let's Encrypt (which is a charitable purpose and so charges $0 for certificates) perhaps because it's actually a hobby project then yes, somebody would need to control DNS records in order to periodically prove control over each name and get issued a certificate, because that's how ACME (the protocol Let's Encrypt use) decides whether to issue.

Many other public CAs are for-profit companies and several already have _active_ commercial deals in which they issue certificates for devices in bulk to the name owner. If you're EXA Metal Poles Europe and you're making 50 000 devices named in the range pole0000.foo.example.com through poleFFFF.foo.example.com they are quite happy to issue you, the legitimate owners of example.com with 50 000 certificates for those devices in exchange for money.

The local device should have a _name_ and then we can issue it a certificate for that _name_ and know we're really talking to the same thing as last time. DHCP and other address allocation protocols don't (needn't) change the name.

The domain stays the same so long as the key does, so the user can bookmark the page for their own device and be sure that when they navigate back to that domain they're getting the same device and not some imposter—effectively making this equivalent to "trust on first use".

Edit: Changed "on the certificate" to "on the public key". It might be necessary to regenerate the certificate periodically, e.g. to update the expiration date, and that shouldn't affect the domain name.

Edit: To be more precise, and to quote [1]

"Secure Contexts says UAs MAY treat localhost as a secure context only if they can guarantee it will only ever resolve to a loopback address (and are in any case not required to). https://w3c.github.io/webappsec-secure-contexts/#localhost"

[1] https://github.com/w3ctag/design-principles/pull/75#issuecom...

It seems to me secure localhost would only be needed for developers, and developers should be able to allow a self-signed cert.

I don't understand why developers so often choose the browser as a frontend. Are there better rationales besides having at least some frontend for tyrant-controlled devices like iOS'es, and just using the skills one already has?

For the first, just tell the people to get proper devices.

Because of the second, I see schooling efforts for JavaScript by the tech giants so negatively. It leads to masses of people using JavaScript where it shouldn't be.

Other nice things to see: multiple independent open source implementations of the application platform; a stable and battle tested sandbox, such that users can run code from hundreds of different vendors every day without much worry about being pwned.

The web is old and hoary, but to me there isn't any comparison. For most apps I build, the second place choice isn't even close.

That seems like a great way to have no users.

An incredibly obvious reason would be that it is the largest application delivery platform with the highest level of user familiarity and comfort.

If you compare two services where one of them offers you a direct login to the app and the other offers you a 200MB download, most people will choose to log in to a website. It's a better user experience. Especially for things that will see infrequent use.

The scenario you are drawing is not a proper comparison. There is no reason why a native toolkit couldn't support rendering the program before it's fully loaded, so I see no reason a native program would need more data transfer upfront than a JavaScript one. Though I think too that being prompted to download the program, then install it and find the way to run it can be cumbersome, but the solution to this is to not do it this way. Why not integrate with the native way to obtain applications and make it transparent and convenient for the user?

After all, I think there might be fundamentally different goals when developing a software, and that explains the difference. If one has accepted advertisement-based financing of projects, then them and I would probably disagree in many ways. I think users devices must only and exclusively work for the user.

This is pure insanity. There are tons of applications built on the web stack now that are supposed to run on local networks. There has never been a requirement that "Network == Internet".

For example, enterprise software. Dynamics CRM? Dynamics NAV? Dynamics... anything? Sage CRM? Everything runs on the browser now.

Why would anyone pass up a gigantic, proven, powerful software stack that represents >90% of all applications in the world?

The error is in the stack, not that people would want to use the easiest, most powerful tool for the job.

We might as well be advocating to go back to FoxPro.

>For the first, just tell the people to get proper devices.

It must be super nice to live in a world where you can dictate what devices the clients use, as opposed to a huge investment of pre-installed devices, or, devices users bring from home.

Whatever job you've got, I want it. Because it's completely alien to my career experience.