Slashdot Mirror
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.
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.
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.
That or if Google supported CERT records in DNS properly. Then sites could publish their own issuing certs and, as long as they use DNSSEC, you could at least verify that the certificates belong to the entity that owns the domain (which is all that's needed for most purposes).
We could also work on getting some of the registrars to actually support DNSSEC.... it's been "coming soon" to my registrar for several years now and I'm considering switching just because of it.
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.
end the end a self signed cert means that the traffic between your browser and the web server has been encrypted.
And decrypted and reencrypted by a man in the middle.
Install device configuration management software on your clients, and deploy the proxy's root certificate through that.
SSH doesn't use certificates as far as I know.
Everything I write is lies, read between the lines.
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.
By "hate", you mean non-SJW.
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.
It isn't a certificate, it is a public key that you accept. Again, ssh doesn't use certificates.
Everything I write is lies, read between the lines.
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.
again, my sshd doesn't use certificates, only public/private key pairs:
# ls
moduli ssh_host_ecdsa_key ssh_host_rsa_key sshd_config~
ssh_config ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub
ssh_host_dsa_key ssh_host_ed25519_key sshd_config
ssh_host_dsa_key.pub ssh_host_ed25519_key.pub sshd_config.new
# grep -i cer *
#
Everything I write is lies, read between the lines.
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?