From July, Chrome will name and shame insecure HTTP websites 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
See: https://www.ghacks.net/2018/01/20/how-to-block-the-chrome-software-reporter-tool-software_reporter_tool-exe/
C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\SwReporter\VERSION\software_reporter_tool.exe
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.
If HTTPS is mandated for all pages, that kind of attack just cannot happen. HTTPS doesn't just protect data that you send, it guarantees that the data (i.e. the HTML/Javascripts) that you've received is what was intended by the site owner.
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.
Yesterday I completed a guide on how to implement let's encrypt, including simple openssl.cnf files and using something other than certbot. Apache on *nix systems. Hopefully useful to some of you.
@Alain,
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
