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.

Comments

MitM https proxies should be flagged too

[nyet]

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.

Re:MitM https proxies should be flagged too

[Wrath0fb0b]

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.

It's not "breaking" HTTPs, any more that distributed authorized_keys "break" SSH. The owner of Group Policy on a machine has (by definition) the authority to set HTTPs policies, read files, spy on the screen and plant furry porn in your home directory. That's literally what it means to be in group policy.

As I see it, the IT admins should be absolutely transparent with employees that all content touching the machine is subject to being recorded and have clear policies on whose approvals are necessary to go read the logs.

Re: Baked in financial transactions?

[Anonymous Coward]

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!

[Anonymous Coward]

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.

Re:Thanks Google!

[squiggleslash]

I'm failing to see how an unobtrusive warning that the webpage you're looking at wasn't served securely is "breaking the Internet".

Re:Thanks Google!

[Khyber]

The warning isn't fucking unobtrusive, that's the problem.

Any time you do something Google doesnt' like, it makes sure to make a big fucking fuss about it.

And that's going to give people the idea that the age they're trying to visit has been hijacked or otherwise when it has not.

It's going to pretty much result in digital libel and defamation of the site as idiots who don't know better start spreading word that "site x is hacked because Google Said So."

Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.

This is stupid garbage

[Anonymous Coward]

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

Re:This is stupid garbage

[Anonymous Coward]

Bbc.com doesn't need encryption.

You visit bbc.com. The great firewall inserts javascript to DoS attack another website.

You visit bbc.com. You read a simple article about foreign policy. In between you and the BBC, the text of the article has been replaced, changing your knowledge of facts, your opinion, and ultimately your vote.

You visit bbc.com. To preserve your privacy, you use a VPN or Tor. Your HTTP request has a BBC-UID cookie. Anyone snooping the connection can tell which link is yours as opposed to someone else's, and can track when you're there using the internet and which pages you go to.

You visit bbc.com. You're an activist in a country which would like to not have you around. Instead of receiving bbc.com, you receive child porn. It only takes a minute for the police to be signalled and break down your door and confiscate your computer. In court, experts testify that you hid the CP in a clever place (the browser cache). Not only do you go away for life, but you're discredited to the public and the court, police and experts don't have to be in on it.

Explain why it is essential to have bbc.com not be encrypted.

Re:To be honest

[XanC]

Do you not want any guarantees that your news is unaltered from the source?

Why encrypt LOLcats?

[XXongo]

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

Re:Why encrypt LOLcats?

[Anonymous Coward]

Honestly, I want encryption so my ISP *can't* inject adds into the pages. Need has nothing to do with it.

Re:Why encrypt LOLcats?

[willaien]

HTTPS isn't just about encrypting information like bank info - but also about preventing tracking. If all of your websites use HTTPS, your ISP can't snoop on your traffic to sell your data.

Re:celf signed certificates

[roman_mir]

elf signed certs are fine, but they cause all sorts of issues in Gnome environments and Men in the Middle-earth attacks are possible.

Re:To be honest

[flink]

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 problem:ALL HTTPS is insecure and allows MitM

[Anonymous Coward]

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.

Software updates etc...

[Strider-]

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.

Re:To be honest

[KixWooder]

Not news, but Comcast has and continues to modify websites.

Crying Wolf

[nuckfuts]

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

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

HTTPS is centralizing the internet

[SkOink]

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.