Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: MNET 1.0 technotes.

Obsolete:MNET 1.0 technotes: Difference between revisions

From MoodleDocs
Line 83: Line 83:
** The library '''must''' let us manage HTTPS cert stuff
** The library '''must''' let us manage HTTPS cert stuff
** The library '''must''' let us encrypt/sign the payload
** The library '''must''' let us encrypt/sign the payload
* Even if Moodle has other XML-RPC or SOAP entry points, we want a segregated entry point for security/auditability purposes. You can eventually lock it down via httpd.conf / .htaccess
* Even if Moodle has other XML-RPC or SOAP entry points, we want a segregated entry point (url) for security/auditability purposes. You can eventually lock it down via httpd.conf / .htaccess
* Version the protocol?
* Version the protocol?
* Declare "prefix" namespaces for each service for extensibility.
* Declare "prefix" namespaces for each service for extensibility.


=== Services ===
=== Services ===

Revision as of 23:08, 20 July 2006

Draft -- Warning: Braindump in progress --Martin Langhoff 12:40, 20 July 2006 (WST)

Trust relationships and encryption notes

The community hub is formed by Moodle installations establishing P2P-style trust relationships. Once those relationships have been established, each Moodle can offer services from other trusted nodes, and use the offered services.

We need to define key infrastructure for managing the trust relationships, probably using a public key encryption scheme. Currently looking at...

Core encryption/signing infrastructure

  • Using GPG via
    • Crypt_GPG - a proposed PEAR package, wraps around the gpg binary. We are lucky and v0.20 is offered under LGPL, though it depends on PHP5 for its error handling (easy to fix).
    • TinyPHP or something similar. See DIY risks.
  • Using PHP's one mcrypt functions. See DIY risks.

DYI risks: we are not actually crypto developers, so if we go out an implement message signing ourselves there is a good chance we will miss a subtle point and end up with a horribly weak implementation that we will be very proud of.

Key generation and storage

Moodle installations should be able to generate keys or load preexisting keys. GPG tends to want the key as a file, so the root of moodledata is a reasonably good place for it. Unfortunately, it is also often world-readable.

Note that the key handling will never be as secure as personal GPG keys can be. The keys and the encryption machinery have to be accessible by www-data. So in most cases any user with shell access to the server can impersonate your Moodle install.

Key exchange mechanisms

  • Each Moodle can publish its GPG public key openly in a standard url.
  • Optionally, public keys can be exchanged out-of-band and loaded manually
  • We do not want these keys to show up on established GPG keyrings, and it is probably overkill to establish a moodle keyring. URL itself is an important point of trust -- see next point.
  • Maybe the 'Register Moodle' database that Moodle.org maintains could make your site keys optionally available in a searchable/browsable directory, and provide some means of requesting a peering arrangement -- even if it is just listing the main admin's email address.

URL as a point of trust, and HTTPS problems

When trusting a web app like Moodle, the URL itself is an important point of trust, specially if it is via HTTPS. We could say that the trust levels are

  • Bare IP-based HTTP URL: the admin controls the server.
  • Bare name-based HTTP URL: the admin controls the server and DNS.
  • Self-signed HTTPS URL: transactions are also encrypted, and we are less vulnerable against MITM attacks.
  • CACert-signed HTTPS URL: there is some assurance of server administrator identity.
  • Paid CA signed HTTPS URL: there is some assurance of server administrator identity and money ;-) (Actually, CAs do some due diligence to check that Amazon.com is actually Amazon Ltd.)

However, the http clients we have in PHP are brittle and hard to use in most of these cases:

  • Hard to get https support (curl compile options, non-free dependencies)
  • Hard to get meaningful errors when the certs aren't good. PHP's libcurl support has the needed bits and pieces, but it is hard to access them directly when using a library such as nusoap.
  • Hard to register an "unofficial" CA such as CACert.

Encryption and performance

Full GPG encryption is costly. To support high-traffic scenarios we should use GPG to setup the dialogue, trade a randomly generated session key, and then continue with symmetric encryption using that session key.

Note that this assumes we are being 'stateful' where we work on top of a stateless protocol. So we should cache the session key, and have an explicit expiry for it. If we are close to the expiry, negotiate a new one. Which leads me to...

Encryption and clocks

Moodle nodes should be on reasonably sync'd up servers. Part of the key setup process needs to check whether the system clocks are reasonably in sync.


Alternative: Use HTTPS infrastructure (or not!)

One does wonder

  • Why are we signing/encrypting all this stuff when we use HTTPS?
  • Why are we trying to manage our own key distribution and trust mechanisms if we can use HTTPS's?
  • Why struggle with key security when Apache's SSL implementation does a kind-of-reasonable job of protecting the private keys?

In a sense, we are making it much, much harder on ourselves. However, there are several threshold issues

  • Not all users can use HTTPS easily -- configuration is hard. We aim to make configuration very easy as soon as there is a gpg utility in the path. Setting that path if it's not the default should be the only hard thing in our scheme.
  • Apache's SSL private keys won't be useful to authenticate as an HTTPS client. We need both. Our scheme is of symmetric peers, on top of HTTPS but the HTTPS infrastucture is client/server.
  • There may be many Moodles in the same HTTPS host sharing the same keys -- (this can be worked around though).

Base API

Should be very easy to extend -- not sure if the services themselves can be cleanly pluggable as they will surely involve serious core Moodle changes, but the API should not be constrained by preconceptions.

Each service can use the core protocol or break out and do its own thing. We do need to ask several questions, however, and so it is a good idea to define an entry point and a base RPC-ish protocol.

Base protocol

  • Need to define whether to use SOAP or XMLRPC.
    • Functionally equivalent
    • XML-RPC simple, easier to debug
    • SOAP has more in the way of introspection -- which may be of use
    • The library must let us manage HTTPS cert stuff
    • The library must let us encrypt/sign the payload
  • Even if Moodle has other XML-RPC or SOAP entry points, we want a segregated entry point (url) for security/auditability purposes. You can eventually lock it down via httpd.conf / .htaccess
  • Version the protocol?
  • Declare "prefix" namespaces for each service for extensibility.

Services

Outline of what I'd expect a site admin to see when looking at the relations with a given host X:

  • Offer Services
    • Allow users from X to SSO here {yes/no} {see report}
    • Allow users from X to enrol to courses here {yes/no} {only courses from list/category} {see report}
    • Allow admins from X to enrol users to courses here {yes/no} {only courses from list/category} {see report}
    • Allow admins/teachers from X to retrive course zipfiles (without user data) {yes/no} {only courses from list/category} {see report}
  • Use Services
    • Allow users from this Moodle to SSO to X {disabled on the remote server/yes/no} {see report}

Work involved

Trust and encryption

  • Revamp Crypt_GPG
  • HTTP client to handle HTTPS correctly, and dealing with self-signed certs in a user-friendly way
  • Define a simple API to
    • Publish pub cert
    • Publish services offered
    • Trigger services offered
    • Create "allow users to SSO" service
      • Options: users shortlist, remote admin approval
      • Requires Auth API work and plugin changes
    • Create "allow users to enrol in courses" service
      • Options: courses shortlist, remote admin approval
      • Requires Enrol API work and plugin changes
  • User-friendly admin pages
    • Establish and manage trust relations
    • Open/close services
    • Each service with an associated usage report. Examples:
      • What remote users are logging in, from where, which remote admin OKd them
      • What remote users are enrolled in, from where, which remote admin OKd them

Protocol and services

  • TODO