In Encryption Push, Chrome Flags HTTP Sites as 'Not Secure' (zdnet.com)
On Tuesday, Chrome started marking sites that don't use HTTPS as "not secure." From a report: First announced two years ago, Google said it would flag any site that still uses unencrypted HTTP to deliver its content in the latest version of Chrome, out Tuesday. It's part of the company's years-long effort effort to gradually nudge more webmasters and site owners into adopting HTTPS, a secure encryption standard for data in transit. Any site that doesn't load with green padlock or a "secure" message in the browser's address bar will be flagged -- and shamed -- as insecure.
[...] According to nightly data compiled by security experts Troy Hunt and Scott Helme, roughly 100 of the top 500 websites are still serving their pages over unencrypted HTTP -- all of which will today be flagged as "insecure." Many of those sites -- like Baidu, JD.com, and Google.cn -- are Chinese language sites, but many popular Western sites -- including BBC.com, DailyMail.co.uk, and Fedex.com -- are HTTP. Of the top million sites, a little over half do not redirect to HTTPS. Chrome 68 also brings with it Page Lifecycle API, and the Payment Handler API. From a report: The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above. As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.
[...] According to nightly data compiled by security experts Troy Hunt and Scott Helme, roughly 100 of the top 500 websites are still serving their pages over unencrypted HTTP -- all of which will today be flagged as "insecure." Many of those sites -- like Baidu, JD.com, and Google.cn -- are Chinese language sites, but many popular Western sites -- including BBC.com, DailyMail.co.uk, and Fedex.com -- are HTTP. Of the top million sites, a little over half do not redirect to HTTPS. Chrome 68 also brings with it Page Lifecycle API, and the Payment Handler API. From a report: The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above. As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.
All of this is pointless as long as we encourage corp IT firewall admins to completely break https with their MitM proxies that use fake wildcard certs and bogus CAs as part of a GP push.
Some of us remember when the web was for the interchange of ideas and knowledge, not some glorified shopping cart for mouth breathers.
Thanks, Google, for breaking the internet.
Misusing your power (client & server) to push people around and to shape a landscape favoring your business and nothing else. You are finishing the nightmare Microsoft tried to realize.
Assholes.
Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc.
Bbc.com doesn't need encryption. My business site which doesn't take payments or allow user accounts does not need encryption. It's a wall of text and pictures.
Google acting like the entire world needs this is incredibly stupid.
I already have to use Firefox to access firewalls because Google decided that "go to the site anyway goddammit" just means "allow traffic for 2 minutes, and then complain about the certificate again. And again. And again"
Now it's going to scare people for no reason. Screw them
Do you not want any guarantees that your news is unaltered from the source?
I'd be very concerned if any site I used for monetary purposes wasn't using HTTPS. On the other hand, sites providing data services like streaming or news probably don't need to encrypt anything.
Yes!
for 90% of the stuff I browse on the web, I don't need https. I really don't care who sees the cat pictures I look at.
https should be saved for pages that actually need encryption
elf signed certs are fine, but they cause all sorts of issues in Gnome environments and Men in the Middle-earth attacks are possible.
You can't handle the truth.
Now Chrome can do web controlling actions like security extortion. the next step will be making only google approved certificates complete with extortionate prices will be marked as secure. Join the resistance, get one of the xul trio of browsers Waterfox Pale Moon or Basilisk.
Do you not want any guarantees that your news is unaltered from the source?
Nobody is doing that. It's the source itself that is usually subverted.
The entire concept of certificate "authorities" is already fundamentally broken by design. (Kinda obvious, given the "argument from authority" fallacy.)
I can not trust an organization that happens to host a website, but I'm supposed to trust an organization that happens to be a CA? Because the browser maker said so? Whose trustworthiness is not established either, by the way.
If you want at least some trust, you either have to BE the CA (like with my own servers), or meet and get to know the person *personally*. Everything else is just hearsay, and of comparable trustworthiness to whatever you receive when you send out an unencrypted HTTP request to a random unknown domain.
Their metric specifically mentions redirecting. One of the sites that I manage is an antique auto parts store. There is still a large fraction of our customers using Windows 98 era PCs. Due to this, automatic redirects from HTTP to HTTPS are disabled, so they can still browse the catalog and call us on the phone to order. Bots testing this site would notice the lack of redirection. However, modern browsers pass in some new additional headers which mention some HTTPS capabilities, and *IF* these headers are available, automatic redirection happens (since we know the client will be on a browser which supports the proper TLS version)
I'm sure several of these other sites are using a similar approach. I just personally tested FedEx.com, and it is properly redirecting from HTTP to HTTPS in an up-to-date browser. So odds are that these bots testing these sites are not fully supplying all the same headers that browsers do.
The text on duck.com is significantly more informative than I expected.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Hopefully, though, software updates (such as Windows Update, Apple Update, etc...) will remain unencrypted. I run a network that services some remote communities via satellite, and those things are eminently cacheable (we have a WSUS server for our corporate computers).
Before you get your panties in a twist about that being insecure, the way I recall these things working is that the update client fetches SHA256 sums of the update files via HTTPS, and then downloads the files over HTTP. That way, the updates can be cached locally, but the end user can still be assured that they haven't been tampered with.
...si hoc legere nimium eruditionis habes...
Not news, but Comcast has and continues to modify websites.
I hate fat people.
The upshot of this is that users are going to become accustomed to ignore all such warnings and proceed to the site anyway. Rendering even legitimate warnings basically useless.
Comment removed based on user account deletion
Comment removed based on user account deletion
I'm all for encrypting web traffic, but this push for HTTPS-everything is kind of terrifying. It puts us in this dystopian future where we rely on CAs to decide whether or not we can visit a website.
If a couple of CAs decide (or are told) to revoke my cert, there's literally nothing I can do about it. And all of a sudden my website is inaccessible to 90% of browsers, and there's nothing I can do about it.
I would happily support some kind of peer-to-peer encryption scheme (HTTPS with no CA, maybe). But centralizing everything through CA gatekeepers is just asking for a government to butt in.
---- I'll take you in a Hunt deathmatch any day.
The number one reason, from my experience, is that of people see warnings a lot, especially for dumb things, they are quickly trained to ignore warnings. Microsoft learned this lesson with their first attempt at UAC. SELinux had a similar problem for a few years.
For best security, you should alert people to actual security problems, and only problems they can do something about. Reading Wikipedia over http is not a problem.
Also, Bobmorning makes a good point here:
https://tech.slashdot.org/comm...
The security systems that are supposed to rpotect you can't see all the malware being downloaded onto your system, the data being exfiltrated, etc when everything is TLS.
Your mundane page showing cat pics or whatever can be a serious threat if the script-kiddie on the next table can inject whatever javascript he wants into it before you receive it.
Yes, a source can be compromised too, but the ease of mitm http is just amazing. Also, any http security header (csp, hsts, hpkp, etc) or other mitigation techniques are futile if transport can't be trusted.
I suspect most people reading this haven't worked in a SOC, so they won't appreciate how much truth there is in what Bobmorning said.
> There is a delicate balance between having situational awareness of what is going on in the network versus
Exactly. We have systems that can see when a site is trying to do a drive-by malware installation or whatever, lots of ways to protect people in some pretty advanced ways. We can't protect what we can't read, though. So there is a balance. Encrypting everything makes it easier for the bad guys to send bad stuff to and from your machine without getting caught. So the ideal is neither "encrypt nothing" nor "encrypt everything as if it's a state secret". The best ways to protect against various attacks are situation dependent. For reading Wikipedia, unencrypted is probably safer overall. It's also faster - https can't be cached.
Nobody modded it down. It currently has +2 Funny. The poster is just such an overwhelmingly obnoxious troll that all their posts start at -1.
What an absurd comment. Whomever created the browser has 100% access to everything, including your account logins and passwords, both http and https. Google gains no additional advantage.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Comcast has been caught injecting advertisements into HTML documents that Comcast customers view over cleartext HTTP. If BBC doesn't want Comcast performing cross-site scripting on BBC's site, BBC needs to use HTTPS.