Slashdot Mirror
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.
Everyone writes about google chrome 68 released today but so far google didn't release 68 version. Just checked official google servers for google chrome (linux version). Stable is still 67.
Some of us remember when the web was for the interchange of ideas and knowledge, not some glorified shopping cart for mouth breathers.
For years I have been commenting on the way that browsers treat self signed certificates, it was always ridiculous and inconsistent. Sites with self signed certs were treated as if they were hacked by definition while HTTP traffic was not marked as insecure at all. At least at this point there will be some consistency to the way that HTTP and celf signed certificates are treated.
You can't handle the truth.
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
They're not right, either. It's security through cargo culting.
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
I have to wonder if we lockup all websites as viewable only via SSL - does that limit access to anything (historical) ? Alright - time to through away the crap, we can't keep everything.
Why is bbc.com insecure because it uses HTTP? I understand why mybank.com would be insecure. I'm worried well lose something valuable when Chrome et al block (some day in the future) all of HTTP.
Besides - it's only a matter of time before hackers move to SSL attacks. When the low hanging HTTP fruit is all gone, SSL looks very appetizing.
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.
Yes, I would like guarantees that google itself can't alter any content it sees fit to. This push is only so Google can control the ad space better, it gives them complete control over ads, as they can now see all of your HTTPS content, not just their own domain connections. HTTP is fine for non-input web pages, you can argue until the cows come home about intercepting raw HTTP and altering it all you want, because corporations MITM HTTPS anyway, so it would just as easy to do the same thing. Assuming the NSA is involved, I imagine they keys or permissions to keys, decryption would now be possible on a global scale, at least with self-signed certs this isn't possible unless they can obtain the keys. I for one will not bend to Google demands, I will warn the users flat out that the Chrome browser is no longer supported on any of my pages that do not require input.
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.
Yes, Google is protective of their ad revenue, https = no ability for ISPs to provide targeted ads without encouraging websites to incorporate their own web tracking scripts or promoting their own search engines.
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
This kind of silliness wasn't what the web was designed for. The web was designed for the free dissemination of free information. Encryption and security are bolted-on hacks that not only don't work very well, but aren't at all in keeping with the original intent of the Web (or the whole Net, for that matter).
I don't see any reason most web sites need to be encrypted.
I don't respond to AC's.
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.
internal apps / IPMI's don't need certs so why push this?
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
SSL does more than simply encrypt traffic. The biggest benefit of SSL for static web sites or information-only websites is that you can verify that you are connected to the right source. Some people mentioned content tampering and man-in-the-middle attacks, but what about a good old fashioned DNS cache poisoning? With SSL, you're not as susceptible to that type of attack.
Comment removed based on user account deletion
Comment removed based on user account deletion
How about Chrome finally taking my word for it when I tell it I trust a particular cert even if it isn't officially signed by some entity I have never heard of.
Meanwhile, if it's so important, why do they make it a pain in the ass for me to examine the cert used by a site? Shouldn't it be in the menu that drops down when I click on the lock icon?
For that matter, why isn't it easy for me to tell Chrome that I do NOT trust a given cert no matter who signed it or that I don't trust a particular CA to sign off on water being wet?
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.
BTW you made a very good point in this other post, though I don't think most people have the background knowledge to fully appreciate your point.
https://tech.slashdot.org/comm...
> They had to divest themselves of the CA business because they prove themselves repeatedly to be not trustworth
Symnatec couldn't be trusted, therefore they couldn't have a CA business. That seems to indicate that untrustworthy companies can't be CAs (for long).
Exactly! eg. USENET:
alt.barny.die.die.die
A dingo ate my sig...
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.
... you can argue until the cows come home about intercepting raw HTTP and altering it all you want, because corporations MITM HTTPS anyway, so it would just as easy to do the same thing.
Corporations can do that on devices they control because they have the necessary administrative access to install their own root certificates. Your local coffee shop or residential ISP can't MitM their customers' HTTPS traffic so easily, whereas the practice of tampering with pages served over HTTP is depressingly commonplace. This is far from theoretical; major ISPs have been caught red-handed injecting scripts and other content into web pages as well as splicing unique user IDs into HTTP headers for tracking purposes.
Short of banning HTTP from the web entirely, I would at least propose to restrict pages served over HTTP from any form of interactivity. No scripts, no plugins, no forms, no "responsive" CSS, limited media formats—no audio or video, just still images in a few well-vetted formats with ironclad decoders. Anything else is too risky to entrust to unauthenticated content. I'd also add a big warning banner above the page saying that the (human-readable) content of the page may have been tampered with and cannot be trusted.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Well if it's the type of site that doesn't need to be encrypted for some reason then it's probably not a big issue that it says it's not secure.
I would at least propose to restrict pages served over HTTP from any form of interactivity. No scripts, no plugins, no forms, no "responsive" CSS, limited media formats—no audio or video
Under your suggestion, with what certificate on what domain should the operator of a private video server on a home LAN run HTTPS? Public CAs don't sign certificates for RFC 1918 private IP addresses or for names within non-public TLDs (such as .local used by mDNS). Some users have suggested using dynamic DNS, but in order to qualify for a certificate from Let's Encrypt, a subdomain needs a TXT record, and the domain it's under needs a Public Suffix List entry. Many dynamic DNS providers don't support those.
It's about making sure that only registered publishers put material on the internet.
I don't see what practical problem that causes for publishers on the Internet, seeing as Let's Encrypt allows anybody who owns a domain name to register as a publisher without charge. Or are you anticipating tighter control of domain names in the first place?
W3C maintains a spec called Secure Contexts, which encourages web browsers to completely disable certain sensitive JavaScript features within HTML documents served over a cleartext HTTP connection. Only HTTPS and http://localhost/ are allowed to use Service Workers, Geolocation, Payment Request, Presentation, and several other web platform APIs.
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.
Sure Google does, if we lock HTTP up Google gains a sizeable advantage. Anyone who is not part of the Google and friends can no longer inject ads into the page. While google can.
Encrypting the material in transit doesn't make any less freely disseminated or the information less free.
It prevents caching. Say a school in sub-Saharan Africa has only a 128 kbps, harshly metered connection for all its computers to use. With cleartext HTTP, if all the students visit the same encyclopedia page, a Polipo caching proxy inside the school can retrieve it once and serve it to 25 students in a classroom. But with HTTPS, the proxy can only handle the CONNECT verb to tunnel the connection to the origin server, causing transfer of 25 times as much data compared to the case with an intermediate cache.
That is a complete strawman. Nobody is "locking up http" or anything of the sort. They are merely accurately indicating that http connections are not secure connections.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
That has little, even nothing, to do with HTTPS. "Altered from the source" is occurring in such volume at the news agencies themselves that HTTP insertion is not even a significant issue.
It's business sites, where manipulation of order forms and prices can cause fraudulent orders, that man-in-the-middle abuse is the much larger risk.
Your concern may have some merit.
Just be aware of the trade-off. Remember the $100 million hack yesterday, where the same company got hit twice in eight months, from phishing attacks? Corp sec could have prevented those if they had visibility into what pages the employees were loading. They could have seen the employees entering their ldap credentials into corporateHR.ru and prevented it. Our SOC catches a LOT of that stuff.
Also catches and blocks a lot of malware, crypto-locker style ransomware, etc.
So you have to decide which is worse - crypto-locker and the bad guys having your ldap credentials, or your fear of the NSA seeing you reading Wikipedia. I don't think either answer is always right.
Because we're now teaching the mantra of "encryption makes you secure", and people will swallow it. Unfortunately, it's not true. It is absolutely possible that you connect to hxtps://onlinebanking.bankofmurrica.com, log in and be surprised that suddenly your money is gone. Because encryption only means that traffic is secure between you and the target, and a certificate only says that the other side is who they claim to be.
What a certificate cannot ensure is that you're really connected to who you think you're connected to. So the next step, or even the step before, should be to teach people to read the fucking URL they communicate with instead of just going "oh browser says 'secure' so it's all right, let me just enter all my passwords".
But where's the money for Google in that?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
You are aware that certificates have very little to do with encryption and are mostly about proving that you're actually talking with who you want to talk to, yes?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The broswser does TLS, so system access doesn't give you access to monitor it. Not using safe APIs. An attacker with root could dig into your RAM or whatever, but that's not a safe approach.
How do you go to the grocery store? Surely you don't believe that unless you personally milked the cow, you can't know that it's milk and of comparable trustworthiness to any white liquid you find in a random container, right? When people say that milk is inspected by the (fallible) FDA/USDA, do you scoff at their "argument from authority"? I mean, at some point in your life you must have had to accept that there are imperfect systems that nevertheless work reasonably well and that have means for self-correcting errors when they do happen. The vast majority of milk sold in the US is milk, and it's reasonable to trust the milk from a reputable grocery store even if you don't personally know who milked it.
I mean, there's plenty of legitimate criticism and improvements to be made about the state of CAs. It ain't perfect, but trust-nihilism isn't even close to a reasonable alternative.
Say you consider the CA nor the self-signed website owner equally trustworthy/untrustworthy. You're still much better off trusting a dozen CAs than a thousand website owners. Browser-trusted CAs allow you to risk your trust on as few entities as possible. You'll still get burned sometimes, but at least you'll be more likely to know who to blame.
This space intentionally left blank
I think you're providing a nice counter example there. Symantec's actions as untrustworthy resulted in them directly losing their business. Same with some of the other vendors we had.
Ultimately exposure to users was limited, certificate revocations were issued, and the guilty parties punished. This is very much a system working as intended in order to maintain trust.
That's not to say you should blindly trust them, but given they actually have something to lose and standards which they need to uphold along with an auditable chain of trust, they get a hell of a lot more trust than random parties.
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.
Yes and here's why: Browser makers don't work in a vacuum. Differences in certificate trust are easily checked on installed instances so you can see if one browser is acting nefariously vs the others. Along with that there are many very open browsers out there who very publicly discuss CAs (see Mozilla).
By extension those various browsers have power over the CA and they have demonstrated repeatedly to execute that power in order to hold the CAs to a reasonable standard. See Symantec, WoSign, or even state run CAs like CNNIC as examples of this system working in practice.
The result is trust through fear of retaliation, or rather as it typically goes, trust through fear of your entire business being given the death sentence. CAs have a lot to lose by breaching the trust of users and their actions in doing so are very easily traced thanks to the very public nature of their work.
You may not trust any random organisation, but you certainly have plenty of reasons to place more trust in a CA to ensure your channel is encrypted and the target organisation is who they say they are. ... Assuming you're not on a corporate computer that is.
Do you not want any guarantees that your news is unaltered from the source?
Is it even relevant? Was it ever relevant? I meant wasn't it ever relevant?
Fuck Putin. I didn't say that. I said make love to Putin. Fake news!
The whole point of HTTP and HTML is that absolutely anyone can implement and run a server or a browser. Otherwise we could have gone with webpages a interlinked Word documents served by Exchange servers. This brings us much closer to sucky closed design. I can't implement https server as a shell script and maintaining keys requires time and money. And simply hosting a webpage requires coding on client and server rather than just dropping a text file somewhere. We can't control what corporations and sheeple who are their customers do, but it's time to resurrect open alternatives. Just like WWW itself was an alternative to Compuserve and AOL. With any luck, we can also bring back intelligent independent content as an alternative to Fox News and CNN.
I have some local machines that have NO connection to the rest of the world. They are HTTPS, but having am official cerificate is not really possible as far asI know, because they can not be verified like my others do that you canb reach from the outside.
It is a sfucking 192.168.x.y address. Stop saying it isn't safe, ya dolt.
Don't fight for your country, if your country does not fight for you.
If a CA inappropriately signs a leaf cert, they will be booted from the big browsers.
This is not conjectural, multiple CAs have been ejected.
How about if Google then forks over the ever increasing cost of certificates/SSL for sites?
Many websites are hosted where only the host can install certificates. This significantly increases costs.
And then, HTTPS breaks and a new need for security arises!
Isn't unregulated life in a capitalistic world grand?!
Perhaps the take-away here is to buy SSL certificate company stocks before this faux bubble breaks!
Self-importance and self-indulgence is the root of ALL evil.
Forcing a website that serves only public content and requires no user input it's absurd!
Why spend the resources of encryption (well put by @RichardStallin) in something that needs none as it's already public information.
The only point I see in Google doing this is that they're concerned about sharing the user navigation history with others since forcing https doesn't affect Google Analytics but may affect other services who get their stats based on packet inspection.