What's the point of this? I understand why you might want this for APIs that expose private user information, but this just performs some computation. You could do the same thing with a js library or webassembly. Is this just to punish http sites?
Making all new API development available only when content is delivered via a mechanism that provides the foundation for the rest of web security is good engineering practice.
In these scenarios a self-signed certificate will rarely improve security because most users will click through the warning anyway in case of an MITM attack.
It's also possible to get a certificate from a CA using any public IP address, and then reuse that cert for LAN. Certs are bound to domain names, not IP addresses.
Even when I have an offline network, I still use SSH whenever possible.
Yes, I don't benefit from initial verification, but I pin the certificate from then on.
I don't think that the current "all or nothing" paradigm that we use with SSL in browsers makes any sense.
I have been really disappointed over the last few years deploying network connected devices and trying to make their services available in a secure way.
It is not really possible for ipcams, routers, etc to offer services in HTTPS in a semi-online network. There should be a kind of 'encrypted but unverified' mode.
Even the worst failure mode is no worse than a plaintext connection.
Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel.
HTTPS, with its current UX, would be a net negative in this case.
I would just replace "HTTPS" with "SSH", and see if that statement is still reasonable.
Even though SSH is not perfect when you can't verify the initial connection to a host on a local network, using TELNET instead is not a solution.
I have yet to hear a reason why HTTP is better than self signed and pinned HTTPS; why possibly insecure is worse than insecure.
The only justifications I have heard are UX justifications, and those are really just a critique of the UX, not the protocol.
> Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel.
That is an extremely fragile solution.
By default ethernet is very open. It is very easy to bridge it with other devices or routers to announce themselves and start routing. It happens all the time on what are supposed to be closed networks, I've seen it.
And many networks are semi-offline. You may need to have limited internet access. Or the network configuration may change in the future.
> By default ethernet is very open. It is very easy to bridge it with other devices or routers to announce themselves and start routing. It happens all the time on what are supposed to be closed networks, I've seen it.
The reason for using Ethernet and browsers is that both are built into pretty much every computer, don't require any drivers, admin privileges or persistent software.
The idea is to replace USB, serial or some other point-to-point link which would require platform-specific drivers and client software. Most peripheral connections for printers, etc don't employ encryption on the control cables and the world hasn't ended, so physical security here is good enough in practice for the majority of purposes.
Forcing https in these applications is a waste of time and money for orthogonal purposes. I guess it could be seen as a cost of dev. for any web based application from now on, but it's sad to me to see the barrier to entry get higher for these reasons.
The steps for an intranet or regular domain is exactly the same if you use the DNS challenge as the web server is no longer involved regardless.
The DNS methods we already mentioned does not involve any of that - just a simple zone file change or a few clicks in a web UI to add a new record.
So much simpler for everything to revert to client only mode and route all messages through a server 3000 miles away. Until they pull the plug and nothing works at all.
So... lets... make the tech that powers it not suck, so we can stop with all this analog business.
Maybe the state of the art has changed since the last time I looked, but it would be really nice to have something as easy as Lets Encrypt for private tools while at the same time not exposing internal network details.
https://developer.mozilla.org/en-US/docs/Web/Security/Secure... Locally-delivered resources such as those with http://127.0.0.1 URLs, http://localhost and http://*.localhost URLs (e.g. http://dev.whatever.localhost/), and file:// URLs are also considered to have been delivered securely.
For those whooshed by the reference, it's about the iPhone's antenna design flaw that Jobs poopooed on stage, to silently get it fixed on the next version.
It seems we're agreeing it's an actual issue that would merit to be fixed.
If there was something sensitive in front of my camera, I wouldn't give any random site permission anyway.
File system access should definitely be secure only, the rest might not need it.
Of course if Mozilla actually did FlyWeb we could almost totally deprecate HTTP except for some public legacy sites.