Firefox now blocks non-secure content from WebLearn: WebLearn pages may need to be edited

A recent change to Firefox v23  browser behaviour may have a significant impact on WebLearn users.

Firefox v23 will now block Mixed Active Content by default.  This makes it more secure. It will  not display non-secure (http) content within the WebLearn frameset.

It is possible that users will report WebLearn pages as being ”broken’ and unfortunately, if those pages do contain non-secure content,  it may be necessary for WebLearn pages to be updated by their owners. This could be a fairly sizable task and ideally needs to be done before the start of term.

The benefit to carrying out this work will be in making your WebLearn  areas more secure because they will be much less susceptible to ‘man-in-the-browser’ attacks. (Such attacks can occur when an non-secure piece of content (eg, web page, embedded video or iframe) becomes compromised and is used to launch JavaScript which can steal session cookies or other sensitive data from the surrounding web page.)

Internet Explorer has been warning users about Mixed Content for a number of years now, you may have seen a message along the lines of “This site contains both secure and non-secure content …” ; Firefox v23 goes one stage further, it doesn’t actually display a warning and the resultant page is simply displayed without the non-secure items. There is however a way of telling that this has happened, you should be able to see a small security warning shield to the left of the site address in the browsers address bar.

grey-shield

Clicking on the shield will display the following dialogue

grey-shield-dialogue

The WebLearn team are looking at making changes behind the scenes which will address some of these issues but the scope of these fixes will be limited and intervention by site owners and maintainers will still be necessary.

Where may non-secure active content be located?

Non-secure content is likely to be blocked in a number of scenarios. We will enumerate them here and explain how to combat these insecurities later.

  • embedded YouTube videos that do not use a secure (https) URL
  • links to non-secure (http) external web sites that open inside the WebLearn frameset, ie, in the main content area
  • links to http://beta.weblearn.ox.ac.uk/ (or http://weblearn.ox.ac.uk/) that open inside the WebLearn frameset, ie, in the main content area
  • site Home pages that display a non-secure external web page, for example, a departmental home page
  • Oxitems RSS feed displays that use output_newsfeed.js
  • Other RSS feeds that either use non-secure JavaScript URLs or do not force links to open in new windows or tabs
  • Web Content links to external websites that do not open in a pop-up window
  • Web Content links that do open in a pop-up window but only for site participants with the maintain and contribute roles. Students (ie, access users) will be unaffected.
  • Syllabus tool items which employ a redirect to a non-secure web page
  • Non-secure Facebook plugins
  • Non-secure 3rd-prty Twitter display widgets
  • WYSIWYG HTML pop up help

You can get a report on insecure content by using Firefox’s Web Developer functionality, press Ctrl-Shift-K then reload your page. The console will show the URL of any blocked content.

webdev

Non-secure passive content

Firefox classifies some content as ‘passive’. At the moment, passive content is not blocked but it will be soon so it makes sense to address such page elements now.

  • display of images that are not stored on a secure domain
  • embedded HTML5 audio and video elements that are not stored on a secure domain

What is the WebLearn Team doing to help?

The central WebLearn team will make modifications to the WebLearn code-base so that it will dynamically alter certain pages as they are loaded in the browser – this will only work for pages stored in Resources (as long as they have been authored from within WebLearn) or text placed in the Home tool ‘Description’ box, however, this is not an ideal solution. We would strongly recommend that pages are modified as per the guidelines given below.

Any changes that will be made are outlined in the appropriate section below in red. Version 2.8-ox7.1 of WebLearn release on 12 September 2013 will include these changes.

We will also be making changes to the Web Content tool to force links to non-secure sites to open in a pop-up window for site participants with the ‘Access’ role (but not for other roles).

All other tools such as Assignments, Announcements, Forums, Polls, Schedule, Sign-up, Surveys, Syllabus and Tests will not be post-processed and must have their content modified by hand.

Please note that it is still necessary for pages with mixed content to be revised. The reason for this is that students will still get warnings about content being blocked even though WebLearn is able to post-process these pages so that much of the content becomes accessible; these warnings are generated before WebLearn has chance to correct the problems. Nothing can be done about this.

Changes you must make to ensure content is not blocked

Embedded YouTube videos

Embed code needs to be changed to use the https protocol (instead of http). For example,

<embed height="344" 
       src="https://www.youtube.com/v/r8isc3Gulvg&amp;hl=en&amp;fs=1" 
       type="application/x-shockwave-flash" 
       width="425"></embed>

Or you may want to replace your old embed snippet with code in the new protocol agnostic format

<iframe width="420" height="315" 
        src="//www.youtube.com/embed/r8isc3Gulvg" 
        frameborder="0" 
        allowfullscreen></iframe>

WebLearn will be modified to dynamically re-write insecure You Tube URLs for pages stored in Resources or in the Home Tool. This will mean that there should not be a problem displaying You Tube videos in these 2 cases.

Links to non-secure external web sites that open inside the WebLearn frameset

Such links should be forced to open in a new tab or window. For example

<a href="http://www.bbc.co.uk/" target="_blank">

WebLearn will be modified to dynamically re-write hyperlinks where the target is an insecure URLs so that, when click, the resultant page will open in a new tab or window. This will only be done for pages authored in WebLearn (using the WYSIWYG editor) and stored in Resources or in the Home Tool. This will mean that there should not be a problem with such links in these 2 cases.

Links to non-secure external web sites that open in the current WebLearn window

If you have a link to an external site that attempts to re-use the current WebLearn window such as:

<a href="http://www.bbc.co.uk/news" target="_top">BBC News</a>

this will not work in Firefox due to bug in the current release. It should be fixed in the next Firefox release (due for release on 17 September) but until then the only option is to change the link it to change it to have a  target="_blank" instead.

Links to http://beta.weblearn.ox.ac.uk/ that open inside the WebLearn frameset

Such links should be rewritten. Consider this original link

<a href="http://beta.weblearn.ox.ac.uk/portal/hierarchy/a/b"> ...

This should be changed to

<a href="https://weblearn.ox.ac.uk/portal/hierarchy/a/b" 
   target="_blank"> ...

i.e. the target=”_blank” attribute should be added.

WebLearn will be modified to dynamically re-write URLs in the above format for pages stored in Resources or in the Home Tool. This will mean that there should not be a problem in these 2 cases.

Site Home pages that display a non-secure external web page

The simple solution is to not display the non-secure page. To do this, visit the Home tool click on Options

dept-home-page

then scroll down and remove the address in the Site Info URL box or link to a different ‘Welcome’ page that is stored in Resources.

dept-home-page-url

Oxitems RSS feed displays that use output_newsfeed.js

We currently do not have a fix for this and are liaising with the Oxitems team on this matter, in the meantime we suggest adding text to say “Please use the right mouse button to click on links below and opt to open them in a new tab”.

Other RSS feeds that either use non-secure JavaScript URLs or do not force links to open in new windows or tabs

Please read an earlier (now updated) blog post about displaying RSS feeds.

Web Content links to external websites that do not open in a pop-up window

You should always opt to open links to non-secure (http) sites in a pop-up window.

wc
Please note that Web Content links that do open in a pop-up window will not be blocked for site participants with the access role, however, they will still be blocked for those with the maintain and contribute roles. This means that students should be be unaffected.

WebLearn will be modified to ensure that non-secure (http) Web Content links always open in a pop-up. The database will be modified to reconfigure all existing Web Content links to non-secure sites so that they open in a pop-up.

Syllabus tool items which employ a redirect to a non-secure web page

Either remove the redirect and replace with a page stored in the Resources area of your WebLearn site

syl

or or add the text of the target page as a Syllabus item

sly-add

Non-secure Facebook plugins

Please regenerate any Facebook plugins and replace the incumbent with the new code.

Non-secure 3rd-party Twitter display widgets

Please switch to using the Timeline widget supplied by Twitter.

WYSIWYG HTML pop up help

We do not have a fix for this yet other than searching the Internet for “CKEdit help”.

Display of images that are not stored on a secure domain

Save a copy of the images in the Resources tool in the site and use this copy of the image instead. Please respect the copyright of all images!

Embedded HTML5 audio and video elements that are not stored on a secure domain

Store audio and small files in WebLearn, store large video files on a server that uses https protocol.

LTI Tools should use secure launch URLs

If you have asked the WebLearn team to add Basic LTI tools to your site, you must ensure that the launch URL is set to a secure URL (https). If you don’t, then even if the launch is set to open in a popup window, Firefox will block the content.

Firefox warning

Updated 29th August

Posted in Sakai, WebLearn | Tagged , | 3 Comments

3 Responses to “Firefox now blocks non-secure content from WebLearn: WebLearn pages may need to be edited”

  1. […] We would strongly suggest that Local WebLearn Coordinators and anybody who has the maintain or contribute role on one or more sites read the WebLearn blog post on the implications of the tightening up of security within the most popular web …. […]

  2. […] We would strongly suggest that Local WebLearn Coordinators and anybody who has the maintain or contribute role on one or more sites read the WebLearn blog post on the implications of the tightening up of security within the most popular web …. […]