[entropyie]

As I said, I am well aware of the perils of MITM. There are mitigations for all your concerns, and in each case, the question should be: is this better or worse than plan HTTP.

As I mentioned below, mitigations include: restricting this scheme to IP Addresses only, non-routable netblocks only, certain TLDs like .local, .lan .personal etc...

In regards to oppressive regimes, the state can also block all traffic unless you relent and install their CA cert in your browser bundle.

Mitigations here would be certificate transparency, pinning etc... I would also suggest that CA certs should be restricted to certain TLDs. Important websites can use all these mitigations, while still allowing my scheme for connecting to my Raspberry PI, kitten blog, or wifi router.

[dale_glass]

> As I said, I am well aware of the perils of MITM. There are mitigations for all your concerns, and in each case, the question should be: is this better or worse than plan HTTP.

I think it would be initially better, then gradually become worse. And that's a horrible thing when the public is concerned.

There's still people out there concerned about the "memory effect" for battery charging, and recommending a full discharge every time, even though that advice has been obsolete for decades now due to different battery chemistries. But the public easily latches on simple advice and doesn't consider the technical reasons for it.

So I imagine the same would be the case here. You'd have a marginal improvement for a short time, until the situation changes and suddenly people have to absorb "Yes, this was fine in 2023, but now is a complete no-go in 2026".

Since we're considering UX here. What UX do you propose that would reliably tell my nigh computer illiterate mom what to do with "the self-signed certificate for this site changed" if she receives it at a hotel while traveling? And what if she first opens the site in a hotel abroad, then comes back home and gets it there? How are non-experts supposed to untangle that?

[entropyie]

Also, today, if your Mom visits google.com, for the first time, and the hotel blocks port 443... guess what? It will try to connect to google.com using HTTP on port 80... at which point the hotel can inject whatever they like.

In terms of UX, in my scenario, if they "really" wanted to, the browser could fake a HTTP:// scheme along with the crossed out lock icon, effectively identical to the status quo in terms of UX, but with improved (not perfect) privacy.

[Flimm]

Webmasters can ensure that browsers only load their websites over port 443 by submitting their domain to the HSTS Preload List.

Surprisingly, google.com is not on this list: https://hstspreload.org/?domain=google.com

[dale_glass]

I expect that to go away eventually, by browsers simply not allowing HTTP for non-local requests. This means a hotel doing this looks like one where wifi just doesn't work.

[entropyie]

What kind of router, raspPI or kitten blog will you Mom be visiting at the hotel that would be of any importance? As I said, I wouldn't suggest allowing this scheme for anything important, such as Google, banks etc...

To answer your question, I don't think the TLS cert should ever change for these kinds of non-identity certs. if they do, the standard warning can apply.

My point is that there should be an escape hatch to provide resilient solutions to narrowly defined use cases, such as hobby websites, wifi routers etc... that don't trains users to bypass security control like the current scheme does.

Right now, if I want my Mom to configure her Huawei wifi router, she has the choice between sending her password in plain-text to a trivially spoofed website, or being trained to ignore TLS warnings and overriding those warnings in her browser, before sending her password into a still-spoofable website.

[dale_glass]

> What kind of router, raspPI or kitten blog will you Mom be visiting at the hotel that would be of any importance? As I said, I wouldn't suggest allowing this scheme for anything important, such as Google, banks etc...

That is part of the problem. How is she supposed to know what's okay or not in what context?

The simplest answer that ensures security as well as we can is to simply not give the user any options. Everything must be encrypted, nothing can be self-signed, plain HTTP support is disabled.

> Right now, if I want my Mom to configure her Huawei wifi router, she has the choice between sending her password in plain-text to a trivially spoofed website, or being trained to ignore TLS warnings and overriding those warnings in her browser, before sending her password into a still-spoofable website.

I think that's solvable, and may have already been solved.

I think current ASUS routers already contain a valid certificate for something like router.asus.com, and the router responds to HTTPS on that address. Or something along those lines, I've not really interacted much with it.

But the point is that in such a scheme, the router would contain a valid cert, issued by a valid authority.

[mLuby]

> There's still people out there… recommending a full discharge every time, even though that advice has been obsolete for decades

The battery UX should hide this implementation detail from the user. If 20/80% is 0/100%, just do that and provide some override setting for "power users" so to speak.