Doesn't the post say they'll fall back to http if the https attempt fails?
> For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails.
The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower).
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.
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.
More than a bit. For HTTPS-only sites, the site could serve a stub HTTP endpoint on port 80 that redirects to HTTPS. The redirect causes maybe some milliseconds to a few seconds (worst case) of latency.
HTTP-only on the other hand can't do a HTTPS stub as easily (as the primary reason you'd want HTTP-only is probably that you don't want/can't deal with the certificate management - if you can set up a redirect from HTTPS to HTTP, you might as well go full HTTPS)
So the only option for HTTP-only is to not open port 443 at all - meaning Chrome has to wait out the 30 seconds (!) network timeout until it can try the fallback. So pure-HTTP sites would become a lot more unpleasant to use.
(A site might be able to cut this short by actively refusing the TCP handshake and sending an RST packet - or by opening and immediately closing the connection. I don't know how Chrome would react to this. In any case, that's likely not what HTTP-only sites in the wild are doing, so they'll need to update their software - at which point, they might just as well spend the effort to switch to HTTPS)
Timeouts occur when you incorrectly configure your firewall to drop packets instead of rejecting.
The recommended practise I've heard everywhere is that an ICMP REJECT provides no opportunities for an attacker they wouldn't have with 10 minutes extra time (modern port scanners can be set aggressive enough that REJECT or DROP doesn't matter if they have a known open port they can obtain an ACCEPT timeline from).
I constantly have issues with this address bar hiding the scheme and even the www.
One issue is when I quickly want to select some parameters or delete parts of the url in order to "up" one level.
What drives me absolutely insane is their inconsitent autocomplete functionality. Sometimes I end up at googling "examp" instead of navigating www.example.com, which was a page I already had visited and therefore showed up as the domain which was autocompleted inside the address bar. Sometimes pressing enter autofills the address, sometimes it googles the halfway typed domain. If I tab the halfway typed domain, it always completes it and an enter will navigate to it.
There is some strange difference in entering a domain and performing a search, something feels off. I can't exactly tell what it is, but sometimes I end up with submissions which I did not intend.
Also something with pressing the down-key in order to select the topmost entry, the one which gets selected with tab, it just gets skipped when I use the down-key.
Another thing is if I want to query "Raspberry Pi disable wifi" or something which begins with "Raspberry Pi", that I then get suggested the URL raspberry.org, a domain which I have often visited, and am forced to type through the entire word Raspberry in order for the URL-functionality to get aborted and have it switch over to googling mode. Maybe there is a keyboard shortcut or something which would help me out, but it simply isn't intuitive.
(Who reads those menu entries anyway, at least fully?)
Also, did you know 80% of facts are made up? XD
The claim you made was “chrome is hurting a large minority of users and they should make a browser in a more fair way” but this changes when you change your made up numbers to something more like “chrome is hurting a tiny minority of users with weird use-cases like me and I don’t like it”
FWIW, it feels like the problem is more that your use-cases don’t fit into web PKI, and I agree with you. But I don’t think harming the security of web browsing for the vast majority is the solution to those problems.
Ah, but now you’re measuring a different thing than the GP, users vs scenarios!
I’d hazard a guess that at least 30% of users need to log into a router at some point or another. I hope it’s more than 30%, because everyone else is likely paying ridiculous prices for a crappy router from their ISP.
E.g. your router/DHCP controller/AD box gives an IoT device a DHCP ip and maybe a DNS address, and additionally it will provision a cert+key to that device by some standard protocol (keeping this secure might be impossible?). Router has an internal CA cert+key to do this.
Your PC then (handwavy) "knows" to retrieve the CA cert of your router by some standard protocol (dhcp extension?), and "knows" to trust it for devices on the router's subnet.
Is a scheme like this possible?
According to the post this shouldn't be an issue.
https://medium.com/collaborne-engineering/self-signed-certif...
Having to install custom-made Root CAs into all and every client device doesn't sound to me like an ideal solution...
Actually, that's one solution Apple could consider: if a user has enabled Developer Mode on a given iOS device, allow the trust model to be broken with an "Are you sure you know what you're doing?" button instead of a silent failure.
The goal isn’t to make a 100% foolproof system (because you can’t), and needing to flip a switch called “developer mode”, which preferably also displays a warning message, should make it clear something is wrong.
...I think this whole discussion is kind of missing the point though. Developers are not the only people who need to log in to routers.
It is true, that in recent versions of iOS (in the past five years or so), you have to install the certificate in Safari, then go to Settings->General->About, scroll all the way down, and manually trust the certificate (to ensure you really know what you're doing by enabling it). And iOS doesn't make this known anywhere outside of that special menu three levels deep, I suppose to not confuse people who had an attacker install a cert on their phone somehow.
But for a user, iOS Safari (not Safari for MacOS) doesn't show any certificate warning that the user can accept, like other browsers. In fact, it just fails absolutely silently. You'd have to connect it to a Mac and open up the developer tools on the desktop's Safari, to see the errors that are being printed on the JS console.
Otherwise, you'd just be left wondering why it just doesn't work like all the other browsers.
Chrome pops a warning, but (with a few exceptions) doesn't let you just navigate through it (there's a secret key sequence you can type to override it, but it's both purposefully undocumented and periodically rotated to make it something that you can only know if you have the chops to read the source code or consult the relevant developers' forums).
Do you have a source on that? I would guess more like 99.99%.
It's even less funny when you realize that the class of devices that gets effectively crippled includes the wast majority of all IIoT devices. Including ones that run manufacturing and power generation. Yeah, your precious personal website is now secure from MITM attacks. The factory that made your car, however, uses critical infrastructure controlled by web interfaces with no encryption at all. Congrats.
If via Multicast DNS, what stops you from publishing TLSA records as well?
70% of the scenarios impact 99.99% of users as well as the project's intended scenario.
> being limited to the same host.
Yes, that's the point, of course.
What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices)
What about offline tutorials? I'd like to provide a ZIP with a plain HTML tutorial that shows how WebRTC works, but users cannot serve it up in their LAN and access through their laptops or phones, because WebRTC requires HTTPS. What's even worse, a self-signed cert doesn't work either. iOS Safari does NOT work with self-signed certs at all!
It's maddening, obstacles everywhere once you don't walk the path "they" (industry leaders, focused on mainstream online web services) want you to follow.
EDIT: There are some (lots [0]) of features that require a secure context, i.e. a web page served through HTTPS. So the defaults to HTTP are not a silver bullet, and the security exceptions for localhost are not really that useful either, being limited to the same host.
[0]: https://developer.mozilla.org/en-US/docs/Web/Security/Secure...