Amazon Adsystem SSL certificate will be distrusted in Chrome M70

; Date: Thu Dec 28 2017

Tags: HTTP Security

Google is pushing the Web towards using HTTPS Everywhere. The browser makers are collectively preparing to DISTRUST PKI certificates issued by Symantec Corporation’s PKI prior to June 1, 2016. It's been determined those certificates had some kind of badness to them, and that Symantec had allowed untrustworthy partners to distribute SSL certificates. To remedy the situation browser makers will shortly begin phasing in a repudiation of these SSL certificates. The plan is resulting in ominous warning messages in browser JavaScript console saying that Chrome M70 will refuse to load affected resources. In this case it will impact advertising assets loaded from Amazon's infrastructure ... eep

The issue is not solely affecting (amazon-adsystem.com) amazon-adsystem.com SSL certificates. It is affecting every service that's using Symantec-issued SSL certificates. In my case I see two affected sites, the aforementioned Amazon Advertising system, and the Adthis service.

The SSL certificate used to load resources from https://s7.addthis.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.
The SSL certificate used to load resources from https://images-na.ssl-images-amazon.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.
The SSL certificate used to load resources from https://aax-us-east.amazon-adsystem.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.

The issue here is a form of the "mixed content warning". That is, when implementing HTTPS support for a website you must ensure that all content loads via HTTPS. This applies to all the asset files, CSS, JavaScript, images, smellovision, and anything else beyond the HTML page. A failure to ensure all content loads via HTTPS results in the mixed content warning. Supposedly stuff loaded via HTTP can be subverted using a man-in-the-middle attack, which could be bad.

In this case, the content is being loaded via HTTPS, but the browser makers have decided to repudiate the particular certificate provider. (Symantec) Webmasters are being given a year or so to fix up their act, and to switch away from the affected Symantec-issued SSL certificates.

We can do that fairly easily for assets loaded from our own server(s). But in this case the assets are loaded from 3rd party services, and we cannot control what those services do.

Do we own Amazon's service? Nope. Nor do we own the Adthis service. We may be using Amazon advertising on our website, and the JavaScript code used by Amazon advertising in turn causes things to be loaded from an Amazon server. As you can see in the messages above, it's an HTTPS URL but the SSL certificate was issued by Symantec.

The messages include a Short URL, which redirects to: (security.googleblog.com) https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html

That page gives a full explanation of what's going on and why the action is being taken.

What's more important is the timeline of actions:

  • October 24, 2017, Chrome began printing the above warnings in the developers console.
  • December 1, 2017, Symantec was supposed to do something useful
  • March 15, 2018 - Chrome 66 goes to Beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016.
  • April 17, 2018 - Chrome 66 goes to Stable
  • September 13, 2018 - Chrome 70 released to Beta, which will remove trust in the old Symantec-rooted Infrastructure.
  • October 23, 2018 - Chrome 70 goes to Stable

In other words - in April 2018, Chrome will start displaying security warnings based on these repudiated Symantec-issued certificates. Then in October 2018 another step will be taken, that will prevent loading assets from affected URL's. Both of these steps can affect readers of our websites.

What can we do? We don't own these 3rd party services. One hopes that those services are being run by folks who are aware of the issues, and who will issue a fix before April 17, 2018 (the first date at which users will be affected).

If those services drop the ball it will be necessary to find alternate services. In the example above - instead of using Addthis, switch to Sharethis (or some other similar service). Or switch to Google Adsense advertising if Amazon hasn't fixed their advertising system by then.

About the Author(s)

(davidherron.com) David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.