Firefox 136.0 released

RFC9110 says:

> Resources made available via the "https" scheme have no shared identity with the "http" scheme. They are distinct origins with separate namespaces.

but then goes on to mention cookies as an example of features that undermine the strict distinction. Specifically RFC6265 says:

> servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security-sensitive information.

because cookies are shared by all schemes and ports on the same host. So even if you stick to the hypothetical world described by RFCs and ignore practical concerns, you can't treat HTTP and HTTPS services on the same host as completely independent.

This is the web, not some NIST-compliant government boondoggle. Everyone used to write charset='iso-8859-1' when they should have written charset='windows-1252'. You can tell people that they're wrong, but that won't fix the websites that already exist. Instead, WHATWG specifies the former as an alias for the latter, and both are now "correct." You should expect that common practices gradually ossify into standards - that is how the web has always worked.

As for HTTPS in particular:

* The HTTPS Everywhere extension has demonstrated that, in practice, many websites serve the same content on HTTPS as they do on HTTP, and you really can just replace http:// with https:// in a lot of URLs.
* HSTS (RFC 6797) has established a precedent that web standards should go out of their way to support and enhance the case where HTTP redirects to HTTPS, even if this means overriding the user's explicit instruction to connect with HTTP.
* The entire .dev gTLD is preloaded into HSTS. If you buy one of those domains, you cannot serve HTTP at all (at least, to any of the usual browsers), because the browser will rewrite all URLs to HTTPS.
* All major browsers now display "Not secure" or similar warnings when visiting an HTTP site.
* Chromium and Chromium-based browsers have been doing the whole "opportunistically upgrade HTTP to HTTPS" thing for select users (plus anyone who manually turns it on) since 2023.[1]

Realistically, I think it's only a matter of time before WHATWG decides to write this behavior down and call it a "living standard."

Disclaimer: I work for Google, but not on any web-related technology such as Chrome. Opinions are my own.

[1]: https://blog.chromium.org/2023/08/towards-https-by-defaul...

OK, there's that, I totally forgot about it. But then you don't really have to bother with setting up anything beyond that on port 80. ;)

You can't really get rid of local (LAN) HTTP. Or at least, there is no reasonable way to do it. In order to serve HTTPS over a LAN, you need a globally routable domain that you can administer (from the LAN). Technically, you do not need to purchase a separate second-level domain for every consumer - it would be enough to buy one domain and give every consumer a separate subdomain, and then use split-horizon DNS so that each consumer only sees their own subdomain (Let's Encrypt and other CAs will happily give you a certificate if you can manipulate DNS records, even if you cannot serve HTTPS on the public web - I know this because I do it on my own LAN). But nobody wants to administer a solution that involves managing so many subdomains with trust delegated to consumers. You would need a separate API key for each instance of the product, a flow for recovering from an account lockout or device wipe, probably some fairly beefy DNS nameservers, and so on. To make things even worse, I can't see a way to avoid remote-bricking these devices when you're no longer interested in supporting them (your DNS nameservers go away, the devices can no longer renew their HTTPS certificates, they expire, the end). I'm not going to say this is impossible as a solution, but it is IMHO unreasonably complicated for such a straightforward premise, assuming you want to do it at scale as an OEM, and not just as a one-off hobbyist configuration for your own personal network.

There are explicitly non-global domains, such as *.home.arpa and *.internal, and you can (legitimately) make up addresses under those domains and serve them using split-horizon (as well as funkier options, like mDNS for *.local), but there is as yet no consensus on how trust should work in that case. Who has the authority to assert these names, and issue certificates for them? It can't be the "regular" global CAs (they do not know which LAN the user is on, and therefore which example.internal is the "real" example.internal from that user's perspective), so they would need to be issued by some sort of local or per-LAN CA. But that just begs the question. IP has no trust hierarchy - when a packet leaves your device, it's up to the rest of the network to decide what to do with it. There is no IP-based procedure for identifying an "authority" for a particular network, nor even for proving that (e.g.) a given router has the de facto ability to route packets for a given network segment (DHCP and IPv6 NDP do not count, because they have no security, so anyone can impersonate the router if they feel like it). That functionality almost(!) exists in the context of BGP and IXPs, but nobody's home network is a whole AS, so it is rather useless for LANs, even if we leave aside the fact that it regularly fails to prevent random ISPs from accidentally turning each other off due to BGP misconfigurations.

I've only heard of one general idea that seems like it has any chance of working, and it looks roughly like the following:

1. When you connect to a LAN, you scan some sort of QR code or similar thing. It might be permanently etched or printed on the surface of the router, or in some other non-removable place where the consumer can easily find it.
2. Whatever you scanned contains a trust token. If not already connected to the LAN, you are prompted to do so, and then you are prompted to accept the trust token.
3. Your device imports this trust token as a limited-scope root certificate, valid only for non-global TLDs like .internal.
4. Some CA on the network holds the private key corresponding to that certificate, and may issue domain certificates based on it. Your device will trust those domain certificates while it is connected to the network. Most likely, this CA is a service running inside the router.
5. When you disconnect from the network, your device must invalidate, delete, or otherwise distrust the root certificate.

There are still quite a lot of obvious problems with this:

* Many consumer devices have a habit of promiscuously connecting to any WLAN they see if the current WLAN appears to be down. This raises the possibility that the user thinks they are connected to network X when in fact they are connected to network Y, and Y is hostile and attempts to impersonate some of the services offered on X. The solution is to require that trust tokens may only become active by explicit user action (ideally, only by scanning a code, so that WLANs with the same SSID do not have their trust tokens confused).
* We need to validate that the user connected to the correct network for a given trust token (or else an attacker could mislead the user into importing some attacker-controlled token instead, and then impersonate local network services). This can be done at import time, by checking that some standardized non-global domain (e.g. www.certificate-check.internal) is serving HTTPS with a certificate that would be valid if we accepted the trust token, but we would need to pick a single standard domain.
* More generally, publicly-accessible WLANs raise a lot of complicated and thorny questions about what constitutes "the real" network and how we should protect the user from a "fake" network. Probably the easiest way to fix this is to avoid using non-global domains on such networks (if you're a giant company providing a WiFi hotspot for your consumers, you can afford to administer one real domain for your whole setup, and then you can just use conventional/global certificates and avoid all this faff entirely).
* We really ought to explain to the user what they are doing when they scan one of these codes, and give them an opportunity to cancel, but it's hard to come up with a good wording that won't confuse non-technical folks *and* will convince them that they should refuse to connect if they do not trust the source of the code.
* In turn, that raises the issue that consumers don't usually pay much attention to what network they are currently on. It may be unwise to assume that users can distinguish between example.internal (on Alice's network) and example.internal (on Bob's network) without some kind of specialized UI that has not yet been invented. By assumption, we cannot display any globally-meaningful identity information to help the user figure out which is which (any means of supplying and authenticating such information would necessarily be just as difficult as using a globally-routable domain in the first place).
* You would still need a means for LAN devices such as printers to talk to the CA, establish mutual trust (presumably with user supervision/approval), and get themselves a local domain and certificate. The flow described above works great for phones, but most printers cannot scan a QR code. There are a variety of options here, but something would need to be standardized so we don't end up with fifty mutually-incompatible onboarding flows.