Nathaniel Smith wrote: > On Mon, Jun 15, 2009 at 12:02 AM, Antoine Martin<[email protected]> wrote: >> Nathaniel Smith wrote: >>> On Sun, Jun 14, 2009 at 8:42 AM, Antoine Martin<[email protected]> >>> wrote: >>>> This patch implements secure passwords authentication (I believe - can >>>> someone please check!) >>> Well, that's the problem with hand-rolled crypto -- it's mostly >>> impossible to check... >> Hard but not impossible! > [...analysis snipped...] > > Well, I meant what I said :-). I actually have a fair amount of crypto > expertise. The sad thing about crypto expertise is that you learn a > whole bunch of cool things, and then you can't actually do anything > with it, because the more you study the more you realize that the > *only* way to write working crypto designs is to (1) be one of the > best people in the world at this stuff, AND (2) convince all the other > best people in the world to spend a few years analyzing your design. > They're still finding design flaws in *ssh*, for crissakes. Ok, maybe I didn't explain it very well, I'm not claiming that this is fullproof by any means. In fact, it is inspired by digest-md5 as used by imap/pop auth schemes, and there are known weaknesses in these too.
> So maybe this design is fine, but the problem isn't just making > something that works, it's being confident that we can stand by it and > support it. I don't see any problems in your analysis, but that > doesn't convince me that there aren't any. I need a really good reason > to take that risk. Hmmm, I would prefer having the option to use an authentication scheme on top of tcp mode for those that choose to use it than none at all! As long as ssh is the default... Risk? > (Plus, how do I know that the next person won't > want even more assurances, like encryption or MITM protection or > whatever? Absolutely, unix is about giving you the rope to hang yourself and you can always do stupid things! This mode is meant to be used over VPNs or LANs, anyone using it over insecure links... well, is doing something insecure... Maybe just documenting what it does and more importantly what it doesn't do? > That will *definitely* spiral out of our ability to get > right. And that also means that whatever reason is given needs to > explain why we need a simple ad-hoc password scheme AND NO MORE.) What I am saying is that the no-ssh option is useful (I use it already) and that you can't just leave the port open for anyone to come and connect/steal the sessions. And if you're going to use some authentication scheme, you might as well not make it trivial to snoop the password. (digest-md5 as opposed to plain/login) >>> Technically, the patch looks reasonable enough, and things like the >>> short write issue are fixable. >> I'm curious, can you suggest how? >> Without adding a whole lot of code that is... I was trying to keep it small. > > It's just a little loop like > written = 0 > while written < len(data): > select.select([], [sock], []) > written += sock.write(data[written:]) > (though of course it's better to wrap this in a utility function) Hah, sure. I thought you meant in such a way as too keep the socket code out of this part of the code. (I like layer separations/abstractions a bit too much for my own good sometimes) > >>> I'm *really* nervous, though, about getting into the secure connection >>> business. That's an impossibly difficult problem, and it's one that's >>> already solved -- just use ssh. So I'm reluctant to accept any patches >>> along these lines without, at the least, specific use cases and clear >>> argumentation for why this approach is the most appropriate way to >>> handle those use cases. Can you provide such? >> I think I can. I've got Windows boxes on the LAN, these will not have >> openssh or plink installed. > > plink is trivial to install (literally: "click 'Save link as...', > done"). Hardly noticeable compared to installing the rest of xpra > (which is much less trivial). Actually, it's not, not any more. You should check out the setup.exe xpra client installer I made for windows - posted a link here recently. It installs like a breeze! Which btw, still requires some patches that I would like you to merge... Can you take a look at some of those? > >> Another use case would be anonymous sessions (ie: locked down guest) >> where you want to allow access from remote hosts without giving them >> full ssh access. (it may also be do-able by setting their login shell to >> an xpra wrapper, but that's just too limited and nasty) > > This seems like a very specific and somewhat odd use case -- is this > actually something you are planning to do for real? Something I've done before with other tools, and I think xpra could be quite well suited for that. > (Note also that it's trivial to configure ssh so that when a certain > key is used it will automatically spawn some particular program rather > than give general shell access -- google "ssh restrict commands" or > somesuch.) Sure, but I'm trying to avoid even having an ssh connection (or even server) in this case. Just the xpra ports. >> BTW, I'm even trying to build the xpra server for win32 now, any ideas >> where I could find one that builds/works?? >> (and the machines that will run it will definitely not be running >> openssh server but will still require authentication of some sort) > > Cygwin comes with an openssh service. You may well want to run xpra > under cygwin anyway (that'd be the simplest way to get the named pipe > support that xpra assumes!), so installing cygwin may not be an extra > burden at all. And if you must start running a new network-accessible > service on this machine, you should trust openssh a heck of a lot more > than any code that we throw together ourselves. After I wrote this, I installed the full cygwin X setup which comes with its own Xvfb server (not advertised anywhere). Looks like xpra server could run against that, but I'm not convinced of the usefulness of the whole thing: there were display bugs and there aren't any useful apps to run beyond xterms... Cheers Antoine _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
