The only issue I can see is that it will 'force' a lot of sites to move to fully https. This is fine per se but will break any embedded links to non-https materials (e.g. YouTube) due to 'mixed' security on the page. Many browsers are getting very draconian about this. Are there any plans to provide some sort of admin tool to identify such possible issues?
Good point Howard. Adding to your comment: Youtube is theoretically quite easy to handle when switching Moodle from http to https, since "http" in the URL can simply be replaced by "https". More difficult will be the fact than not every Moodle admin is used to replace links in the database (which is necessary if you do not want to change every YouTube link manually). And even more difficult is the situation if there are dozens of external links/repositories embedded in a Moodle installation, especially on large installations.
Indeed, you both hit the nail on the head. We will be looking into providing a tool to convert HTTP embedded content to HTTPS (Apache server itself allows you to do this, but we expect that not all servers necessarily offer this functionality).
In any case, this solution will only work for external sites that support https. So that's why we're interested in finding out any sites commonly embedded in moodle that do not support https.
As a side note, by making this change we are essentially saying that loginhttps and http (no SSL) offer equivalent security. So admins can 'downgrade' from loginhttps to http with no added risks. However, as you say we do expect admins to upgrade upgrade their security upon this release.
I disagree with the sentiment that loginhttps and http are of equivalent security. Leaked credentials and leaked sessions are of differing value because:
- Sessions are limited life - they have to be used within a relatively short timeframe of capture, and cannot be reused at a later date.
- Sites that have unified credentials (LDAP, AD, etc), the credentials give you access to all sites, while a session wouldn't.
- Users may reuse credentials on other sites - while it's bad practice, it is still very common.
Sites may use http content for performance reasons (https take CPU time, and is non-cachable), embedding, etc reasons, or the content within Moodle maybe considered of low value if compromised, but the credentials would allow access to much higher value systems.
I don't really have an opinion or not if loginhttps is dropped (we only use full https systems), but I don't necessarily agree with the premise that it is of equivalent security to plain http.
I would also note that many sites prevent embeds of https pages to prevent click jacking. We ultimately tell most of our users to not use embeds.
These are some really good points, thanks Eric. My assertion above that http and loginhttps are essentially equivalent was inaccurate or at least misleading.
I suppose what we are really saying here is that the detriments of loginhttps (false sense of security, cost of the SSL certificate and setup for a smaller gain, no AJAX login in future) outweigh the positives (somewhat improved security over http, ability to embed content from sites that only support http, slightly decreased server load).
In almost all cases the recommended choice would be use https site-wide.
Back on the other topic of this thread, it's interesting that you point out that embeds are often disabled or at least discouraged. This means that in general the impact of moving from loginhttps to full https will be reduced from the content side of things.
More difficult will be the fact than not every Moodle admin is used to replace links in the database (which is necessary if you do not want to change every YouTube link manually).
Perhaps this can be something Moodle can handle for all Moodle related features? If it's enabled, allow an update to the links. Or ask the question at Upgrade stage and update links autmagically?
Eric is right. Login https is more secure than http, partly because credentials which probably work for other systems are much more sensitive than a transient session ID. We should be very clear that the proposal is to remove the "medium security" option and force users to choose between "low security" and "high security". Not that any site running Moodle is actually "high security", but that's slowly being improved.
There are occasionally issues with https only, for example last week Chrome had an issue with popups and https, IE has a long standing issue where it doesn't close https connections which results in a minor "DOS", etc. For these reasons, there certainly may be cases where an admin does not wish to use TLS for everything, or where that simply is not an option, where it breaks things. My career is primarily in internet security, and from my viewpoint there are some advantages of using TLS for everything*, all the time, but it just doesn't quite work sometimes with real-world browsers and all.
* In the general case, there is also the argument that marking everything as "secure" by using TLS weakens security by blurring the line between what's confidential and what's not. Similar to the fact that marking every document in your office "confidential" guarantees that employees become accustomed to ignoring the designation. Better to have your public pages https://www.site.com and your credit card payment form on https://secure.site.com, running on a secured server, the argument goes. There is some merit to that.
A filter to convert http to https in links to external content is trivial to implement. Would be surprised if there wasn't one out in the community already, freely available.
Certainly for linked content internal to Moodle, you could use protocol relative urls:
This would get you over the mixed http/https that browsers like to complain about. I'm not sure if this would work for externally linked content though. I guess you'd be dependant on all external sites supporting https, which cannot be guaranteed.
Excellent idea nonetheless!
That's a really cool trick! Fortunately Moodle's internal links' schemes are all defined from the same place so when a site is changed to https, all the linked pages and content will as well. But that would be a good idea to try for external content, as you say.
If the server is still running a non SSL host pointing to the same webroot as the SSL host, why can't Moodle just redirect any requests using the HTTP protocol to HTTPS (stripping out any session related information from the response before serving up the redirect)?
On this topic, there was a talk from Google IO yesterday offering more justification for this approach:
Many of the courses on the site I administer contain links to external materials that cannot be copied. For example, teachers may want their students to access a news item, a review, or information on a technical website.
I don't think all these sites will all be using HTTPS any time soon, so if the removal of Login HTTPS in Moodle 2.8 prevents users of my site from accessing them, teachers will be very disappointed and some may even stop using Moodle.
This forum is certainly the right place to discuss the issue as it is read by experts, but I would suggest that before implementing such a dramatic change a wider number of opinions should be sought from Moodle users.
Many admins who use Login HTTPS must use HTTPS because it is required by their institutions, so they cannot revert their sites to HTTP. If they knew about this change, I guess they might worry that, when support for Moodle 2.7 ceases, they will have to explain to their colleagues that something as fundamental as linking to an external site is now allowed only if the site supports HTTPS.
I am no security expert and came across this thread by chance, so I apologise if I misunderstood the situation. However, if there is a technical solution to the issue of linking to HTTP sites, I would humbly request that it should be made available to users along with Moodle 2.8.
Thank you very much for you attention.
Links to insecure (i.e. non-HTTPS) sites aren't a problem (as in, Add a resource... > URL).
It's embedding http that's the problem - where the result of a 'secure' moodle domain, including 'insecure' domain content e.g. from Prezi, would be a page that makes browsers panic.
Prezi content, as just one example, is also available on HTTPS as far as we can tell. We implemented a filter to translate insecure HTTP Prezi links to HTTPS, with no reported ill effects. The filter code is very simple and easily implemented.
Likewise YouTube embedded content.
All sites should be HTTPS 100% of the time and there is certainly movement in that direction. In the transition however, I guess it's up to us as developers to ease the transition - and to educate our end users.
Could it be easily expanded to include other common sites used for embeds such as issuu and others people suggest (see what I wrote further down before spotting this post of yours)? Then moodle HQ could make it core as part of the loginhttps-devoid version(s).
Yeah Sergio, I agree that we need more opinions to get a complete picture of the usage of loginhttps and the impact of its removal. As it stands there seems to be little benefit and little detriment to keeping loginhttps. The perceived benefits of loginhttps greatly outweigh its actual benefits.
As David pointed out, links will be unaffected.
Yes, you can embed http content on a loginhttps site, but the whole point of https is to ensure secure content. So you should just have a http site if you are willing to put your users at risk in that way, and not give a false sense of security by using https on the login (when the user is most likely to be looking at the green icon on their browser.)
As James has said, education of end users is important. And I would propose that education of teachers and moodle administrators is also important. If it's true that some would leave moodle due to the dropping of loginhttps support, I don't think that they fully understand what it is and does. So it's up to us at HQ and in the moodle community to ensure people understand what removing loginhttps means.
Currently the removal of loginhttps is being delayed, it won't be in Moodle 2.8.
Here, we use embeds in course pages and sometimes Add a resource... > Page - that may be typical.
Sometimes youtube videos go in Pages so the student stays on moodle but is accessing the resource.
I advise staff to go easy on embedding into the course page, to reduce page loading times.
What might also be useful is to know is a list of sites that people commonly embed - youtube, prezi, issuu being the
ones that spring to mind from our place. But I appreciate there are also some random others like classtools.net.
For this https-only vision, here's a suggestion of how any embeds would work:
- A check - does this label's code have a http:// url in it, and is there a secure version
- If there isn't a secure version of that site, maybe have a wrapper script in moodle that could pull it in (but warning the user it's a site which isn't secure)
For the check, I wonder if the ruleset provided by the EFF for HTTPS Everywhere could be used by Moodle - I'm unsure on the licencing of the ruleset they provide however - but it would certainly be easier than Moodle maintaining it's own rules.
They also have an "Atlas" of all the sites they know of which support http/https at https://www.eff.org/https-everywhere/atlas/ which could be a starting point - but using their list would certainly be easier if the licencing is permissive enough.
A study examining the cost of HTTPS has been published at the ACM CoNext conference in Sydney.
As well as slowing down page-loads by as much as 50%, the study also considered the cost to local services like caching and virus checking, which can't be used as easily with HTTPS. It even goes on to estimate that transmission by HTTPS increases energy usage by 30%.
"The NSA and its allies routinely intercept [HTTPS] connections -- by the millions. According to an NSA document, the agency intended to crack 10 million intercepted https connections a day by late 2012. The intelligence services are particularly interested in the moment when a user types his or her password. By the end of 2012, the system was supposed to be able to "detect the presence of at least 100 password based encryption applications" in each instance some 20,000 times a month. For its part, Britain's GCHQ collects information about encryption using the TLS and SSL protocols ..."
i want my username (email, username, what ever site uses) and my password, to be under httpS, if in that same page / happening, i get my session key under HTTPs even better.
now i can goto the server room and run my key card (errr session key) and get in. ya i may loose it to someone else, but card is easily disabled and new key card (errr session key) obtained.
hey.. wait a minute.... i am just a general student. not much i can do... beyond steal a given user info. not much of a security risk (within reason)
woops, i have admin rights... time to keep me in HTTPS mode for all pages, why am i even trying to view stuff in admin rights? if i have admin rights, i should be able to create "lower level" user test accounts, and not use the "switch roles"
woops, i have course editing abilities... time to keep me in HTTPS mode. but WAIT! turn on editing, is currently "off". do i really need HTTPS?
Some good thoughts, thanks.
The vulnerability of HTTP involves stealing a user's session, so even if editing mode is off, the 'hacker' can still turn editing mode on easily once the session is intercepted.
HTTPS for admin only or limiting HTTPS by role is an good idea, as the HTTPS overhead will come from only a few users (say admins and teachers.) But even if only a ordinary student's account is compromised, his or her personal information would be exposed. Academic integrity can also be compromised if one student hacks into another student's account and changes their submissions or copies their submissions.