Sometimes I care only about my traffic being encrypted, and resent having to jump through hoops to ignore the name mismatch. Sometimes I care only about assurances that the name is correct, and don't care about having the traffic encrypted.
If that's not in your threat model, and you want encryption for another purpose, then I could understand that, but currently, protecting the endpoints against malicious attackers in the middle is the big value of TLS.
Why do you care about encryption without authentication? Without TOFU, PKI or a preshared key what is the value?
> Sometimes I care only about assurances that the name is correct, and don't care about having the traffic encrypted.
So signing?
At least with HTTPS over the local network, it can frustrate attempts to break into it. That said we are sure to call it “https-insecure”.
There are options for this, that needn't cost.
In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build, point whatever domain you like (“real” or just a local-only DNS entry) at your host and sign a cert for that with the internal CA. Generating keys & certs for each workstation can be automated. You could sign a wildcard subdomain and key+cert for each machine or person, .pc101.devteam.internal/.johndoe.devteam.internal, so each user can setup multiple dev/test services on their box without requiring support from the infrastructure team.
Or get a wildcard from LE or similar for some [sub]domain, point *.[sub.]domain to 127.0.0.1 and let everyone have the keys for that. You need to renew every 3 months or less and redistribute the cert, but that isn't massive hardship and can be automated. Also make sure this is only for dev/test though, not internal tooling that might handle read data/controls, or having multiple (potentially many) people with access to the private key is a massive security issue.
Using proper names & certs and not encouraging disabling checks for local dev/test, reduces the risk of code that doesn't do proper verification getting let out into the wild later when someone forgets to switch checks back on.
> In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build
I'd be surprised if this did not cost when done properly. Securing a (even internal) CA is a whole thing that is not trivial.
