Security and privacy

My previous remark was a bit of an oversimplification, because I could not be bothered to explain fully.

The thing is, the Internet is really quite well designed. There are lots of independant parts that just plug together to achieve the overall effect, and it all works because of various standard protocols.

The bits are roughly:

+--------------+                      +-----------------------------------+
|    Client    |   Network protocol   | Server (Apache+PHP, IIS+PHP, ...) |
| (IE, FF, ...)|<-------------------->| +--------------------------+      |
|              |  (HTTP, HTTPS, ...)  | | Moodle                   |      |
+--------------+                      | |                          |      |
                                      | +--------------------------+      |
                                      +-----------------------------------+

Note in that diagram, that the network protocal only touches the client (the users's web browser) and the server. Moodle is sitting inside the web server, and does not really care how the data is sent down the tubes. The server handles the details of that. Moodle just sees a request for a particular URL, and sends back some HTML (and JS, CSS, ...).

Actually, there is one place where Moodle affects thta. How does the user's web browser decide which protocol to use? Well, that depends on the URL it is trying to request. Depending on wether that starts HTTP or HTTPS, the client will use one protocol or the other. As part of the output it generates, Moodle output URLs (links) that the user may click on. So, by outputting either HTTP or HTTPS urls, Moodle will determine whether the client users HTTPS in future.

Now, by default, Moodle does not use HTTPS. There are some settings that affect this, including $CFG->wwwroot in the config.php file, and "Use HTTPS for logins" under Site policies.

The difference between HTTP and HTTPS is pretty small, since HTTPS is built on top of HTTP. Actually, it is HTTP wrapped inside SSL, or TLS as I think it is more properly called. That gives you two additional bits of security.

A. It makes it impossible for anyone to see that data that is flowing backwards and forwards. HTTP is like a glass pipe. Anyone who can see the pipe can peak at the data flowing inside, and may be able to spot things like passwords as the pass. (This is why you may wish to turn on the HTTPS for logins setting.) HTTPS is like an armour plated pipe. No one can see it, only the client at one end and the server at the other can see the data.

B. HTTPS can guarantee to the client that the server is who it says it is. This is the bit where the certificate comes it. The server owner buys a certificate from a trusted source, and the client can check the certificate aginst the list provided by the trusted source when it connects. This prevents a malicious user from setting up a server that pretents to be your server, and tricks users into sending their password or credit card detials to the hacker's server.

Now in theory, it should be possible to use the A part of HTTPS without the B part, but in practice it is not. The reason for that is to do with keeping people safe. Because people send really sensitive information (like bank deatails, credic card nubmers) over HTTPS, and becuase of phishing attacks, broswer makers and banks wanted a really clear message to tell users to keep them save. The message is, look for the security icon in the URL bar before you typein sensitive information. In this case it is important to have both A and B, and as a result, web browsers now give very promenant warnings if you try to do A without B. Enough phishing attacks have tried to do that, so it cannot be allowed to just work.

I hope that makes it clearer.

I also want to add my voice to thank Petr for fixing the "https error" problem.

In my efforts to find a workaround, i.e. change all https requests on my domain to point to http (using a script or setting change), I downloaded demos of ZWS (Zeus web server) and also the load balancing software ZXTM. From asking on a forum (www.webhostingtalk.com), I got some helpful advice from one user. Each virtual site has 2 ports 80 and 443. The plan was to change the backend 443 to 80 also.

I was about to request that my hosting provider make such changes when by chance I had another look at this forum posting. I can't believe you finally fixed the problem! I have done the update and tested it. It works just fine and now I can re-enable guest login and allow course creators to create again without being directed to the https and site certificate error.

So I don't need to contact my hosting company now.

Thanks again for sorting this problem which has annoyed me since Christmas.

Best wishes and thanks to all,

John