Google Warns Webmasters About Insecure HTTP Web Forms (searchengineland.com)
In April Chrome began marking HTTP pages as "not secure" in its address bar if the pages had password or credit card fields. They're about to take the next step. An anonymous reader quotes SearchEngineLand:
Last night, Google sent email notifications via Google Search Console to site owners that have forms on web pages over HTTP... Google said, "Beginning in October 2017, Chrome will show the 'Not secure' warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode."
Google warned in April that "Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we're ready to take the next steps..."
"Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the 'Not secure' warning when users type data into HTTP sites."
Google warned in April that "Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we're ready to take the next steps..."
"Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the 'Not secure' warning when users type data into HTTP sites."
Let's separate authentication of websites from encryption for privacy. Then there's no reason not to encrypt everything.
It's Nazi mania right now. Everyone you disagree with is a Nazi. Nazi's are everywhere!!
BOO!!!
Firefox added a warning a while ago. It's no surprise Google would follow suit.
Chrome is really turning in to a slow, bloated, spyware-ridden Firefox clone.
Required reading for internet skeptics
This seems like overkill to me.
A week ago I would have modded this offtopic. Now I'm just mad you beat me to it.
With way things are going, one can easily foresee so-called hate sites having their SSL certificates revoked; Chrome displaying a warning message / blocking access.
As for encrypting everything, that makes sense from a security standpoint to better prevent the injection of bogus links, malware, etc in transit.
How completely ironic. Google serves ads that infect users and they are lecturing on how to be secure? Please. Give us a break.
My site has a contact page. I'm not going to spend the extra money to get a certificate just so Chrome won't kvetch about my site. I'll put verbage on the site explaining the error message in Chrome and if people don't want to contact me, I can live with that. Worst comes to worst, I can code the site to complain that Chrome isn't supported. I already do that with Internet Exploder.
If there are credit card forms, shouldn't they be reported to the cards (mc/visa/amex/jcb) so they can stop accepting transactions from unsecured (and definintely not PCI DSS compliant) pages.
While your at it, how bout not flagging self signed certs as insecure? You could flag it as identity not validated, but end the end a self signed cert means that the traffic between your browser and the web server has been encrypted.
We could have had an all HTTPS web decades ago if the browser makers didn't pull this BS. Thankfully Lets Encrypt finally released free certs for all fixing this issue.
Calling self signed cert HTTPS sessions insecure is like saying a SSH terminal session is insecure, since probably 99% of SSH terminal sessions are running on self signed certs that were generated when the OS was installed.
Self signed means false sense of security. The HTTP scheme without S means a true sense of insecurity. True sense is better than false sense.
Install device configuration management software on your clients, and deploy the proxy's root certificate through that.
I no longer care what Google has to say, considering that they believe they can censor whatever they want.
I often (lazily) use password fields to input text that is then used only by Javascript internal to a short page. No need for https, but firefox and chrome warn me regardless. And my webhost (1&1) wants to charge like I'm a business for anything more than a single subdomain on SSL.
They flagged my public wiki as falling under the new policy. So someone who posts something on this wiki runs the risk of having their contribution changed by a man-in-the middle. (besides running the risk of someone just going to the wiki and changing their contribution the proper way).
I got this warning from Google about my site. A couple years ago, I got https working using Let's Encrypt. So, you'd think I could switch over 100% to https as Google is pushing me to do. But, what I've found is that there are a few odd browser/devices that don't work. A notable one is the PS3/4 web browser (my site is video-game related, so this is not entirely rare). Sony hasn't updated their root certs to include the one used by Let's Encrypt. So, my https does not work on a PS3 or PS4. Thus, I'd prefer to keep the site indexed with the http version, despite Google's pressure. I do have links up for the secure site and have tried to motivate people to switch (even use HSTS to make the switch sticky). About 28% of my signed-on users still use http. It's their choice.
Self-signed means the man in the middle (MITM) who intercepted the connection is decrypting what the server sends, storing it and/or altering it, and re-encrypting it to send to the client. CA-signed means the same MITM also had to intercept the CA's connection to the DNS when the server operator obtained the certificate, which is a bit harder to do for actors smaller than a nation-state. And it's even harder if the server operator regularly checks Certificate Transparency and/or Convergence.
I don't see how Let's Encrypt, an automated domain-validated CA, is a "racket". DNS is more of a "racket", as people who operate an internally reachable server on a LAN have to buy a domain in order to qualify for a certificate.
Why would that be any less or more secure for the user? Or did they mean to say incognito mode on http site , which is insecure because it's http not because its incognito ?
Https could have been designed to work the same way as ssh, store a fingerprint, if it changes then throw up alarms.
It does work that way. The warning you see when visiting an HTTPS site whose certificate has an unknown issuer, such as a self-signed certificate, is analogous to SSH's warning that no fingerprint is stored for that hostname. A domain-validating CA is just a way to skip that warning. If you think that's a racket, then answer me this: How do you verify that no MITM is altering the fingerprint the first time you connect to an SSH server?
Sites could have stored their current fingerprint as a record in their DNS entry to automate validation
That's called DANE. It's not implemented in browsers because until less than a year ago, DNSSEC keys were 1024-bit RSA, and 1024-bit RSA is too short for current safety margin expectations. In addition, several registrars appear to charge extra for DNSSEC. There is a Chrome extension to run a DANE check on a certificate, but I don't know whether that or a similar Firefox legacy extension will survive the WebExtensions cutover.
Warrior promoting Unjust Society (or is that, Warrior for Unequal Statuses).
Where are we going and why are we in a handbasket?
"Oh, I'm sorry. Snapd won't support that because that might compromise security."
Use the --dangerous flag, or use the SNAPPY_FORCE_CPI_URL root environment variable to switch the machine to a different store. Or what am I missing?
"Chromebooks only support changing the cert store at the user level. It won't work with your federally mandated content filter because we protect our users."
Then perhaps Google should be playing chicken with a national government as a means of showing that said government's communications policy is harmful to its citizens' well-being by weakening security. When Wikipedia played chicken in June 2015, censorship dropped.
It seems like, if anything, the developers don't trust the users
Given how prevalent PEBKAC is, it saves the support department money not to have to trust the users.
A page which was served by unencrypted HTTP but which posts its form data to an https url is secure.
It just doesn't look secure to non-technical users.
Of course if the site then sends the form data back up unencrypted (e.g. after server side value validation fails) that is then insecure, but no one with a brain sends the password value back up anyway.
Where are we going and why are we in a handbasket?
They don't care about your privacy... AT ALL! Or your money or you for that matter. They care about control, and is what this move is about. Forcing those that self host their stuff come out and make themselves known by buying certificates. FU google!