STARTTLS for bzr server

[Denys Duchier]

Following up on the discussion we had on #bzr:

I am interested in improving the bzr server to provide:

    - encryption (done in a separate patch)
    - user authentication
    - operation authorization

I am employed at a (small) french university and I must unfortunately
operate under a number of restrictions that do not necessarily make
sense.

Why not SSH?

    - there is NO WAY that I can be permitted to provide SSH access to
      any machine on our network (regardless of whether it is physical
      of virtual), or whether the access is restricted.

      The mere mention of SSH access is sufficient to get a NO from the
      network admins.  This is not a rational requirement.  It just is.

    - all university personnel must be authenticated using the
      university approved method.  It doesn't matter that it makes no
      sense; that's what you have to do.  Here, it's really, really
      advanced: it uses LDAP; so it must good!... right? er... right?

Management:

    - we are researchers: this means we collaborate on software and
      papers with other researchers on the planet (like everyone else).

      we need to make it possible to (easily) add non-local
      collaborators on specific projects.  This is one point that is
      very, very hard to sell to the admins.

Why not HTTP(S):

    - it is incredibly difficult to set anything up behind the
      university portal.  Nothing plays well with reverse proxies;
      project management software even less.

    - how can you add collaborators when you are not allowed to control
      the authentication configuration files?

The bzr protocol can easily be extended with "user authentication" in
the same manner as other protocols (e.g. SVN).  You may think it
bizarre, but this form of authentication is easier to sell to our admins
than the alternatives.

My plan is to provide services for:

    - authentication
    - authorization

through hooks and plugins.

Since it is never a good idea to transmit credentials over an
unencrypted channel, I extended the bzr server with SSL encryption, and
bzr clients can now use bzrs:// URLs to connect to bzr servers with SSL
encryption.  See [1] on launchpad.

[1] https://code.launchpad.net/~denys.duchier/bzr/bzr.ssl/+merge/10254

I would also like to provide opportunistic upgrade to an encrypted
channel for all bzr server connections.  In this manner, a client can
connect to a bzr server (old-style) and request an upgrade to an
encrypted channel.

For many protocols, such an upgrade is usually initiated with a STARTTLS
command.  The problem here is that a STARTTLS request arriving at the
server is executed at a level that knows nothing of the underlying
socket.  My question is: how can we best accomodate a STARTTLS-type
request?

Cheers,

--Denys