Chrome 82 to Start Warning and Blocking "Mixed Content Downloads"

[engine]

Google has said Chrome 82 will start blocking "mixed content downloads" to protect users from insecure files being downloaded from HTTPS sites.
In other words, on an HTTPS site, non-HTTPS downloads will be blocked with V82, due April, 2020.
It's going to be a gradual rollout, starting with a console warning in V81, with warning over .exe downloads in V82, and blocking from V84. Android and iOS users will be delayed by one release as, it says, the mobile OS has better native protection.




[security.googleblog.com...]

[graeme_p]

So if you have an https only site you cannot link to a pdf on an http site?

Not loading elements of the current page from http urls is reasonable. Breaking http links is over the top and breaks stuff that you cannot fix.

[engine]

So if you have an https only site you cannot link to a pdf on an http site?

You can link, but those using Chrome with the versions in the chart above will receive notifications, and then, eventually, it'll be blocked as the versions progress.

Other browsers are available, but, of course, Chrome has the lions share of the market, and i'd assume Microsoft's clone will follow the same pattern.

[graeme_p]

That is what I meant. The end result is that links to, for example, a PDF that is only available over http will not work in Chrome based browsers. Too much breakage.

[engine]

Too much breakage.

Yes, and not what users want, even though they are going to get it.

It really means we are going to have to have secure sites everywhere, like it or not. :(

[lammert]

It really means we are going to have to have secure sites everywhere, like it or not. :(

Yes, that seems the goal. They left out Chrome 87 in this graph but I wouldn't be surprised when in that version or a few versions later, linking from https sites to HTML pages on non-encrypted sites will be blocked, effectively splitting the internet between an accessible encrypted part and an isolated part without encryption.

[aristotle]

Well this is hard for me to understand. My sites are still http. Google's search results pages are https. So does it mean that pages on my sites and other http sites will be excluded from google's search results for people using chrome browsers but not for other browsers.

[lammert]

No not yet, at least. The current roadmap is only for direct download links from https to http, not for regular links. But given Google's push to a fully encrypted web, it is difficult to say where their crusade against http will stop.

[aristotle]

lammert -- Thanks for your reply. That's what I thought, but wasn't completely sure, since the word "download" is sometimes used when talking about html pages.

Another question: PDF files and video files often appear in google's search results. What if they're on http sites? Will they still be included in the search results?

Also, will the affected "direct download links" still be visible in the chrome browser view of a page, but not clickable?

I'm still not sure how all of this will work.

[mcneely]

What if they're on http sites? Will they still be included in the search results?

... of course they will

We now have a thing called Open SSL -- Google pulls from the open ssl across the board unless you specifically request that Google doesn't.

OpenSSL is a software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites.

[en.wikipedia.org...]

If you have PDF's, Video's, or any other files being served over a so-called HTTP connection, you can force SSL via your .htaccess writes in order to deliver everything you have over a secure connection.

You can force an HTTPS connection on your website by adding these rules in your website's .htaccess file:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

[siteground.com...]


Furthermore ... If you are trying to link to a PDF with a link HTTP on another domain that you don't have access to or otherwise control directly, simply change the link to HTTPS and the requested URI will pull from the SSL side of that particular domain ... (works 99% of the time)



**not quite sure what happened here with this post, but I'm seeing two of the same -- lets keep this one and delete the other then, shall we?**

[edited by: mcneely at 7:56 pm (utc) on Feb 9, 2020]

[mcneely]

What if they're on http sites? Will they still be included in the search results?

... of course they will

We now have a thing called Open SSL -- Google pulls from the open ssl across the board unless you specifically request that Google doesn't.

OpenSSL is a software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites.

[en.wikipedia.org...]

If you have PDF's, Video's, or any other files being served over a so-called HTTP connection, you can force SSL via your .htaccess writes in order to deliver everything you have over a secure connection.

You can force an HTTPS connection on your website by adding these rules in your website's .htaccess file:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ [%{HTTP_HOST}%{REQUEST_URI}...] [L,R=301]

[siteground.com...]

[lammert]

@mcneely: Then you are not serving over http anymore :) In your example code you also forget the issue that you have to get and maintain certificates for the encrypted connection. It is more work than pasting some code in the .htaccess file.

And of course, the webserver (in your example Apache) has to be instructed to listen to encrypted connections and serve the appropriate web pages and files.

[mcneely]

It is more work than pasting some code in the .htaccess file.

@lammert -- Actually ... it isn't.

If you're hosting on a server that has implemented open ssl, all you have to do is force ssl through your .htaccess and you're done.

If you've instructed the server to listen for the secure connection, then you can write HTTP for days, and the server will still deliver HTTPS

As an aside, if you were to run a full on ecommerce solution for instance, and wanted to serve your cart pages on your own domain, then you would go dedicated, purchase a cert with your brand/company name, and go on from that point. Trouble is here that most don't do that ... the majority are hosting shared and write HTTP ... it's at this point that open ssl serves it's most useful purpose.

[edited by: mcneely at 8:23 pm (utc) on Feb 9, 2020]

[lammert]

Without certificates, webservers won't deliver an encrypted connection and without changes in the base configuration, no encrypted requests to port 443 will be answered. The amount of work and technical knowledge needed is one of the reasons that still a large portion of the web is served over http without encryption. You may try to add your example code to one of your sites and report back here the results.

[mcneely]

Without certificates, webservers won't deliver an encrypted connection

You're absolutely right in this regard --- If your host doesn't serve an encrypted connection, then it might be best to get a new host that does.

I've got 3 of my own (static) sites that are written with forced ssl via .htaccess and and all 3 deliver HTTPS regardless of whether I write HTTP or not

If you're running Apache, and have a licensed cPanel ... the awstats show both HTTP and HTTPS connection logs ...

[motorhaven]

McNeely,

That .htaccess change doesn't make the link HTTPS. The browser still sees at HTTP link the HTML. Its not until **after** it makes a non-secure HTTP connection that .htaccess redirects to HTTPS.

In Apache, if you want to change the actual link to HTTPS in the HTML so the browser never makes an HTTP connection on the same site mod_substitute can accomplish this by rewriting the HTML before it goes out to the browser.

[aristotle]

It looks to me like https would be a lot simpler and easier to implement if they hadn't added a requirement for certificates. I don't know why certificates are needed for most sites anyway. Maybe one of the purposes in requiring them is to extract money from webmasters.

Anyway this thread is supposed to be about google and its chrome browser.

[Dimitri]

I don't know why certificates are needed for most sites anyway.

The "certificate" is what provides the public encryption key, how do you run https without a public encryption key? The certificate also authenticates the pair domain name / key, which prevents session hijacking. Even if a site doesn't carries sensitive information, you don't want the session to be hijacked by someone else.

Maybe one of the purposes in requiring them is to extract money from webmasters.

Anyone can have free certificates for any use even commercial. And the process of renewing is automated most of time now.

[graeme_p]

@Dimitri, it could have worked the way ssh does: get the key on first connection. That plus some system for checking the same cert is being served to different IPs (there is/was a firefox extension that does that) would not be much less secure than give free certificates to anyone who can show they control the domain (even briefly) - and if its secure enough for managing sites, it ought to be secure enough for accessing them.

[graeme_p]

Another question: PDF files and video files often appear in google's search results. What if they're on http sites? Will they still be included in the search results?

Unless they include some exception for links from search results, then you will not be able to view them.

i suspect Google will remove PDFs and other non HTTP files from the search results, probably followed by all http links (even HTML), followed by removal of http support from Chrome.

Google is determined to force us all to use https for everything,

[Dimitri]

it could have worked the way ssh does

Indeed, but it would have needed a total change of the HTTP protocol, or the creation of a unified protocol to transmit data over the Internet. If this is not something achieved right at the beginning of times, then it's too hard later, to unify it. So we have to built over existing protocol , to slightly modify them progressively, to avoid breaking everything.

Still I don't think that it would be easier to set up than actual TLS, from a web publisher point of view.

[JAB Creations]

graeme_p, just do what I do: tell people to stop using Chrome if they want a working browser.

I'm fairly neutral on the topic of http versus https. If you have an authentication form or have to process any sensitive information then you absolutely need it. Mozilla started warning people about non-encrypted pages with authentication forms and that was appropriate and sufficient.

Let's Encrypt is easy and once it's setup (the web host should be able to easily support it and if they don't get a new web host) it automatically takes care of itself. Whenever I add a new client if I really need to I can force-update (without code) in the control panel and the invalid certificate messages (because it doesn't check literally every five seconds) goes away. No dedicated IP, no code, bare minimal effort, etc.

I use Waterfox and if I didn't I'd have quintupled the amount of clicking to achieve what I've accomplished all of these years. There is no way in hell I'd use Chrome and I test the Blink engine last as I'm against monopolies and market cornering because when that happens you get people who are over-zealous in control of things that they shouldn't be. The only reason why Chrome is "popular" is because it's been automatically installed by every OEM, motherboard utility and anti-virus by default and normal people don't read anything on installers.

John

[graeme_p]

@dimitri, I do not get that. https is just http over TLS. We could have had http over something else instead, right?

@JAB Creations. Yes, its easy to add https and all my sites and clients sites do, but I still want to be able to link to sites that use http without the links breaking for most users.

When the average user seems Chrome say a link on your site is insecure, they will not think "Chrome is broken", they will think "this site is insecure".

If other browsers do not follow then we could mark links "will not work in Chrome" I suppose.

[JAB Creations]

@graeme_p You need to tell them that Chrome (and it's countless clones) are broken then. If people don't then everyone will think the website is broken. You only need some people to realize this and help them realize they shouldn't be using Chrome.

John

[lucy24]

All right, then. Let’s all bring out our old “Best viewed in Netscape 4.0” tags and see how that works.

[Mark_A]

Oh, Doh, now I understand, it is going to block them if your https site calls them from a non https source.
Glad I realised that .. it was starting to look very stupid - but it was just me that misunderstood!

[graeme_p]

@JAB Creations.

Waterfox has just been bought by System1, an ad tech company that also now owns start page. Not sure whether the privacy implications worry you, but worth noting.

[mcneely]

Let’s all bring out our old “Best viewed in Netscape 4.0” tags and see how that works.

... precisely

[csdude55]

But, but... when I look at my console, I have several warnings on every page that Adsense is the one trying to load an insecure image:

Mixed Content: The page at 'https://www.example.com/' was loaded over HTTPS, but requested an insecure image 'http://l1.yimg.com/foo/bar'. This content should also be served over HTTPS.

[awsoo]

This will definitely make a negative hit on file hosting sites. Also the warn can easily be bypassed by simply visiting your downloads tab but what about block?