Disable HTTPS upgrade? [LWN.net]

Disable HTTPS upgrade?

Posted Mar 5, 2025 9:22 UTC (Wed) by PeeWee (subscriber, #175777)
In reply to: Disable HTTPS upgrade? by intelfx
Parent article: Firefox 136.0 released

why should someone's desire to have some $feature in a completely unrelated context break a completely valid, legal and standards-compliant configuration? (emphasis added)

Who says that it is? I am half suspecting that it just happened to work because of implicit reliance on side effects, i.e. no-one ever tried to connect via HTTPS before.

to post comments

Disable HTTPS upgrade?

Posted Mar 5, 2025 9:41 UTC (Wed) by intelfx (subscriber, #130118) [Link] (12 responses)

> Who says that it is?

Because existence and nature of HTTP services on port 80 on a particular host is not supposed to mean or convey anything about existence and nature of HTTPS services on port 443 on the same IP address. If you want to prove me wrong, please quote an RFC.

Disable HTTPS upgrade?

Posted Mar 5, 2025 10:41 UTC (Wed) by PeeWee (subscriber, #175777) [Link] (6 responses)

It's implicit in the definition of HTTPS, which is just HTTP over TLS. And the mentioned effort of said HTTPS Everywhere addons has basically established this as a quasi standard. Also the problem @Cyberax describes looks like it can be fixed by proper authentication certificates for all the host names or a wildcard for the lower level domain.

Disable HTTPS upgrade?

Posted Mar 5, 2025 10:46 UTC (Wed) by intelfx (subscriber, #130118) [Link] (5 responses)

So, it's not actually a thing. Thanks.

Disable HTTPS upgrade?

Posted Mar 5, 2025 10:56 UTC (Wed) by PeeWee (subscriber, #175777) [Link] (4 responses)

You may also want to checkout @csamuel's reply and the knowledge base article he linked to. If that method does not work, it's a bug which should be reported, simple as that.

Alas, this is yet another storm in a tea cup, imagined by people whose go-to response is ranting about some vendors they chose to hate, yet they still use their product. So the problem is in fact not a thing. Thank you.

Disable HTTPS upgrade?

Posted Mar 5, 2025 11:07 UTC (Wed) by intelfx (subscriber, #130118) [Link] (3 responses)

You are linking to internal documentation containing a description of the behavior of one specific implementation, the one whose behavior is being questioned. That does not advance the discussion at all.

Just like in your previous comment ("mentioned effort of said HTTPS Everywhere addons has basically established this as a quasi standard"), it is invalid to justify some sort of behavior by the fact that this behavior exists.

Disable HTTPS upgrade?

Posted Mar 5, 2025 11:31 UTC (Wed) by PeeWee (subscriber, #175777) [Link] (2 responses)

You are linking to internal documentation containing a description of the behavior of one specific implementation, the one whose behavior is being questioned.

That is very much public documentation, which one arrives at by following the link in the release notes.

That does not advance the discussion at all.

You are making up problems which are non-existent. That does not advance the discussion.

Just like in your previous comment (""mentioned effort of said HTTPS Everywhere addons has basically established this as a quasi standard""), it is invalid to justify some sort of behavior by the fact that this behavior exists.

The user who enters an incomplete URI is at fault, basically, and FF just changed how it defaults (hence the name) the request. And that's what you get when you rely on side effects. Always enter complete URIs and there is no problem.

Disable HTTPS upgrade?

Posted Mar 5, 2025 15:20 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

> The user who enters an incomplete URI is at fault

I never said I did this, yet you somehow assumed a fact that makes me at fault.

> You are making up problems which are non-existent

Okay, so you apparently know better than me what problems I experienced. This is a subtype of a personal attack, and, again, not something that's called a "good faith discussion". This is a pattern (even in this message, but also with you in general), therefore I will not talk to you further. Have a good day.

Disable HTTPS upgrade?

Posted Mar 5, 2025 15:50 UTC (Wed) by PeeWee (subscriber, #175777) [Link]

> The user who enters an incomplete URI is at fault

I never said I did this, yet you somehow assumed a fact that makes me at fault.

Why does everything have to be about you? Are you that narcissistic? I was (implicitly) referring to @Cyberax, or rather the problem they described above.

> You are making up problems which are non-existent

Okay, so you apparently know better than me what problems I experienced.

No, I am referring to your assertion that somehow FF is doing something wrong here, which it does not.

This is a subtype of a personal attack, and, again, not something that's called a "good faith discussion".

I apologize if it came across that way, which was not my intention.

Disable HTTPS upgrade?

Posted Mar 5, 2025 10:55 UTC (Wed) by excors (subscriber, #95769) [Link] (3 responses)

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.

Disable HTTPS upgrade?

Posted Mar 5, 2025 11:02 UTC (Wed) by intelfx (subscriber, #130118) [Link]

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

Sure, that's a restriction placed on the previous clause. Yet, "the exception proves the rule in cases not excepted".

So it is, in fact, true that besides this mutual distrust caveat, RFCs declare http:// and https:// resources as separate namespaces. I take it as a pretty clear-cut confirmation that the standards agree with my interpretation.

Disable HTTPS upgrade?

Posted Mar 5, 2025 14:07 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

> because cookies are shared by all schemes and ports on the same host.

... which independently of https is a major design bug since webservers on non-standard ports exist.

Disable HTTPS upgrade?

Posted Mar 5, 2025 15:19 UTC (Wed) by excors (subscriber, #95769) [Link]

Yeah, modern web security is based on "origin" (basically a tuple of scheme, port and host) which is generally sensible, but cookies were invented long before that and can't be fixed because of backward compatibility requirements. If you want to properly isolate sites then they can't even be on different subdomains of the same domain - they must be completely different domains, up to a suffix listed in the Public Suffix List (.com, .co.uk, .github.io, etc). And definitely don't try to isolate them just by port. It's a bad design, but it is what it is.

(Or as RFC6265 puts it: "For historical reasons, cookies contain a number of security and privacy infelicities.")

Disable HTTPS upgrade?

Posted Mar 6, 2025 1:29 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

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