[dale_glass]

> My biggest issue with this whole situation, is that the user gets a better UX with no encryption whatsoever on a http:// site than a self-signed or expired cert on https://.

I think part of the issue was that priorities shifted. Initially, SSL was for commerce. You were looking for assurance that your credit card number wouldn't be captured in flight, and would go to the right, verified party.

In this context, a self-signed certificate is somebody claiming "trust me, I'm a bank manager" despite being unable to prove any association with your bank. And somebody with an expired ID might be a former, disgruntled employee whose ID has expired because they don't work there anymore. Both of those are far more suspicious than somebody not claiming to be anything in particular.

> Especially for local LANs, but also for small websites, there should be a way to use TLS with a self-signed cert to say hey, I'm not making any strong claims of identity or privacy here, I just want some modicum of obfuscation of the traffic.

That's not really reliable. The moment you install that as a norm, you'll have various countries doing MITM and generating their own cert for the site. Any confidence such a scheme provides is extremely suspect, as it relies on nobody exploiting the flaw for personal benefit.

> Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed.

That only works if you think your attack mode is a hacked/malicious access point at a cafe or hotel. If you're in a place like Russia or China the state has the resources to ensure you always get the same MITM-ed cert, unless you play games with VPNs, which may well land you on some sort of watch list.

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

[jandrese]

I’ve always found it weird that expired certs are treated like a doomsday scenario by the browser. Technically they aren’t valid, but if it is just because they timed out the level of threat seems low. The only danger is that they might have been on a CRL that also trimmed the certs when they expired. In practice CRLs are barely used.