If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?
The trajectory is pretty clear, the long term plan is to phase out HTTP completely. And I'm not against it, but I need a solution for LAN devices, and it doesn't exist at the moment because the big web actors do everything in the cloud these days and they don't care about this use case.
Also, it completely cuts out "legacy" devices, basically anything more than 5 years old.
The Web is once again splitting into AOLized mainstream and "indie underground" that you have to make an effort to access.
So, to summarize: one more way for the browser maker to control what the user can and cannot access without jumping through hoops.
That 'third party' is one of the recognized 'certificate authorities'.
But the OPs point is by going https, you don't have a choice, you have to pay the certificate tax.
I.e *.int.mycorp.com, but not www.mybank.com
Browsers don’t let me do that, it’s either app or nothing. X509 name constraints aren’t great either and don’t give me, the browser operator, the power.
If you need https on the public internet you need a trusted cert.
I don't think they would even know the option exists.
I can recommend the docker image made by linuxserver in particular [0]. Makes Https a (tax free) breeze.
Want a NAS box for sharing family files/photos or some other IoT device at home? Just set yourself up some other device to run the docker image, get your self a certificate from LetsEncrypt and then... install it on the NAS box? How does that happen?
I think this state of affairs is nuts. With the exception of Firefox, because web browsers have an inordinate number of security issues to contend with.
Issues like this exist at all layers of the stack, so anything touching the internet needs regular security patches.
edit: a word
According to the proposal[0], leaf certificates are prohibited from being signed with a validity window of more than 397 days by a CA/B[1] compliant Certificate authority. This is very VERY different from the cert not being valid. It means that a CA could absolutely make you a certificate that violated these rules. If a CA signed a certificate with a longer window, they would risk having their root CA removed from the CA/B trust store which would make their root certificate pretty much worthless.
To validate this, you can look at the CA certificates that Google has[2] that are set to expire in 2036 (scroll down to "Download CA certificates" and expand the "Root CAs" section) several of which have been issued since that CA/B governance change.
As of right now, as far as I know, Chrome will continue to trust certificates that are signed with a larger window. I've not heard anything about browsers enforcing validity windows or anything like that, but would be delighted to find out the ways that I'm wrong if you can point me to a link.
Further, your home made root certificate will almost certainly not be accepted by CA/B into their trust store (and it sounds like you wouldn't want that) which means you're not bound by their governance. Feel free to issue yourself a certificate that lasts 1000 years and certifies that you're made out of marshmallows or whatever you want. As long as you install the public part of the CA into your devices it'll work great and your phone/laptop/whatever will be 100% sure you're made out of puffed sugar.
I guess I have to disclose that I'm an xoogler who worked on certificate issuance infrastructure and that this is my opinion, that my opinons are bad and I should feel bad :zoidberg:.
[0] https://github.com/cabforum/servercert/pull/138/commits/2b06... [1] https://en.wikipedia.org/wiki/CA/Browser_Forum [2] https://pki.goog/repository/
1. Overhead: I have 5 devices that I own 3 of my wife and a smart TV. Setting all this us takes a lot of time, even if it worked fine.
2. What about visitors to my home, that I want to give access? They need the cert as well together with lengthy instructions on how to install it.
3. How do I even install certs on an iPhone?
4. Firefox uses it's own Certificate Database -- for each profile. So I'll have to install certs on the system AND on the host (for e.g. Chrome to find it).
5. All these steps need to be repeated every year (90 days?!) depending on the cert expiration period.
Eventually I just gave up on this. It's not practical. There needs to be a better solution.
But, #3 How do I even install certs on an iPhone
AFAIK (though I've never done it) you use a configuration profile
https://developer.apple.com/documentation/devicemanagement/c...
https://support.apple.com/guide/deployment-reference-ios/cer...
I found the steps described in https://github.com/FiloSottile/mkcert reasonable to follow. It describes an iOS workflow too.
It is a hassle and as far as I could see it requires resetting the device and I’m not sure I can restore my backup over it and retain both.
It ought to be a practical to do (A) without doing (B), but due to a variety of deep human and technical problems, it isn't.
WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one.
The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.