Closed Bug 862164 Opened 7 years ago Closed 6 years ago

https://www.nytimes.com/ does not render properly because of mixed content blocking

Categories

(Tech Evangelism Graveyard :: English US, defect, major)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: briansmith, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [mcb-thirdparty-notified][mcb-chrome][mcb-ie])

+++ This bug was initially created as a clone of Bug #861961 +++
+++ This bug was initially created as a clone of Bug #861753 +++

https://nytimes.com/ should render like http://nytimes.com/, but it doesn't because the CSS is loaded from http://css.nyt.com/css/0.1/screen/build/homepage/styles.css

The https:// version of that URL does NOT work because of a certificate error: "The certificate is only valid for the following names: a248.e.akamai.net , *.akamaihd.net , *.akamaihd-staging.net"

There is a LOT of mixed content on this page, including a LOT of other mixed active content, including scripts, at least one *.swf, and more CSS.
Loading 'https://nytimes.com/' in Chrome 25 works properly.  It appears to redirect to 'http://www.nytimes.com'. Looking the network panel in Chrome shows that it sends a 302 redirecting to the http url.
The same thing seems to happen on Firefox.  When I visit https://nytimes.com I get redirected to the http version.  This implies that the https version isn't ready yet, and new york times is directing users to its http version.

Brian, how did you discover this issue?  With HTTPS Everywhere installed?
(In reply to Tanvi Vyas [:tanvi] from comment #2)
> The same thing seems to happen on Firefox.  When I visit https://nytimes.com
> I get redirected to the http version.  This implies that the https version
> isn't ready yet, and new york times is directing users to its http version.
> 
> Brian, how did you discover this issue?  With HTTPS Everywhere installed?

It seems that sometimes https://nytimes.com redirects to http://nytimes.com and sometimes it doesn't. I have seen it go back and forth over the last week.

I don't use the HTTPS Everywhere extension.
(In reply to Brian Smith (:bsmith) from comment #3)
> > Brian, how did you discover this issue?  With HTTPS Everywhere installed?
> 
> I don't use the HTTPS Everywhere extension.

For some reason, my awesomebar chooses https://nytimes.com over http://nytimes.com by default. But, that is probably because I entered in https://nytimes.com a long time ago by hand and it worked fine and I just kept doing it.
https://nytimes.com/ redirects to http://www.nytimes.com/ but https://www.nytimes.com/ doesn't, resulting in a broken page and making this evangelism issue more serious.
Summary: https://nytimes.com/ does not render properly because of mixed content blocking → https://www.nytimes.com/ does not render properly because of mixed content blocking
I'm hitting this too and suspect that the issue is rather prevalent. I don't use HTTPS Everywhere, but my awesomebar defaults to https://www.nytimes.com/ as well. The end effect is that anyone who has their history in this state will have a top US website load with no stylesheet under mixed content blocking.
Severity: normal → major
https://www.nytimes.com is also broken on Chrome.  Can someone check Internet Explorer?

I wonder if they are already aware of the issue.  Does anyone have contacts at nytimes.com?  Of all the sites that have been reported with mixed active content (https://bugzilla.mozilla.org/show_bug.cgi?id=844556), nytimes is the most concerning.
(In reply to Zach Lipton [:zach] from comment #6)
> I'm hitting this too and suspect that the issue is rather prevalent. I don't
> use HTTPS Everywhere, but my awesomebar defaults to https://www.nytimes.com/
> as well.

IMO, this is the most concerning aspect of this. Why is the awesomebar directing us to that broken https:// version of the home page that we've seemingly never been on? We shouldn't be sending people to this broken page from the awesomebar.

Anyway, IIRC, you can track down the nytimes coders by starting your stalking journey at http://open.blogs.nytimes.com/. I actually seem to remember trying to leave a comment in the comment form of one of the guys' blogs but I don't think I got a response.
(In reply to Brian Smith (:bsmith) from comment #8)
> IMO, this is the most concerning aspect of this. Why is the awesomebar
> directing us to that broken https:// version of the home page that we've
> seemingly never been on? We shouldn't be sending people to this broken page
> from the awesomebar.
> 
The issue with the awesome bar is discussed in bug 769994.
I sent the following email to techfeedback@nytimes.com :


Hi,

I am a Security Engineer working at Mozilla.  Recently, we added a new security feature to Firefox called the Mixed Content Blocker.  Chrome and Internet Explorer also have this feature.  While testing, we discovered an issue with nytimes.com.  I will provide some background information, details on the problem, and a description on how to fix the issue.  Hopefully you can forward this email on to your web development or security teams.

Background:
When an HTTPS page contains HTTP resources, the HTTP resources are called "Mixed Content".  For example, if an HTTPS website contains javascript that is sourced from an http:// link, the javascript is Mixed Content.  Chrome 21+, Internet Explorer 9+, and Firefox 23+ will all block the http:// javascript load by default.  This can result in functionality issues on a website and cause the user to think the website is broken.

Problem:
https://www.nytimes.com does not render properly on Firefox 23, Chrome, or Internet Explorer because it contains http:// loads that are blocked by the browsers.  This includes both CSS stylesheets and javascript.  A list of the blocked resources is below [1].

Solution:
It appears that when a user visits "https://nytimes.com" they are redirected to "http://www.nytimes.com".  This may imply that the NY times prefer their users visit the HTTP version of their site for now.  Adding a redirect from "https://www.nytimes.com" to "http://www.nytimes.com" would fix this issue.

Another alternative solution is to replace the HTTP CSS and Javascript loads with HTTPS equivalents.  This would require purchasing an ssl certificate for nyt.com and then updating the "http://" links in the source code to "https://".

Further References:
For further help and guidance, feel free to contact me and/or view the below articles:
https://developer.mozilla.org/en-US/docs/Security/MixedContent
https://developer.mozilla.org/en-US/docs/Security/MixedContent/fix_website_with_mixed_content
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/
https://bugzilla.mozilla.org/show_bug.cgi?id=862164

Thank you very much for your time!

Sincerely,
Tanvi Vyas
Security Engineer, Mozilla


[1] Blocked loading mixed active content "http://css.nyt.com/css/0.1/screen/build/homepage/styles.css" @ https://www.nytimes.com/
Blocked loading mixed active content "http://css.nyt.com/css/0.1/print/styles.css" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/js2/build/sitewide/sitewide.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/js2/build/homepage/top.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/abtest/js/wto/wt_capi.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/abtest/js/wto/nytd_wto_lib.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/abtest/js/hp/bar2.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/js2/build/video/2.0/videofactory.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/js2/build/video/players/extended/1.0/app.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://js.nyt.com/js/app/recommendations/recommendationsModule.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://www.nytimes.com/ads/common/embed3.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://graphics8.nytimes.com/js/app/lib/NYTD/0.0.1/tabset.js" @ https://www.nytimes.com/
Blocked loading mixed active content "http://markets.on.nytimes.com/research/modules/home/home.asp?0.9188775693893395" @ https://www.nytimes.com/:670
Blocked loading mixed active content "http://js.nyt.com/js2/build/homepage/bottom.js" @ https://www.nytimes.com/
Whiteboard: [mcb-thirdparty-notified][mcb-chrome][mcb-ie]
Blocks: 888941
Duplicate of this bug: 888941
(In reply to Tanvi Vyas [:tanvi] from comment #10)
> I sent the following email to techfeedback@nytimes.com :
> 

I haven't heard back.  I just replied to my email to them, but it is the techfeedback@ address.  If anyone has an actual contact at nytimes, that would be helpful.
Tried my contact at nytimes: https://twitter.com/swannodette/status/352233508640534529 .  We'll see if it works.
Reply from help@nytimes.com:

Thank you for contacting us.  We appreciate your comments regarding The New York Times Web site.  We are always looking for ways to improve the site and take all suggestions into consideration.  We have forwarded your comments to our development team.

Your satisfaction is important to us and we thank you for your interest in The New York Times.

Sincerely,

[Name Removed]
Online Customer Care
The New York Times
www.homedelivery.nytimes.com
I'm trying to get some attention to this.
Duplicate of this bug: 906440
WFM. https://www.nytimes.com/ now redirects to http://www.nytimes.com/.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.