[lucideer]

> * 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 that's a well-acknowledged issue but those who disagree on less-severe expiry warnings would simply argue here that it would be preferable to be strict in both cases and that the lax approach to http:// is just legacy baggage we should work toward getting rid of.

Personally, I'm a little on the fence. The expiry UX could definitely be "improved" (made more helpful) without making it more lax. Another thing to consider is that going from lax to strict is MUCH MUCH harder than going from strict to lax, so easing severity now would make it difficult to undo that change later.

[entropyie]

That legacy baggage is the only thing that allows older hardware to connect to the modern network. It's the only thing that allows folks the agency and autonomy to setup their own services and share them with folks locally, without requiring the blessing and grace of a distant 3rd party authority.

I've spent 20 years working with advanced PKI and cryptography in many different domains and form factors, and what I've learned is that even with the best of intentions, they are all fragile and their default state is broken, without constant maintenance.

Availability and resilience to failure are key pillars to security that are often overlooked.

In the past 20 years, all of the critical failures in PKI systems that I have seen were due to expiring certs, expiring CRLs, failure to distribute new PKI in time, accidental deletion of key PKI, missing intermediate certs. None were due to MITM, weak crypto, spoofed packets, use of plain HTTP. Make of that anecdote what you will.

[lucideer]

> In the past 20 years, all of the critical failures in PKI systems that I have seen [...] None were due to [...] use of plain HTTP.

Not sure how a PKI failure specifically can be due to use of plain HTTP, but I assure you there's been plenty of other very real security failures over the past 20 years due to use of HTTP.

> That legacy baggage is the only thing that allows older hardware to connect to the modern network.

This sounds like legacy baggage, yes. The term "legacy" is not a value judgement. It doesn't mean "bad", it just means "old".

[jen20]

> without requiring the blessing and grace of a distant 3rd party authority.

Nothing stops you installing a private CA into the trusted roots for this kind of case.

[entropyie]

Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor.

In 40 years time, how will anyone be able to make use of my "antique Internet Radio / Amazon Alexa"?

Virtually zero appliances / embedded systems sold today allow you to configure the CA bundle. Even Android is locking this down bit by bit as they don't want anyone peeking at all the surveillance traffic their Apps are sending to the internet.

[jeroenhd]

Your 45 year old rotary telephone could also have encrypted the numbers you're dialing. Buying user-hostile devices is what leads to user-hostile behaviour.

Apps needing to opt into CA certificates are an annoyance for sure but in 45 years the API those apps are talking to won't be running anyway. You'll still be able to buy WiFi adaptors for whatever tech we'll use by then to physically hook up your current devices, but the network itself won't work unless you set up a server for yourself.

Your converter box is similarly difficult, an old "speaker hooked up to a wire" protocol has been converted into a fully fledged Internet appliance. The POTS services that the phone wants to connect to are no longer there, you need to spoof them; the same will be true for the smart crapware we buy today.

[lucideer]

> Here is a thought experiment for you: Right now, I have a 45 year old rotary telephone working fine in my living room, hooked up to VOIP with an adaptor.

The adaptor in your analogy sounds like it could be analogised by a local transparent proxy.

A more apt formulation of the analogy would be phone companies persisting DTMF to avoid the need for adapters.

----

<off-topic> What adapter do you use? I also have a rotary phone & have been struggling to find a good one...

[entropyie]

A local proxy in this analogy would have to be able to MITM the traffic... which is unlikely to work with an Alexa. I'd like to see the EU mandate customer configurable CA bundles, but I won't hold my breath! --- https://www.dialgizmo.com/ A bit finicky, but does what is says on the tin ;-)

[lucideer]

If the definition of "older hardware" is closed saas-supported media products then I guess this is a different discussion than I thought. I'd be surprised if the SaaS support lifespan of things like Alexa would even be long enough for the hardware to be in any way usable after reaching an age considered "old" but... if it does, then I'd suggest the sibling commenter's point about selection criteria fits here.

> * I'd like to see the EU mandate customer configurable CA bundles*

Agree but I'd go broader - right to flash or some kind of general firmware/os/softwate openness mandate would be nice to see.

[jen20]

Make that part of your purchase criteria if it matters to you.

[AnIdiotOnTheNet]

> Availability and resilience to failure are key pillars to security that are often overlooked.

In my experience, it cannot be overstated how true this statement is.

[peoplefromibiza]

> http:// is just legacy baggage we should work toward getting rid of.

I, the server, should decide what protocol to use, not the client i.e. some software provided by two of the largest World corporations, which are also, by sheer accident I suppose, American.

I can send encrypted content over that insecure channel that only some receiver could decrypt and read.

It's none of Google's or Apple's business like it wasn't Microsoft's business to impose their browser and their standards on all of us.

[lucideer]

> I can send encrypted content over that insecure channel that only some receiver could decrypt and read.

We've tried this approach with email and has not resulted in a world where I can easily send secure emails to anyone I know.

Even setting aside the problem of inconsistent clients, you're asking for a world where every server re-invents wheels & you haven't even begun to think about solving for authentication (which is a very hard problem even with TLS)

[peoplefromibiza]

I'm simply saying that HTTP is perfectly fine and it's not legacy.

Of course it's easier to pay for a certificate from a certification authority that maintains the infrastructure, and no, Letsencrypt is free only on the issue side, but maintaining HTTPS has its warts (for example: renew the certs every 3 months!)

but the problem is not HTTP, HTTP in the hands of people who know what they are doing is completely okay, if browsers ban HTTP I predict an explosion of protocols like Gemini or something similar

A lot of low power devices don't need or can't handle HTTPS and there's no problem if what they do doesn't need security nor identity verification.

Meanwhile it's baffling that we are pushing for internet non-public non-state-run identity authorities, while in UK, Japan, Russia, USA and many other countries such an authority don't even exist for real people...

[lucideer]

> it's baffling that we are pushing for internet non-public non-state-run identity authorities, while in UK, Japan, Russia, USA and many other countries such an authority don't even exist for real people...

This I'm fully onboard with. We absolutely need to be more active in moving away from this approach of centralised authorities - there's unfortunately no rreal candidates for this outside of the blockchain space. I think we're stuck in an awkward time where many "I need an alternative to centralised systems" innovators end up turning to blockchain, which inevitably leads to vapourware. Hopefully that tendency disappears soon.

Otherwise though, you seem to be avoiding the elephant in the room with HTTP.

> there's no problem if what they do doesn't need security

The fundamental problem is that users need security, and implementers are tasked with making this decision on behalf of users (users don't "choose" to use an unencrypted protocol on the web). Implementers have historically not been the best stewards of user needs. IOW: there are far too many cases of things that do need security where implementers don't believe it does.