Wouter Verhelst wrote: > On Wed, Aug 13, 2008 at 09:58:50AM -0400, Paul Clements wrote: >> Wouter Verhelst wrote: >> >>> What we came up with is this: >>> - Server sends a random number as a way to challenge the client for a >>> password >>> - Client constructs something based on the IP address, password, and the >>> random number the server sent, pumps it through a secure hash >>> algorithm, and sends that back. >>> - Server constructs the same thing and pumps it through the same >>> algorithm. If the output matches, we're authenticated; if it doesn't >>> match, we're not. >>> Thoughts, anyone? >> But why build that into nbd? You can stunnel the nbd connection, and it >> takes care of authentication and encryption. And no messy code added to >> nbd. > > That's a bit of a hack, isn't it? It'd blow up the requirements on the > client side too, which I'm not very fond of (requires libssl and > libwrap, and seems to want some perl stuff, which I don't think can be > done from an initrd). Also, is it possible to run stunnel on the server > side in such a way that it'll accept different authentication for > different ports? After all, nbd-server can serve multiple connections > from the same server process now.
You're right, there are environments where using a generic tunneling mechanism (or VPN) is overkill, but I like the flexibility of being able to just set up the compression/encryption/etc. and everything that goes over the tunnel automatically takes advantage of it. None of the apps have to have compression/encryption embedded in them, which is nice (especially in the case of nbd, where that code would have to be in the kernel). The tunnel could be run somewhere besides the actual client and server systems too, if desired. > OTOH, I don't think the code for a secure hash function is very hard or > convoluted. I'd obviously ask someone to audit it once I've written it, > just to make sure I've made no errors, but it seems like something that > can be done in less than 100 LOC to me. The current nbd-client is only > 358 LOC. I think this, combined with some sort of encryption layer, would make the client/server connection very secure. -- Paul ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
