Removal of httpswwwroot

[Andrew Nicols]

Originally reported in http://mahara.org/interaction/forum/topic.php?id=1746

If wwwroot and httpswwwroot are both set and they're set differently, then users accessing mahara over https won't be able to retrieve various things - e.g. help snippets.
If the user is coming over https, and httpswwwroot is set, we should be using that instead of the wwwroot.
If they use the wwwroot, then browsers see this as XSS and block various things - e.g. help files.

This is *only* a problem when visiting over https and the wwwroot is set to http. The only place I can see where we actively pass users from http to https is the account settings page. That said, users can visit the httpswwwroot instead of the wwwroot and will see this on any page that they visit (until they click a link that is...).

I've marked this a security bug for the moment until someone else has had a look.
I think we may need to have more of a review of this - the ajaxlogin also uses config.wwwroot regardless of the setting of httpswwwroot.

Andrew

[Andrew Nicols (dobedobedoh)]

This patch may provide a potential solution but may also break things horribly - haven't had a chance to fully check. It may cause issues with exports with links to files included in the export (e.g. not being re-written correctly). It's also rather heavy weight.

[Andrew Nicols (dobedobedoh)]

I *think* that the ajaxlogin is the most security conscious part of this bug.
js/mahara.js->ajaxlogin() sends the json login request to config.wwwroot + 'minilogin.php' which will ignore the httpswwwroot set for auths.

[Andrew Nicols (dobedobedoh)]

There's no sane way to fix the ajaxlogin I don't think:
User using http but httpswwwroot is set. If forcing to use httpswwwroot, this is an XSS
User using http and we ignore the httpswwwroot, password sent over http.

[Andrew Nicols (dobedobedoh)]

Just had a chat with Penny.
We're both in favour of stripping out the httpswwwroot entirely and, if you want to use https, that's what you specify in your wwwroot. The option causes a great many potential issues and as a result there are attempts to break out of the browser's sandbox to jump between http and https whenever you're trying to use the httpswwwroot.

There is at least one potential issue:
* if httpswwwroot and wwwroot don't just differ WRT to the protocol (e.g. wwwroot=http://mahara.example.com; httpswwwroot=https://secure.example.com/mahara), then we'd be changing the hostname and mnet certs would break.

I don't think that profile exports should be too affected. It would effectively be just the same as following the Changing Hostname guidelines from the wiki.

[François Marier (fmarier)]

Yeah sounds like removing httpswwwroot is the solution.

[Iñaki Arenaza (iarenaza)]

As Andrew points out, due to the way we deal with logins (at the same URL with a transitent content, instead of using a round trip to a different login URL like Moodle does), it's completely impossible to make the Ajax based login work with it (the Javascript security model forbids it, as it's clearly a XSS).

I talked about this with Nigel when I developed the patch, and he thought the feature was still valuable (and demanded[*]) even if we didn't protect the ajax based logins, so that's why it got in.

On the other hand, I don't think httpswwwroot could break mnet certs. We don't use httpswwwroot for anything touching mnet at all (if I'm not mistaken), only for local logins, and only for the login process itself (so exports shouldn't be affected either).

I guess we are not going to change the way logins are handled, so this is a bit of a dead end.

[*] Many people don't need or aren't interested in protecting the contents of their Mahara site, but they need to protect their usernames and passwords (e.g., they may be using their LDAP credentials, that are reused in other more security-sensitive environments). And running the whole site on SSL just to protect logins is overkill IMHO (and quite a CPU burden if your site is used more than occasionally, even if CPUs have gotten better at crypto).

Saludos.
Iñaki.

[François Marier (fmarier)]

As Firesheep (http://codebutler.com/firesheep?c=1) has pointed out, logins are not the only thing that needs to be protected. Session theft is now a very real threat.

Also, Google has released numbers showing that the overhead of SSL is actually fairly small. We should probably encourage people to run full SSL sites, especially if they already have a cert for their logins. No?

[François Marier (fmarier)]

and here's the Google link I forgot to include:

  http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

[Ruslan Kabalin (rkabalin)]

I agree, full SSL support is required. httpswwwroot config option should be deprecated.

[Iñaki Arenaza (iarenaza)]

Then, so be it!

[François Marier (fmarier)]

During upgrade, we'll need to make sure admins are warned about this change.

I suggest a pre-upgrade check that will abort the whole upgrade if httpswwwroot is set in config.php. A message like this could be displayed:

"HTTPS logins have been removed. You need to remove the httpswwwroot variable and switch your wwwroot to https."

and then a link to this wiki page for more details: http://wiki.mahara.org/Release_Notes/1.4.0/Removal_of_httpswwwroot

[Iñaki Arenaza (iarenaza)]

I have just read the last developer meeting minutes, and wanted to clarify that I'm fine with the removal :-)

[François Marier (fmarier)]

Thanks for the clarification Iñaki !

[Greg Hanley (greg-s-hanley)]

This is going to cause problems as well. I just recently moved our site from always https to only login, because when students embed video from outside of the site (which they are encouraged to do to save file space and to take advantage of other resources) Internet Explorer will block the content every time you reload the page. It also looks like it is blocking the new Google Apps block type, even if the provided url/embed-code has https in it. As Iñaki Arenaza mentioned, we use LDAP for logins that can't be allowed to pass in clear text so HTTPS is important. At least 25% of our users use IE and it becomes very irritating having to constantly confirm "show all content" when editing a page or browsing a collection.

Some of this might be mitigated if the googleapps and externalvideo block types took into consideration the site's SSL status and embedded the content with https sources when available (both YouTube and Google Apps seem to support embedding over https).

[François Marier (fmarier)]

Thanks for the heads up Greg. I have filed a new bug for the issue you're describing: bug #809058.