Or just further training users to ignore security warnings? Plus, who actually checks for the "Secure" icon when they're not entering personal information into a form?
Three years ago, Google's search engine began favoring in its results websites that use encrypted HTTPS connections. Sites that secure their content get a boost over websites that used plain-old boring insecure HTTP. In a "carrot and stick" model, that's the carrot: rewarding security with greater search visibility. Later …
Yesterday I came back, my notebook running with full fan speed, was hot. Good that I had ProcessExplorer running. It was a new EXE that scanned all my files and tried to upload the log file (incl. filenames and running processes) to Google server! The software_reporter_tool.exe gets silently installed and runs only in idle, when you are not using Windows 7/8/10. And even if you delete the EXE, it gets re-installed the next day by Chrome update process.
@TheRegister: please write an article, we need a public outcry, so that Google stops this spyware
On a lot of forums people are complaining for almost two years now, as the process is very sneaky it's hard to spot it being active. Yet it runs on all Windows-PCs that have Chrome installed.
What is worse is that Google employees provide false information on their Google Group forums to downplay the functionality, how to deactivate it (no, there is no entry in the software control panel!).
The only way to get rid of it, is to delete the files, but keep the "\SwReporter" folder, but remove all permissions, effectively lock out everyone, so that even one himself cannot open it anymore with Explorer.
I urge everyone to install a Chromium Windows build, or Brave, Vivaldi, etc.
I had something similar on Linux with chrome. It was running one of their test suits which put my fan in turbo, kept doing it for 2 days on and off. I couldn't work out what it was actually doing other than two new chrome processes started and took all processor resources.
I understand (although totally disagree and hate) that today's climate is all about giving up all details of everything you do on a PC but there's never a button that says "don't do it" or "don't do it now I want my computer back!". It's all very secretive.
Pre SNI, you could only have been 1 HTTPS cert per IP address*. So a pretty trivial reverse DNS lookup will would have revealed the site you were visiting**. HTTPS won't stop a MitM knowing that you went to en.wikipedia.org. But they cannot see the specific pages within Wikipedia that you visited.
*It was technically possible to do multiple subdomains with a wildcard (eg *.theregister.co.uk could multi tennant forums and www and whatever else on the same IP address). It was technically possible to do a SAN cert (eg, Google could have got a single certificate for google.com, YouTube.com, gmail.com etc.) But for the most part, if you wanted HTTPS (pre SNI), you had to buy a dedicated IP address for it.
**TOR or a VPN through a trustworthy provider are your friends to that end.
Man-in-the-middle malware attacks.
ISPs have been caught modifying and injecting ads.
You can't do that on HTTPS. Not without flagging a bunch of warnings.
However, it does remove/destroy all the capacity of centralised caching (e.g. in workplaces) for simple things like images and static pages. But I can't say that's a bad part of the trade-off... pretty much the cacheability of websites has plummeted in recent years because of video, CDN, advertising, etc. anyway.
There's no reason NOT to encrypt. And a hundred TO encrypt.
Now if we could just worry about end-to-end encryption for all email, then we might actually be living in the 21st century a bit.
> ISPs have been caught modifying and injecting ads.
MitM could even inject coin miners.
> However, it does remove/destroy all the capacity of centralised caching (e.g. in workplaces)
It removes it for byod stuff, but company issue kit can have a MitM trusted CA to sign your fake certs.
As a trivial example of why it's a GOOD thing to encrypt all pages, even ones that don't have a form on them to collect your data, consider this: You have a bunch of pages that just have some content on them, no forms. They DO have a link to your login page (which itself uses HTTPS). Without HTTPS, it's very simple for requests for those content-only pages to be intercepted and altered before they're sent on to the customer - so the customer receives all the same content with a login link which looks the same but which now actually sends the user to a malicious site which harvests his/her login details.
as to the no reason not to encrypt argument - I'd beg to differ. Encryption costs money, which will have come some from somewhere. With the pervasive advertising/profiling/re-selling of user data business model that will in all likely hood mean the even further dissemination of the user’s data and a corresponding tightening of their/our filter-bubble.
As Lee D said.
"I'm not sure I see the value in creating a bunch more aggregate traffic and load for essentially trivial traffic". Without SSL, that "trivial traffic" could be modified - that might not be a risk to you, as the content provider, but it is a risk to your users who could as Lee D said end up infected. You may not see your content as valuable, but I guarantee your users see their computer/data as valuable.
As techies living in the server room, it's easy to forget your users need protecting too.
Amazon.com works fine with HTTP-only (except for its login page), at least for more than two decades (1995-2017). HTTP is completely fine for most websites. And if you are doing e-commerce, or banking, such sites have HTTPS support anyway. This is a war or HTTP for no good reason. The reason is with HTTPS you traffic is unique and you can be traced very easily.
And of course Email is still sent in plain text, and there is no lobbing for S/MIME and GPG at all - because the browser cartel (who also is the email cartel) doesn't care about data privacy at all, it's all about spying the end user and tracking them. And HTTPS is a good vehicle to create an ad-monopoly on top of it. And don't forget about LAN and IoT where HTTP is irreplaceable, realistically. Getting users to install self-signed SSL certs on their LAN devices looks shady and simply doesn't work.
And the best joke is their Let's Encrypt thingy, guess what you allow them root access to your server by running their code on your server, and they can slip you in another cert or read your data, and make your server more vulnerable (Heartbleed anyone - only HTTPS servers were insecure) And to push Let's Encrypt, they stop trusting Symantec, GeoTrust, RapidSSL and Thawte certificats! And show a big "NOT SECURE" warning for all HTTP websites. WTF, this is so evil! Screw the browser cartel (Goo, Moz, M$) for destroying the web.
Just because the connection between the website and the browser is or isn't encrypted, doesn't automatically imply that the website is also (in)secure to use. I know this sounds obvious but you have to keep in mind that plenty of IT illiterates will also be using this system, and I for one can easily imagine situations where some might even ignore possible risks because "the website is secure" while it's not.
It's plain out nonsense that a website which doesn't ask for any user input would be more secure if it uses HTTPS vs. HTTP.
Sure, you can get free certificates. But if your hosting provider doesn't support SSL you have no other option but to get a more expensive subscription. If you actually care for this nonsense of course.
>> It's plain out nonsense that a website which doesn't ask for any user input would be more secure if it uses HTTPS vs. HTTP.
No it's not nonsense at all. A website that doesn't use HTTPS can have its pages, as displayed in the browser, modified in any way by simple MITM efforts. That's trivial to do and therefore it is most certainly less secure than if it used HTTP.
(NOTE: That's not to say it IS secure if it uses HTTPS just that it's more secure as there are less attack vectors).
Google's actions are Suspect.
Its also much more secure if your website only connects to one server. Instead of sidelining info to Google Facebook and friends.
What are the chances of chrome saying that a site that only visits _one_ secure destination is more secure than one riddled with ads?
Google likes ssl because it inhibits competition from seeing referer headers which they already know.
Chrome sends everything you type even local network hosts off to the chocolate factory. No way that is secure. They don't care about security or privacy unless its _also_ an earner for them.
Anything that makes the web more expensive for server owners is good for Google.
"Chrome sends everything you type even local network hosts off to the chocolate factory. No way that is secure. They don't care about security or privacy unless its _also_ an earner for them."
Just for fun, why not have your site browser sniff - and if it detects Chrome, display some appropriate text about the slurp-tastic nature of Google.
The world of software as we know it is a mess because widely used applications like browsers are targeted at the needs of a relatively narrow group of users. These users, the ones that use the Web for information and entertainment, are the most numerous but realistically all they do is browse websites, consume multimedia streams and get served advertisements. Since the 'push' needed to monetize these sites demands that users run scripts there's a problem with ensuring the integrity of what's being pushed at you. The result is an ever narrowing of browser capabilities even as the things get bulkier and bulkier (and consume more and more resources).
This leaves other users like SCADA systems out in the cold. These users can't rely on upgrading their software every five minutes to fix vulnerabilities and get whatever the latest and greatest is, they need consistent, reliable, code that's stable for years. Communication between the units is a bit simplistic, but then it doesn't need to be anything more (you certainly can't rely on the whole IoT house of cards -- its too slow and too unreliable -- too many potential points of failure). Bottom line is its a real pain when Chrome or whatever won't open a webpage because it doesn't think its secure (well, it isn't, but realistically its none of its business -- sure, its useful to protect unsophisticated users from themselves but everyone else should be keeping things hygenic).
This post has been deleted by its author
> SSL certificates are free
The best joke is the browser cartel's Let's Encrypt campaign. It's "FREE". Yeah "free" as Facebook. You are the product. You allow them root access to your server by running their code on your server, and they can slip you in another cert or read your data, and make your server more vulnerable (Heartbleed anyone - only HTTPS servers were insecure).
And to push Let's Encrypt, they stop trusting Symantec, GeoTrust, RapidSSL and Thawte certificats! And show a big "NOT SECURE" warning for all HTTP websites. WTF, this is so evil!
Screw the browser cartel (Goo, Moz, M$) for destroying the web.
"... You allow them root access to your server by running their code on your server"
You don't have to allow any of their code on your server. You can manually get the certs or use a number of other scripts to auto-renew.
They highlight hundreds of different scripts and clients you can use on their website: https://letsencrypt.org/docs/client-options/
Their recommended one Certbot is maintained by the EFF and has a link in it's main menu to the source code https://github.com/certbot/certbot. It doesn't get much more transparent than that.
Iit is optional whether you use Let's Encrypt or you choose to pay for another provider.
So it might be worth checking the facts before posting?
I'd argue that if you're running Certbot as root, you're definitely doing it wrong. There's nothing about it that needs root access. It needs write access to the certificate files and possibly your web directories (depending on your validation method), but that doesn't have to involve system root access.
"...SSL certificates are free and take little effort to install, add virtually no load or problems for your website"
This is exactly the problem. Google are training naive users into thinking that just because the site is HTTPS, somehow it's bona fide. When any old idiot can get a cert for free, that's a very dangerous assumption.
You seem to be one of the few that looked into certbot and I see you have your own reasons not to run it on your systems. I don't like the idea that the default install can update the script and replace it with something else running as root. While there has been care to make that harder to MITM, anyone who can get a bad cert installed in the system CA chain might be able to p0wn the server. It is a big enough target surface not to have thousands of people working on that right now.
On my virtual host servers, I use dehydrated which is a simple shell program running as its own user.
I trust all CAs equally but see them as a necessary evil. As soon as I find one that doesn't have a spook or former spook high up in their management, I might trust one more than the others.
The cheapest non-free certificates come at $5 per year and domain. I don't consider paying $15 and handling some certificates every 3 years much of a problem.
So yeah, certificates are practically free.
(V ohl ng uggcf://purncffyfrphevgl.pbz/ rira gubhtu gur anzr erzvaqf zr bs Ubarfg Npuzrq :-)
True, but it's not just Google making this call. More and more web tech is TLS only. HTTP2 mostly is. (The spec supports unencrypted connections, but hardly anyone implements it.) Web workers are. The writing is on the wall, the HTTP specs are not going to support plaintext at the same level of functionality as TLS, going forward.
You're told to stay on one side of the road. You're told to maintain a pecking order when it comes to crossing streets (both to maintain order). You're told to keep your rubbish under control (reduces fire risk and discourages scavengers).
Now you're told to keep your sites under wraps so they can't be exploited.
No, I don't think it's all that different, honestly.
The biggest problem I have with this is the term "secure".
Yes, we know what it means but too many "normal" people think it means safe. Even the TV ad over xmas with the robot toy saying "look for the green padlock" made the same mistake - "secure" means nothing in regards to identity. My personal site has the "green padlock" and "secure" in the URL bar simply because I use CloudFlare's DNS - it proves nothing about the ownership of the site or whether it's "safe."
There really needs to be a better term used than "secure". "Private" perhaps?
And who checks to see that the list of trusted CAs used by the browser is actually a list they agree with?
It's all very well having a green locked padlock symbol, but all it tells the typical user is that one of a list of organisations they've never heard of say that the site being accessed is who they say they are. Malware can be delivered down encrypted connections too, and while Lets Encrypt is a commendable effort, it doesn't actually solve the problem of being sure who you (or your software) can trust.
Securely delivered malware will be coming to a browser near you, soon, if it hasn't already arrived.
This is actually my only criticism of the effort. If the lack of SSL on a site is enough to have it labelled as insecure by the browser, then you could argue that certs that are only signed by the big CAs should be labelled as such, too.
I gave up on considering them "trusted" a few years back.
I do some work for small website owners who have trivial content, no user interaction and relatively low traffic. Even my less than technical clients have said "wheres the green padlock" when looking a dev version.
Adding an SSL cert from letsencrypt is easy enough and of course does not fix all the problems, but it does make a good start.
I am more suspicious about Google's motives. Sometimes google seem very altruistic but i am still suspicious. I thank Apple for killing flash, but that is not to say i trust them as far as i could throw them!
Where as any site where you enter personal information or login needs to be SSL secured, It is not needed for all websites. I visit some retro computing sites that remain on http to be compatible with old browsers on original hardware that don't support SSL/TLS and it will be annoying if Chrome makes me jump through hoops every time i want to visit them from my laptop. If i can't switch this off in Chrome I will be moving to another browser.
A simple encryption certificate provides nothing that resembles "security". Fine, somebody can't snoop on your connection to my site, but what proves my site is legit, isn't harmful, isn't illegal? Oh, yeah, that's right - NOTHING.
Furthermore, the increasing prevalence of public WiFi access points that intentionally block HTTPS until you accept their certificate (for anti piracy, no doubt), leaving the user with two choices: don't use any HTTPS sites while connected to that AP, or piss away any pretence of security.
Furthermore2 (the sequel), my site is pretty much static pages assembled with some php and a comment form that has no requirement for the user to leave anything that resembles a real name. There's nothing whatsoever that demands secrecy, security, or any of this hoo-hah. If Google wishes to flag it as insecure, maybe they could begin by defining clearly what the benefit of the padlock is - because for the huge majority of sites, it seems to me that the padlock just means "your connection to this site is scrambled", nothing more.
I think the idea is more to prevent ISPs from doing ad injection, public access points from snooping your data, coin miner injection, etc. It's not all about protecting credit card numbers.
I haven't seen a public WiFi hotspot that required me to add a security certificate yet. That certainly sounds shady. I have been to ones that required me to try to access an HTTP site before I could get to their sign-on page. The sooner this kind of broken sign-on process goes away the better, and if wider use of HTTPS accelerates it, great.
" haven't seen a public WiFi hotspot that required me to add a security certificate yet."
KFC Laval (France) when trying to access Google on an iPad. I understood what this was implying. I wonder how many other people just accepted the prompt without realising what it meant?
Just because 81% of the top 100 sites have SSL, doesn't mean that follows for the remainder. There is a very long tail of websites out of the top 5000, or 10000 that are never going to get SSL that are now going to be penalized.
Lets Encrypt on windows is still slightly messy. Going through various load balancers are messy.
Very few customers not doing SSL today find even the little effort to do SSL to be worth the costs (money wise or technical wise).
This is definitely going to train normal users that it is "normal" to see the warnings and to ignore them.
..now all our tiny charity has to do is triple our hosting costs (we get a huge discount because were a charity on the 2nd from bottom basic plan)
We collect no information, and there is no way imputing text on our site, it merely a informational site.
I'm sure Google will kindly pick up these costs for us.
Let's back away from the good vs bad aspect for a few moments and have a look at the bigger picture.
By this action, a significant number of organisations are left in a position where they have to either comply or risk losing business and/or audience. And the entity forcing this choice upon them is not an international council, a standards body or regulating agency - it's a corporation, answerable to it's shareholders alone.
Of course, with the current state of frenzy about cyber crime etc., people are going to buy into this. But in a similar manner, people are buying into AMP - "because it's faster". The danger here is that little by little, people will become increasing more accepting of Google's dictating how the web should work - which is exactly what Google want in the long term.
There isn't a technical reason for them to label sites as insecure simply because they aren't encrypted.
Certificates cause a lot of issues and extra administration for small scale web owners. This is an opinion of Google, and a static site that just serves HTTP should not be labelled as insecure.
Boo on you Google.
I take it you prefer Telnet over Secure Shell as well, and you prefer postcards to envelopes?
I take it you are typing this from your Tempest screened bunker on a machine with a verified CPU and no IME or closed source BIOS.
Security depends on the threat model NOT ticking boxes
Well, the threat model is rapidly becoming "ANY unencrypted connection is prone to tampering. China does it, Verizon does it, expect more to follow, and DON'T expect them to go away."
Under such a threat model, the best move would be to abandon unencrypted connections altogether before one of them gets hijacked and used to either pwn you, tag you (think supercookies, they don't require scripting), or otherwise exploit you (think inline e-Coin miners).
Does it even necessarily have to be a valid HTTP page? In my experience anything with a DNS entry is usually good enough for the sign-in hijack.
These days most OS's I use will automatically detect that hijacking is happening, and pop up a window with the sign-in page, anyway. I only rarely have to trigger them manually. We really need a better system for this, though.
Sadly this affects the ranking of sites which do not sell anything, or advertise anything and usually not for profit. Yes they are out there and worthy. often academic. I hate the bullying tactics of Google. But heck they only want to list and rank sites which make them MONEY!!
But its still a free world and lots of other good (now better!) browsers out there.
I was thinking the same thing. I thought the idea was to return the most relevant results for the query the user has entered, but that's obviously not what Google's thinking. If the info I want is on an unencrypted site that has no mobile version, I want that site to still be shown prominently in the search results because of its relevance, not downgraded for reasons irrelevant to its information content.
It underscores what we already knew about Google, though... the people doing the search are not the customers. They have no problem fudging the results and harming the efforts of the user to find what he's looking for if it benefits their real customers, the advertisers. The goal is not to deliver the best, most relevant results to the user; it is to deliver the most users to the advertiser. Google gained prominence and market share by delivering more relevant results than their competitors, but now that they have such dominance, it isn't necessary for them to keep worrying about little things like finding what the person searching asked for. Why do that when you make more money delivering fake results paid for by your advertising partners?
The internet already consume colossal amounts of energy. Adding encryption where it is not needed, does not help. We can argue about what is needed in terms of encryption and the threat models will clearly vary a great deal, but all-HTTPS-all-the-time is not a zero-cost option.
Biting the hand that feeds IT © 1998–2021