It should just label HTTP pages as "not secure", full stop. Because they aren't secure. Or at least, any page with a form. Never mind if it's a password field or not.
The majority of the big sites that people use (Google, GMail, Youtube, Facebook, Reddit, NYT, WaPo, etc.) are already being served using HTTPS. I think if a couple of HTTP sites an average user still browses start showing these warnings they will notice them. And what matters, the owners of those websites will notice them and will ask their "IT guy" hey "why our website is marked as insecure? I want a green lock like Gmail has".
Their IT guy?? There are gazillions of people like me who have a blog, or some small project that has a small audience of tens to just a few thousand users. All these people now have to fork for SSL, or have to move everything to a different shared hosting that supports Let's Encrypt.
Your shared hosting service doesn't need to support Let's Encrypt, it just needs to allow you to upload a certificate. You can use https://gethttpsforfree.com/ to generate it.
The renewal is the same, follow the steps and you get a new cert. Keep the Account key and the CSR, so it's just a matter of copy-pasting. If they charge an installation fee again, you're probably better off paying for cert that lasts longer (not from Let's Encrypt) - you can get one that lasts three years for $15. Or just switch hosting providers :)
Right now, you can just put Cloudfront in between. It's free, and takes maybe 5 minutes to sign up and adjust your DNS entries.
Of course relying on a provider that might cancel the free plan at any time is not ideal, but worst case you just have to revert your DNS and it's done.
I assume you mean Cloudflare and not Cloudfront. While you could use Cloudfront, AFAIK there's no free option. (Aside from the usage you get as part of the AWS free but that is time-limited.)
It is, but it might work for your app, too – js/css/image caching at CF nodes helps a lot. Moreover, you can disable their cache/cdn features and use it only for SSL.
They even have multiple modes, the "Flexible" one works even with no changes at your server at all. It obviously makes the CF<->server transfer insecure, but your users would still get a "green lock", if that's what you're after.
It would freak a significant proportion of the community out who fail to distinguish what is a web page and what is their computer. They would honestly think that their computer is not secure and their local files/photos would be at risk. After the initial panic and speaking to their "friend who is good with computers" that they will just ignore it forever.
The far better approach is to aggressively warn at users at the point where they are trying to do something secure over an insecure connection. Personally I would be adding UI elements next to HTML forms saying "Do not enter your password here".
That will happen eventually; both Firefox and Chrome have already taken some steps in that direction. But it has to happen as a gradual transition, with plenty of time for people to switch to HTTPS in response.
This would be really nice. Tools like google analytics (if they aren't already) should probably show "Secure visits" and "insecure visits", and they should get even more attention.
They aren't secure, but neither is HTTPS, it is only more secure. HTTPS leaks the actual name of the site you are accessing as well as your IP; HTTP leaks the content you are seeing too. Tor would be more secure, because it leaks neither.
^ 100% agree. I think just marking HTTP pages with password fields as Not Secure would make HTTP pages without passwords fields appear to be secure. This is obviously not the case---they are just as insecure because you are sending your session cookie which is equivalent to your password---so all pages should be marked Not Secure.
Plenty of websites think they only have to secure app.example.com, while www.example.com can be left uncovered even though it serves www.example.com/login, because /login POSTs to the app. subdomain, and the session cookie is only set by and for the app. subdomain.
From a naive perspective, all requests passing private information are protected in such a scenario. But, of course, since the www. subdomain is uncovered, it can be MITMed and replaced with a phishing site. (A.K.A. a "spear-phishing" attack.)
This change somewhat fixes that scenario: the developer can no longer keep the /login route on the insecure www. subdomain; they'll have to serve that page securely (either by making www. secure, or, more likely—because it's lazier—just moving /login to the app. subdomain.)
Even though www. can still be MITMed to replace it with a phishing subdomain, that subdomain can no longer serve a login form itself. It would have to link to a "real" phishing FQDN (one the attacker controls enough to get a TLS cert for), at which point that domain can just be found and blacklisted by the browser vendors.
In a sense, it forces the attacker into the open, where the attacker themselves can be caught/blocked, rather than simply their attack being caught/blocked. (In other words, it forces MITM attackers into a situation more akin to current botnet malware-writers, where they must put up C&C infrastructure which can be traced back to them.)
Of course, this isn't nearly as good as just securing the www. subdomain; and it will force much more work (likely, doing said securing) on those who want to embed a login form directly on their www. subdomain's landing page. But, in the interim while we work on universalizing TLS, it will drastically decrease the value of spear-phishing attacks, just as spam filters drastically decrease the value of unsolicited bulk email ad campaigns.
> because you are sending your session cookie which is equivalent to your password
This is extremely different for most users that don't use password managers and/or unique passwords per site. As if your password is leaked. Maybe all your other sites are now leaked(with same pass) . The same can't be said of cookies.
