SSL Proxy woes

SSL Proxy woes

by Ben Steeples -
Number of replies: 20

Our Moodle 3.2.1 server is behind a load balancer which offers SSL offloading (meaning that the Moodle server never sees SSL/HTTPS requests). In 1.9 this worked perfectly, enabling loginhttps would send users via a secure login page, but dropped them back to HTTP when their login completed. It seems that whenever the login form appeared, it would POST to a secure page.

However, in Moodle 2.3.1, we're getting different results:
loginhttps = false; sslproxy = false
Works, but login page is sent over an unsecure HTTP connection.

loginhttps = true; sslproxy = false
Fails, visiting the login page causes a cyclic/infinite browser redirect.

loginhttps = true; sslproxy = true
Fails, visiting Moodle throws up an error that wwwroot isn't https.
Changing wwwroot to include fixes this, but the entire site is then in https (and we hit subsequent issues of mixed http and https content).

It seems that:

  • With sslproxy = false, Moodle is expecting to see a $_SERVER['HTTPS'] value, which is never set (due to NLB), and hence causes an infinite loop.
  • With sslproxy = true, Moodle is expecting the wwwroot to be a https url, forcing the entire site to be https, and bombs out when it isn't.

Any suggestions? Reintroducing the older behaviour, with a warning that it isn't advised, would be an ideal solution.

Average of ratings: -
In reply to Ben Steeples

Re: SSL Proxy woes

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
Hello,

$CFG->loginhttps with ssl proxy is not supported because we must know how user accessed the server, sorry.

I would personally recommend to use SSL everywhere because using ssl only for login pages does not improve security much, once you get http cookie of a teacher or admin you can do pretty much anything in the moodle.

Petr
In reply to Petr Skoda

Re: SSL Proxy woes

by Ben Steeples -

Hi Petr,

I appreciate that sslproxy and loginhttps aren't supported, but it would be good if there was an option to override this behaviour.

Is there any easy way of doing this?

Thanks,
Ben

In reply to Ben Steeples

Re: SSL Proxy woes

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
It is not supported for a reason, if you want to hack around it fine for me, just add "return;" to the start of verify_https_required() method inside lib/pagelib.php. But please do not report any bugs or problems related to this afterwards.
Average of ratings: Useful (1)
In reply to Petr Skoda

Re: SSL Proxy woes

by Ben Steeples -

Hi Petr,


Thank you for this. I agree, putting the entire Moodle site in HTTPS would be the better option. Unfortunately, we've had fixed references to HTTP creep into the site, and it's going to take a while to track these all down.

In reply to Ben Steeples

Re: SSL Proxy woes

by Daniel Kaelin -

I have found multiple fixes for this issue. We have our Moodle site sitting in a load balanced environment with SSL offloading. 

I was running into the same problem as you with HTTPS logins only and certain pages being rewritten as HTTPS which resulted in broken pages. 

 

Here are the fixes we have implemented in our environment to workaround these issues. I would test them with your environment prior to putting them on a production site. This is with Moodle 2.4.7 but I would imagine it applies to more than one version. 

 

1. Set sslproxy=true in config.php file 

2. Comment out the following section from /lib/setuplib.php.  Approximately line 822 - 828

3. Add the following lines to lib/pagelib.php typically found around line 1352

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {

                                    $_SERVER['HTTPS'] = 'On';

                                    return;

                        } else {

 

                                    redirect($this->_url);

                        }

 Use the image below as a guide. You will replace out the return; line with the enclosed code. 

4. To prevent form pages from being rewritten as HTTPS you will need to comment out the following lines around line 175 in /lib/formslib.php

            /*if (!empty($CFG->sslproxy)) {

                // return only https links when using SSL proxy

                $action = preg_replace('/^http:/', 'https:', $action, 1);

            }*/

 

 

In reply to Daniel Kaelin

Re: SSL Proxy woes

by Lars Bonnesen -

I am running Apache reverse proxy with SSL offload on a number of sites.

Trying to do the same with Moodle 3.1.3 (Build: 20161114) seems to be difficult. I am not able to make it work even with your workaround... and I also do not like to do such hacks... what happens on updates?

This really not possible to do in an officially supported way?

Regards, Lars.

In reply to Ben Steeples

Re: SSL Proxy woes

by Christopher Murad -

Not recommended but I did run into an issue of the browser blocking a filepicker request XMLHttpRequest cannot load AJAX - because of XSS / CORS 

In this instance I commented out the first line of  /moodle/user/editadvanced.php - where it required https for this page.
The reason being as users passwords can be set from the profile edit page.

In this instance we are using ldap for user authentication / passwords are not changed via this page.

I just thought I'd share my experience as this thread has helped me with loadbalancer / ssl woes


Average of ratings: Useful (1)
In reply to Christopher Murad

Re: SSL Proxy woes

by Susan Mangan -

Hi, I just wanted to check in to see if you guys (and anyone else for that matter) are still using this particular configuration and related code hacks for version 3.0x?

We are also experiencing ssl offload woes with configuration set for https only on login.

We have recently implemented an F5 load balanced server farm using glusterfs, dedicated memcache server and dedicated MySQL server cluster using Apache 2.4.18, PHP (FPM/FastCGI) 5.5.21, V.3.0.3+ (Build: 20160324). And yes, I know we must be missing some brain cells to attempt such a mature configuration for this open source beast ;)

While we will plan to move to HTTPS next term, we are seeking a more immediate fix (bandaid) until we are able to fully test full HTTPS environment with our existing data.  When we implemented F5 load balancing it was not clear at that time that we could not use the 'https on login only' setting.  We got it to work initially by configuring env_module to allow https but now we are seeing certain moodle pages 'break' because of the ssl offloading.  This was missed during our testing phase prior to implementation as I had my browser settings to allow mixed content.  Obviously we cannot just tell our thousands of users to update their browser settings to accommodate this.

So far I think our options are as follows:

1. Go all HTTPS (which we will do next term)
2. Go all HTTP and turn off HTTPS on login only
3. Keep HTTPS on login only and modify some of the codebase as per this thread
4. Am I missing anything??

Appreciate any insights from the community!  TIA!!

 

In reply to Susan Mangan

Re: SSL Proxy woes

by Susan Mangan -

... and to add to the above mixed bag of apples, we authenticate over ldap (not ldaps) why not ldaps?  because we have next to zero resources and stumble upon these things re-actively as opposed to proactively sad  This is another item on my checklist of things to configure but I wondering how this might blend into the mix of ssl woes ...

In reply to Susan Mangan

Re: SSL Proxy woes

by Christopher Murad -

Hi Susan,
This thread popped back up in my email due to your replies and it piqued some curiosity...

While I understand there are probably many factors / tests you want to perform before going full https - my question to you is why not just pull the trigger now?

If you are load balanced already I doubt you will see a performance hit - and a combination some SQL,  moodle's find and replace, and some quick  sed/awk cli scripts  should cover updating all the links. 

Additionally it seems that you already have the ssl in place for login - switching it on fully only makes your site more secure and gets rid of the woes you are mentioning.

From my outside perspective going full SSL sooner rather than later is the way to go.

Hope this helps

Chris

Average of ratings: Useful (1)
In reply to Christopher Murad

Re: SSL Proxy woes

by Susan Mangan -

Re: "and a combination some SQL,  moodle's find and replace, and some quick  sed/awk cli scripts  should cover updating all the links. "

It would be great if someone started a 'transitioning to https' moodle page with tips and tricks to encourage the move rather than people having to hack their way around this issue because they are scared to do so - just my 2 cents ;)  But heh - maybe there is one!  I'll have a look!  Thanks again for all your suggestions, I may be checking back in with you guys as we transition smile

In reply to Susan Mangan

Re: SSL Proxy woes

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

LDAPS is pretty easy to configure - just uses a different port and you need to install a certificate.  As for ssl, I just moved my site to SSL - took me about ten minutes using letsencrypt.com to generate and import a certificate and change my config.php.  Not hard at all.  Little more involved on a cluster but don't let lack of resources stop you - it didn't cost me a thing!

In reply to Emma Richardson

Re: SSL Proxy woes

by Susan Mangan -

Thanks Emma, and everyone else who has posted.  Your suggestions and feedback help a LOT.  By lack of resources I really mean my time.  To answer everyone's questions around why we are not just biting the bullet to go https since we are already half way there, the reason has more to do with being afraid of breaking data during an active school term, especially scorm.  We have been a moodle shop since 2005 and I still have that early-moodle-don't-change-anything-until-fully-tested-with-all-your-data mentality!  I do know Moodle has made great strides in that area however and the release schedule, testing and documentation has come a long way since then. 

We are literally just starting a new school term with a new load balanced system with glusterfs and didn't want to implement anything else 'new' right now.  This httpslogin issue came at us as a bit of a surprise and although the problems were starting to creep up I didn't fully understand what was causing them until now.  That is the only reason for holding back right now - our intentions were to move that way soon anyway.  I just have to convince management that we need to do this now and hopefully with the support of the community we will be able to get through any issues we come up with during the transition.  Thanks again for all your feedback and expertise, very appreciated as always.

In reply to Susan Mangan

Re: SSL Proxy woes

by James McLean -

I'd suggest going HTTPS for the entire site, as soon as possible. DO NOT entertain the idea of using HTTP for login - this WILL transmit usernames and passwords in clear text over the wire when people login. If you did that you may as well just post everyone's username and password on a poster in the cafeteria, it's about the same level of security.

We have used https on login only with Moodle behind an F5 device on older versions of Moodle, I don't recall any special hacks being needed as it should be supported out of the box.

What specific issues are you encountering?

In reply to James McLean

Re: SSL Proxy woes

by Susan Mangan -

Yes, we essentially nixed that idea (not using https over login) pretty much as soon as I posted it - stupid thought.

What version are you using?  It seems this configuration worked in 1.9 branch but not 3x - not sure about 2x.  What specific apache configuration did you need to make loginhttps work with ssl offloading?  Our admin had to make a change to env_module to make loginhttps work otherwise we had a redirect loop when attempting to login.  The change was:  SetEnv HTTPS on in env_module.  It was going fine until we encountered the following 3 reported errors so far:

1. /user/editadvanced.php - when attempting to edit a user profile, JSON Error, unable to upload user pic (just hangs) and Interests field is disabled.  Looking at Chrome developer tools it looks like it's hiccuping on script draftfiles_ajax.php?action=list/repository - if you manually change the URL to https the error does not occur and the page is functional.  OR, removing loginhttps flag fixes this issue. (same issue as reported below?)

2.  /group/autogroup.php - page reverts to https which in turn breaks CSS due to mixed content

3.  /mod/lesson/editpage.php - page reverts to https which in turn breaks CSS due to mixed content

What do think about Ben's post above and his issues? https://moodle.org/mod/forum/discuss.php?d=207951#p906313

And Petr Skoda's post following that just confirms that this isn't supported https://moodle.org/mod/forum/discuss.php?d=207951#p906328 I applied his hack suggestion in that post and was able to get rid of errors 2 and 3 as well as be able to login to F5 using httpslogin without redirect problems and modifying env_module

 

 

In reply to Susan Mangan

Re: SSL Proxy woes

by James McLean -

Ahh yes - we did https login only in 1.9 days, but as soon as we went 2+ we were 100% HTTPS. Personally I'd be putting all efforts into moving to 100% HTTPS, it's well supported and the best way to go.

In reply to Susan Mangan

Re: SSL Proxy woes

by John Okely -

From a security point of view, HTTPS for login is not really a huge amount better than just HTTP. There are plans to remove it https://tracker.moodle.org/browse/MDL-42834 As you also noticed, it's not possible to have HTTPS for logins and SSL proxy at the same time. There are many flaws.

If it's at all possible I'd recommend going 100% HTTPS

Average of ratings: Useful (1)
In reply to John Okely

Re: SSL Proxy woes

by Lars Bonnesen -

And it is not possible to fix these flaws?


Regards, Lars.

In reply to Lars Bonnesen

Re: SSL Proxy woes

by Robin Stark -
I'm not sure how it was previously but in 3.x moving to HTTPS site wide is fairly easy, out of curiosity why would you want to fix the flaws and use HTTPS only for login when someone could do a MITM attack and grab the authentication cookie of an administrator.  Maybe I'm missing something but it just seems like a great way to potentially give someone open season on your install.