STARTTLS for bzr server

[Martin Pool]

2009/8/20 Denys Duchier <denys.duchier at univ-orleans.fr>:
> I am employed at a (small) french university and I must unfortunately
> operate under a number of restrictions that do not necessarily make
> sense.

(The conversation was in retrospect pretty funny because I was under
the misapprehension that the requirements made sense. :-)

I think it would be great if people could set up securely
authenticated access to bzr servers in a way that worked across
platforms and that didn't require adding new OS accounts or having
root/admin access.  Ideally you should just tell it what users, what
password or keys, and what access they would have, and off you go.

The important thing is getting the feature but it's also of some
interest how we get there.  Ideally, we would use a relatively
standard protocol around the bzr smartserver protocol, for a couple of
reasons:

 - All other things being equal, using a standard protocol is nice
 - ... partly because you can then use standard tools (wireshark,
stunnel, openssh, curl, whatever) to debug/test it
 - It lets people switch between the bzr implementation and others -
for example, hypothetically, if it was based on ssh (which I realize
won't work for you) there would be a choice between the easy
installation of bzr and possibly the increased features of openssh
 - There is, possibly, less risk of making mistakes that impair
security.  Specifically, the starttls approach of having one channel
that's sometimes authenticated and sometimes not runs some risk there
will be bugs to do with confusing these states - I'm pretty sure I
have read of such bugs in real smtp implementations.
 - Wrapping authentication in a clearly separate layer allows it (at
least in principle) to be done in a separate untrusted process which
is also good for security.

... actually more than a couple!
> 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.
>

I don't think those are totally necessary problems with http:

You can run http on any arbitrary port, it doesn't have to have a
proxy.  If you can't accept any tcp connections at all you have bigger
problems.

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

Why wouldn't you be able to?

A more serious problem with https is that it has more constraints on
streaming and may in future be slower.  But it's probably not much
different at the moment.

My basic position here is:

You have a server, running as unprivileged user 'denys', on some
high-numbered tcp port, accepting connections.  When someone connects
it negotiates encryption and then authenticates them against eg a
user/password file.  From the network and the administrators point of
view it's a black box: they don't need to give you any permission
beyond letting you get tcp connections.  Unless they sniff the network
it is entirely invisible to them whether the program happens to be
talking https or ssh or something else.  There is no issue of needing
root or more user accounts or giving out shells on the box.

If they've said, irrationally, "you must not use a protocol that looks
like ssh", ok, but why not https?

> 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?

As we discussed on irc, you *can* arrange for the request handler to
have a reference to the medium, and then to tell it to start ssl.  It
would be reasonably clean at the code level I believe, but I'm
skeptical it's the best approach.

-- 
Martin <http://launchpad.net/~mbp/>