I think this goes deeper. Currently, supporting HTTPS means you have to have some kind of internet connection, back-end infrastructure and other running costs.
Even if you use Let's Encrypt and DNS validation, you will have running costs to keep the domain name registered and you will need some way to periodically transfer new certificates to your devices.
Even if you somehow manage to update the device without a permanent internet connection, if someone wants to access the web interface, they will have to use the domain name - and therefore at least need to be connected to an internet DNS server so the domain resolves.
So if, at some point, browsers would completely drop support for HTTP, this would suddenly force any kind of device with a web interface into an IoT-style lifecycle where the device loses functionality once its vendor is not able to support it anymore - even if the vendor would want people to continue using the device and even if there is no technical reason for it.
For a $5 product it may not make sense to have this level of configuration, but for example I believe the FireBrick (a device you might buy to put a small company or district office online) is capable of being configured with your name rather than a generic product DNS name that could go away.
Also, just because a name is in DNS doesn't mean you must use the Internet to resolve the name. In a truly offline system you can just hard code that name resolution and it'll work fine. Nothing about HTTPS cares how resolution was actually done, only the BRs for the Certificate Authorities tell them they mustn't issue for names that aren't actually part of the public DNS hierarchy.
So, the device needn't be on the Internet.
The name must make sense in the Internet DNS hierarchy, but (with a typical commercial CA) needn't actually exist or (with Let's Encrypt, who insist on checking) needn't resolve to anything, let alone an actual machine on the Internet
Yes, you will need to move new certs to a device if you want it to remain publicly trusted as time passes. If that's an unacceptable burden (maybe your device is under the North Pole ice) then you probably didn't want the Web PKI, you need your own PKI for your very special application. Most people want the Web PKI.
However, my scenario was for situations where you don't want to modify the viewing device.
The advantages of web interfaces is that you get a complex GUI for your device without significant overhead on the device and without any requirements on the viewing machine. You can use an arbitrary PC or phone to access it.
If HTTP were to go, that would change: Either you restrict which machine can view the GUI (by requiring a specific resolver and/or CA) or you add the overhead of maintaining and updating the certificates and domains.
An example would be a (non-cloud) security camera or network printer. Those devices typically have a complex web interface for administration and data access - however, they are typically used within a LAN and there is no technical need why they need to access the internet. Indeed, when misconfigured, they can even be vulnerabilities.
As it is, the warning seems to be disabled for localhost/127.0.0.1 (where I only see a 'not secure' if I manually click the ⓘ) but the warning shows as usual if I browse a local IP address over plaintext HTTP.
To make it easier & cleaner in development, it's best to make yourself a Certificate Authority CA and issues local certificates. This makes for no warnings in browsers and ensures a better development experience.
A post from my colleague on how to do it https://reactpaths.com/how-to-get-https-working-in-localhost...
sure. That's what I do on those sites where I absolutely need SSL even during development. But it's still a hassle and, I would argue, an overall security downgrade.
If somehow that CA certificate gets out (commited to github by accident, extracted via malware, etc.), I become MitMable unless I manually check every certificate of every site I visit.
I know that this isn't too likely an attack vector, but if I had to target a developer friend, that's something I'd look into because this has the potential to work across machines whereas traditional malware based solutions would only work on machines I can compromise.
If you have unique CAs per development machine, this would of course be moot, but at that point, you might as well just run with a self-signed cert to begin with and allow the exception once.
A _Private Key_ is the thing that needs to be kept private, in Microsoft Windows it's common to bundle this together with a corresponding Certificate in a single file, often with the filename extension .PFX I assume it's more "convenient" this way, shame about the security.
If you do this a LOT (maybe you're a team of fifty developers at a software company that mostly builds web apps but has a strict policy of not using "real" certificates or wildcards) you should mimic the hierarchy required of "real" public Certificate Authorities:
Mint a "root CA". You'll end up with a certificate and a private key, let's call them root-C and root-P. Every developer (and QA and so on) system needs to trust root-C, you can use Group Policy or similar tools to arrange that.
Use the root CA to issue a sub-CA, the "issuing CA". Write _constraints_ in the certificate used to issue this sub-CA. A constraint is a rule about what things the Subject is an authority about in the opinion of the Issuer. So for example if you set a DNS constraint of just example.com, certs for example.org, or google.com from this Issuing CA don't work. If you later acquire example.org, you can "just" replace the Issuing CA. No updates to employee systems. Think about the Constraints you write, so that they block "mistakes" like MITMing google.com, but not anything you expect to actually need. You can also constrain the types of certs issued. Will you only issue TLS server certs? Then write a constraint saying so.
Now, lock away root-P, a serious CA has it in a special hardware device to protect it, but a USB key in a locked desk drawer is a good first step.
The Issuing CA credentials will probably need to stay live on someone's computer, they're valuable of course, but because of the Constraints they now aren't an unlimited black hole in your security.
But are you telling me that each developer should do this for their personal webpage project just because Chrome might decide to put HTTP-only pages behind a modal dialog?
If you're a bit bigger, so that you're needing to put webpage projects on a separate machine, so maybe QA can try it, or you can run a demo, you can and should set aside one or more chunks of public DNS hierarchy for the test systems, for example a cert for *.test.example.com can allow a number of test systems at Example Inc to do HTTPS. If you're happy to pay a commercial CA they'll mint such a certificate for fair price upon proof you control example.com. If you want to use Let's Encrypt, they'll need you to have records for test.example.com in public DNS to run proof of control automatically. Provisioning the private key and copies of (periodically updated) certificates to the test boxes is not exactly a difficult problem for a working test environment.
Only if you (perhaps out of paranoia) refuse to do that, should you try what I suggested with a private CA hierarchy for web pages.
If you're building something quite different (not TLS, or genuinely not on the Internet, although what the point of things other than the Internet is I'm not sure) then you can and should roll your own PKI, but that's a huge under-taking, you should already have hired at least one person who knows MORE about this than me or you're already in deep trouble.
Chrome wants to move away from the "Secure" wording because people don't understand what it means, for example, they think it means they can trust the site not to misuse their credit card details.
Your information (for example, passwords and credit card numbers) is private when it is sent to this site.
To the layman this means: Chrome says it is safe to enter credentials on this site (and not that it just means that it is hard to eavesdrop on the connection), especially that because this does not say anything about the trustworthiness of the site.
I hope that flipping the switch now will cause enough of the remaining non-https sites to start looking into switching before Chrome feels the need to start adding "more prominent" warnings (for example using a modal dialog).
I agree that, yes, in general, we should all be using HTTPS on the internet, but non-secured HTTP still makes sense for example during development or for home routers and printers where traffic encryption is less important compared to the initial UX (my parents could probably set up a home router on their own if it's using non-encrypted HTTP but they would be totally unable to proceed if it's using a self-signed cert).