[entropyie]

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 know all the stories about MITM attacks, but the fact is, it is still MUCH easier to accidentally or purposefully log unencrypted http:// traffic in a passive manner than it is to actively spoof a HTTPS:// connection.

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. Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed.

Also, the fact that the entire world's infrastructure relies on some small, centralised non-profit in the USA (LetsEncrypt) makes me very nervous. Ordinary citizens can end up on the wrong side of sanctions through no fault of their own...

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

[ThePhysicist]

LetsEncrypt is not the only ACME provider, and there are hundreds of regular CAs. Nothing about TLS certificates is centralized, there's just market concentration as a result of good UI/UX by LetsEncrypt, but there are open-source ACME implementations available, the protocol itself is in the process of being standardized and nothing keeps other CAs from running the same service, and in fact many are planning to do just that.

[nisegami]

>Nothing about TLS certificates is centralized

You're right that there are additional ACME providiers, but the reliance on just a handful of default root cert stores is what makes HTTPS centralized, even if TLS isn't.

[jeroenhd]

Most big apps bundle their own certificates/certificate authorities for cert pinning already. They can switch to their own CA system any time.

Sadly, DANE has failed because DNSSEC has failed on the American market. Hopefully we'll find an alternative for these protocols in the future.

[vbezhenar]

I'm using strong protection in Chrome and it prevents me from browsing HTTP websites unless I explicitly allow it.

So while you're correct, it's just a historic issue and soon browsers will treat HTTP like bad HTTPS but not in a sense you're proposing but rather forbid both.

[amluto]

> 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. Also, a user should be able to trust a specific cert once on first visit, and then be warned only if that cert changed.

This is asking for trouble. If a site presents itself as https://foo, it should be foo according to global norms of what that means. No self-signed certificates.

What I think is needed is a way for a site to make a claim that it can prove in a decentralized way. Here are some examples of ways this could work:

https://serialnumber.vendor.com

The device has a certificate (with no expiration!) identifying it, signed by the vendor. The vendor provides a new kind of certificate saying that the device cert matches the serial number. The vendor refreshes this certificate periodically. There are thorny issues involving keeping this efficient, revoking problematic certificates, having the client (which likely has Internet access, but maybe not if the device is a router, for example) refresh the certificate if the device itself can’t, etc.

https://something_entirely_local

The origin could be literally a hash of the device private key. Sure, it’s not human readable, but it could be bookmarked. To make this work, routing info needs to be added too, giving, perhaps:

https://iot_device_(hash here)@address_or_domainname/

An IoT device could even have a QR code on it with a link:

https://iot_device_abcd1234@something_5678.local

Bonus points if there’s also a way to fetch pages like this over something like BLE for provisioning.

[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 ;-)

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

[pilif]

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

How would a browser know whether a site presenting a self-signed cert is one where no strong claims of identity or privacy are needed or whether it's one where strong claims of identity are needed but which has been MitM'd.

Also, do this without the browser talking to some "mothership" to ask about what a domain should be treated us because that would leave that party in a position where it gets to all of your browsing history.

[entropyie]

Requiring a remote 3rd party to bless a transaction in order for two computers on a local network to talk to each other, is tyrannical and anti-resilient.

[entropyie]

DNS? crt.sh? Certificate Pinning? Apply this only to non-routable IPs? Apply this only to certain TLDs, such as: .local .lan .personal There are many options. Also, how would this be any worse than visiting a plain HTTP site instead?

[pilif]

DNS can be MitMd. crt.sh would be in a position to get all your browsing history.

The local thing would work, but of course only for local hosts.

It would not be worse than using plain http and my personal opinion is that visiting a plain http site should have the same UX as visiting a self-signed one.

[entropyie]

All fair points, and I would settle for HTTP equivalent UX. DOH and DOT would go some way to mitigating DNS inadequacies (although they have their own issues in terms of network autonomy). I personally think the best long term solution would be for each TLD to maintain the CA bundle and TLS standards for that TLD. That way there is no case where a CA cert from CN can issue a cert for google.com .

It would also specifically allow non-identity locally issued certs for .local, .lan, .hobby etc...

[nisegami]

The browser shouldn't, the user is the one that needs to make that determination. But right now, the user doesn't even have that choice.

[ozim]

You still can have untrustworthy page and user still has to make that determination with TLS or without. If you connect to bad guys server you still will get owned.

Problem is that technically *user should not make that determination* - for casual user TLS is transparent. Which takes burden of technically knowing if traffic was or was not MiTmed out of the question for end user. End users should make less technical decisions because they want to browse websites - not worry about if someone is injecting stuff in their traffic.

[andirk]

Good point! No encryption shows zero issue.

Your mention of us all using LetsEncrypt and similar is beyond my understanding of cryptography but why do they need to be signed by a central authority exactly?

[entropyie]

Ultimately every cert is signed by a Certificate Authority. This is a "Trust Anchor". An authority that you trust implicitly. Your web browser maintains a list of these trusted parties, which are measured in the dozens and only change occasionally after careful scrutiny by Browser vendors. If your cert is not signed by one of these CAs, there is no way to verify it's veracity. That is why the browser gives a scary warning. I could issue a cert claiming to be google.com without any deterance. Until recently all such authorities charged a fee to issue you a verified certificate. Also the process was usually not fully automated and required human intervention to renew a cert. LetsEncrypt was a major innovation for two reasons:

1. They provided the certificates for free, no strings attached 2. They provided a fully automated and optimized process to issue/renew/deploy the cert

This had the effect of making HTTPS accessible to everyone, and is the reason that HTTPS has become the default rather than only being used for a small fraction of websites (e-commerce etc...).

Overall this has been a positive development and has raised the bar against mass-surveillance across the world. However, the downside as mentioned, is that much of the world's infrastructure now relies on this small company. Since the certs are only valid for 3 months, any blockage in that renewal process means rapidly failing services.

[Tijdreiziger]

It would be interesting to see governments or domain registries set up ACME-compatible CAs.

At the moment, it looks like there are options in Norway and Austria as well as the US: https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...

[jonas-w]

Wouldn't this allow them to easily MITM you?

[Tijdreiziger]

A lot of governments already have CAs, so they could MITM you anyway.

For example, the Netherlands government CA: https://cert.pkioverheid.nl/

[tialaramex]

The other answer to your question seemed to me to have guessed wrong what you're concerned about. My guess is that like a lot of non-experts, your thought was "Why do we need this CA role?" and that, fortunately, is something where I can appeal to your intuitions rather than needing some mathematical proof about cryptography you won't understand.

This is about identity. How can we (and everybody else) agree on the identity of something? Is "Chris Pratt" the movie guy we've both heard of, or is it some Belgian guy's friend's brother you met once at a party? The Screen Actors Guild insists its members all have distinct names so you can tell them apart. If your real name is Clint Eastwood and you go into acting, too bad change it or you won't be allowed to work on most stuff with union rules. You don't need a legal change of name (although if you're a serious actor you might decide it's less bother to get one) but you must use a name distinct from those already in use in the industry.

Naturally there can't be some objective "truth" to a name. People may say "She looks like a Deborah" but that's not really how it works - when we find someone in a coma with no ID we don't go "Oh, he looks like a Jim Smith, of 420 Springfield Crescent", we have to put out a public appeal with photos. If I show you a web page it may look like Wikipedia, but I can trivially do that myself, so the real Wikipedia is the one everybody agrees on, and if for some reason we all agreed tomorrow that's not Wikipedia, it wouldn't be.

So, with no objective truth† we have to instead have an authority, and for everybody's convenience we should all trust at least roughly the same authorities, so we're all agreed about who we're talking about

† We can use cryptography to "assign" things names, but these names aren't very satisfactory, that's how Tor's private services work, which is why they have ugly names like facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion -- notice that all those letters are crucial, facebookwkhpilnemxj7asaniu7vnjjxiltxjqhye3mhbshg7kx5tfyd.onion is one letter different and would be a different Tor service not operated by Facebook.

[peoplefromibiza]

> How can we (and everybody else) agree on the identity of something?

we do, I rephrase it, billions of people do it all the time everyday on WhatsApp.

It's called TOFU

The first T means Trust.

Another example: Protonmail, it uses PGP, it works.

The important thing for privacy is the encryption part, not the identity part.

Even more so when we all know that full fledged HTTPS site put TENS OF MEGABYTES of garbage on their web pages to track people.

Identity: I want it confirmed if I'm talking to my bank, but why the bank cannot buy a 10 year certificate it's a mystery to me, I sure hope they'll still be in business in 10 years time from now, at least they should be able to not think about this minutia so often.

[tialaramex]

> why the bank cannot buy a 10 year certificate it's a mystery to me, I sure hope they'll still be in business in 10 years time from now, at least they should be able to not think about this minutia so often.

There's no more reason they should "think" about this than, say, testing fire extinguishers, it's just routine maintenance, it is presumably somebody's job to ensure all the routine maintenance gets done. If you're holding a meeting about the certificates on the web site, rather than knowing that's maintained and monitored properly as part of normal operations, you screwed up.

Now, why does it need maintaining? Why not have them issued for 10 years (so, longer than many employees will work for the bank) ? Well the lifetime of a certificate in the Web PKI is in practice the best possible agility we can achieve for the entire Web PKI, so the longer the maximum lifetime, the slower we're able to fix any problems.

If the bank's new certificate today is valid for 10 years that means if we sunset things which are a terrible idea tomorrow they are still polluting the ecosystem until at least January 2033. A new browser, written by a team who are all in primary school today, might ship in 2033 and yet it's expected to put up with every weird thing we're still allowing, even if it's known to have been a bad idea for about a decade by then.

Currently the rule is 398 days, so if we outlaw something tomorrow, it's no longer a problem by the end of February 2024. More realistically, if we argue about it for a few weeks, and then agree to ban it from May 2023, it's no longer a problem by the second half of 2024.

[peoplefromibiza]

> fire extinguishers

fire extinguishers are for emergencies!

if a fire extinguisher doesn't work, people can die

if an HTTPS cert has expired, there is no risk involved, it can still be used only o. the domain it was issued for.

Anyway in.my country you have to check them every 3 years and someone comes to you, you don't have to remember about it.

> If the bank's new certificate today is valid for 10 year

nothing prevents reissuing new certificates before expiration, if necessary.

[tialaramex]

> nothing prevents reissuing new certificates before expiration, if necessary.

So you want a product advertised with a 10 year lifespan, but sometimes it fails much earlier? I guess I have great news, you can use the existing product this way, although everybody you work with may find you exasperatingly incompetent.

[drewmol]

The CA signing provides different levels of validation. DV (Domain validation) certificates require demonstration of control over the dns record(s) to the CA, ensuring the (IP address) server responding to your request has demonstrated control of the domain name by which you addressed it, to the CA.

Let’s say your local dns is poisoned to resolve to a nefarious server at a specific IP address for ss64.com, that server’s certificate won’t be signed by a CA (unless they also controlled ss64.com’s dns records, in which case there would have be no need to poison your local dns). Your connection to this server can still be encrypted via a certificate, but the CA won’t be providing validation of their identity or affiliation with the real ss64.com.

[ownagefool]

TL;DR

It's just for Identification.

The signature on the public key matches what domain it should resolve, and said public key pairs with a private key that encrypts your data. Assuming you don't a) mishandle the private key, b) the Signatory has a reasonably process to assure that person with the private key should be able to encrypt the domain, and c) all potential trusted Signatories can be trusted, then you can reasonably assume the site you're visiting is legit.

The actual encryption doesn't need identification. Doing so would ensure others can't listen to your conversation, but wouldn't help if the person you think you're talking to isn't actually the right person. This is a realistic problem, because there's nothing in DNS or routing that ensures trust.

[SturgeonsLaw]

> there should be a way to use TLS with a self-signed cert

Well, there is, all (afaik) current browsers have some kind of barely visible "yeah, I know, take me there any way" button buried under a click or two on those cert error screens. The only exception to this that I can recall are servers that use an old version of TLS like 1.0, and in those cases, there is a browser flag that lets them load.

[entropyie]

Sure, what I had in mind was a more user-friendly UX. For example, if I could add something to the certificate subject to say: "This is an obfuscation only cert, not claiming identity or MITM resistance".

Then, the browser would either show the address bar like a HTTP page, or maybe show a notification instead of a block page, saying: "This is the first time you have visited this page. Identity is not verified. Trust identity?"

You can tell I don't do UX for a living ;-)

[iso1631]

For 90% of people there's two UI options

1) a button to let them get where they want to go

2) A button which doesn't let them get where they want to go

[jeroenhd]

> "This is the first time you have visited this page. Identity is not verified. Trust identity?"

Users will click random buttons until the popup disappears. You can watch it happen in real time when you help the elderly with computer issues and don't say anything. Every option from cancel to close to OK is tried as whatever is happening doesn't work. Reading the error message itself is an action of last resort.

There's a good reason you can only bypass certain TLS errors by typing "thisisunsafe" into the error screen in Chrome; people just clicked the ignore button until the problem disappeared and then ran into trouble.

[jrochkind1]

I seem to recall the browsers threatening to start issuing warnings for any http, but I guess it hasn't happened yet.

[bombcar]

Especially since all Let’s Encrypt cares about us a DNS proof-of-domain, it should be possible to negotiate that from the browser itself.

[jrochkind1]

It is probably easier to give a browser a fake DNS result (ie, a MITM attack) than to do the same to the letencrypt authorizers.

Fake DNS result/MITM is one of the things that the SSL cert is supposed to guard against. Possibly the only thing that a domain-validated cert has going for it over an anonymous cert. Allowing a domain cert to be "renegotiated" from the browser would seem to defeat the purpose of having a domain cert at all.