Issue 45: SSL for confidentiality (and perhaps authentication)

Reported by Unknown User, Jun 9, 2006

(This entry was imported from the savannah tracker, original 

The one feature of OpenCM that I really miss in Monotone is the 
support for SSL communication (actually OpenCM always ran over SSL, 
but that isn't really relevent). Privacy is important for me (I have 
some things in Monotone I wouldn't want other people to see, such as 
proprietary code and my personal configs, and I often work from 
coffeeshops, etc). Also the fact that Monotone has a custom 
authentication protocol somewhat frightens me. I know you guys are 
smart, and I've looked at it and didn't see any problems, but this 
really does seem to be something where standard == good, because 
standard protocols are the only thing that the real security people 
spend a lot of time looking hard at, and at this point Monotone 
isn't popular enough to attract serious attention from that sphere.

Taking into account the obvious responses:

- It would require yet another dependency. I agree that isn't great. 
It would boil down to either switching from Botan to OpenSSL, or 
using Ajisai. Neither seems like a compelling choice.

- Someone has to do the work, and it should be me since I want this. 
Yeah, I know. I'm busy, as I'm sure you are. :/

- Stunnel / SSH tunneling: My feeling on this is the same as 
--daemonize; this is something which should just work. Stunnel is 
IMO a stopgap at best. If it is something that can be done 
automatically without extra work from the user, it should be done.

- Certificates are a mess. Obviously. However using self-signed 
certs with manual imports is basically the same thing the current 
raw key system, but provides an easy (standard, documented, already 
supported) way of binding metadata to the key (maybe it is just me, 
but having the email address be the index for a key seems like a bad 
idea - what if I want to have multiple keys? What if I lose my key? 
I haven't seen a good way of handling these cases...). And it does 
leave open interesting opportunities WRT project-specific CAs, key 
revocation, etc in the future, if someone wants to deal with that 
complexity later on.

I suppose there are two questions here, one is if it is a good idea 
(in principle) to use SSL+certs, another is who is actually going to 
do it. I don't have a good answer for the latter, but I think I can 
make a good case for the former. I'd be happy to discuss here or on 
the list if anyone wants to talk about it.

monotone version:
monotone 0.26 (base revision: 
Running on          : Linux 2.6.16-1.2111_FC4 #1 Sat May 20 19:59:40 
EDT 2006 i686
C++ compiler        : GNU C++ version 4.0.2 20051125 (Red Hat 
C++ standard library: GNU libstdc++ version 20051125
Boost version       : 1_32
Changes since base revision:

Comment 1 by Unknown User, Jun 9, 2006

0.27 can speak over ssh, with an ssh:// URI form as the 
"host" parameter of push/pull/sync. It is also extensible 
in lua scripts to use any other full duplex channel you can run as a 
subprocess. Good enough?

Comment 2 by Unknown User, Jun 9, 2006

I should say "the soon-to-be-released 0.27", since there's 
no such release yet.

Comment 3 by Unknown User, Jun 9, 2006

Hrm. In general SSH is going to require that every user have an 
account on the machine, so I would say it addresses my initial 
problem while introducing one that I like even less. On the other 
hand the hooking mechanism may mean I can do this myself with some 
Lua glue and a little bit of C. I presume it is possible to allow 
anonymous pulls over netsync but require all pushes (and pulls from 
branches that have access controls) to happen over an alternate 
channel ie SSL? Also is there a way to short circuit Monotone's 
built in authentication mechanisms and so forth? I suppose I should 
go read the source now.

I can't say I'm really enthusiastic about it as a solution, but then 
again I'm not about to hack all of the nice stuff in Monotone into 
OpenCM, either, so I should probably just shut up and eat my damn 

That does leave the key metadata thing unresolved, though. The docs 
make it sound like once a key is in the database with a particular 
email, it's impossible to introduce another key with the same email 
address. Am I wrong about this?

Comment 4 by Unknown User, Jun 9, 2006

(I have a feeling my first questions can be answered by reading the 
hook documentation. I will do so tonight)

Comment 5 by Unknown User, Jun 9, 2006

Yeah, SSH is mostly for private use. You can scale it up a *bit* if 
you put entries in your .ssh/authorized_keys file with a command 
restriction (similar to but it's 
not terribly satisfying, I'll admit.

The authentication layer of monotone is not terribly rich, and may 
need some further adjustment as time passes. Currently it calls 
hooks to confirm read/write accesses from the network, but it 
doesn't mention whether those accesses came over SSL (since it has 
no idea about SSL). Some extension could be possible there, 

Key metadata has been pretty bad since the get-go. We're going to be 
having a go at cleaning this up when we do our "policy 
branch" work. This will involve storing some versionned policy 
settings in the database which describe human-to-machine identifier 
mappings, so you'll be able to rename and expire keys and branches, 
etc. That work hasn't really gotten underway yet though.

Comment 6 by Unknown User, Jun 9, 2006

Sounds reasonable. I have yet to really dig into the code (though, 
BTW, from what I've seen it is excellent work, certainly better than 
my own C++), but maybe this is a good time to do so.

Comment 7 by Unknown User, Jun 11, 2006

In principle I think we'd be happy to use SSL at the channel layer.  
Having our own crypto there gives me the heebie-jeebies, too.  There 
are some reasons why this isn't what we did from the start, though:
  * OpenSSL is GPL-incompatible, so we can't use it.  (We could in 
principle relicense monotone to add an exception, but then _we_ 
would be GPL-incompatible.  Since we currently distribute some GPLed 
and LGPLed code from third parties, and might want to do so in the 
future, and our code has itself been used in other projects, this 
option is unappealing.)  GnuTLS and Ajisai are both options.  The 
Ajisai faq says that it is still very alpha, though it's otherwise 
appealing (minimal new dependencies, presumably sane API, author has 
been responsive to our needs in the past).
  * Async sockets + SSL is a major pain in the butt.  It requires 
lots of magic, and last I checked there was no freely available 
documentation describing how to do it.
  * Most SSL code assumes you want to join in the X.509 mess -- 
e.g., you should have a key in that format sitting in a file, and 
you want to use signature chains to validate the other side, and so 
on.  It is probably possible to build an actually usable system out 
of these primitives -- i.e., one that doesn't add extra key 
distribution hassles or CAs, but still provides MITM protection -- 
but I couldn't figure out how to do it.

So, yeah.  SSL would be nice, there are just annoying practical 
issues to overcome.

(Who are you, by the way? :-))

Comment 8 by Unknown User, Jun 11, 2006

Oh, and re: the bug title -- you have to use the same system for 
both confidentiality and authentication, because otherwise your 
confidentiality is open to MITM attacks.

(Perhaps this is not that big a worry compared to having no 
confidentiality at all, but one might as well get these things 

Comment 9 by Unknown User, Jun 19, 2006

Yes, you are certainly right about async sockets + SSL being a pain. 
I know OpenSSL has had in the past (and may still have) various very 
weird failure cases when running on async sockets, and oh-my-god are 
they painful to track down. Right now Ajisai doesn't support async 
sockets at all, not to mention a distinct lack of Windows socket 
support, etc - it *works*, but I would not suggest using it in 
anything approaching production software in its current state. I 
really should start working on it again, there has been a lot of 
interest from different quarters (KDE, especially) but I'm always 
either short on time or motivation.

I think I mentioned something about MITM very briefly at one point - 
the easiest (rather, simplest) way to deal with MITM in this context 
is to simply predistribute all the certs and avoid certificates 
chains/authorities entirely. Since this is exactly the current 
model, there is no real loss in usability. (Or shouldn't, at least). 
There is some extra stuff in a self-signed cert that isn't in the 
Monotone key format (a signature on itself and some places to put 
various pieces of metadata), but you could treat such a cert exactly 
like an email/key pair if you wanted.

Comment 10 by Unknown User, Jun 19, 2006

(Finally bothered to get an account)

Created: 17 years 3 months ago by Unknown User

Updated: 17 years 3 months ago

Status: New

Type:Feature Request

Quick Links:    -     Downloads    -     Documentation    -     Wiki    -     Code Forge    -     Build Status