At the very least I would want the fproxy page to be able to be password protected.
I know trusted client certificates can be a nightmare. If you support SSL, supporting client certificates is actually quite easy. That's why I suggested just putting in the options for users who know what they are doing but not really offering support beyond that. Given the sensitivity of what fproxy can do, if it is run on a multi user machine this is really the most secure way to support doing that, even in a local network. On Jun 30, 2006, at 11:05 AM, Matthew Toseland wrote: > Allowing trusted client certificates is a very complex option (from > the > point of view of user friendliness)... > > We can provide some options for stripped down operation (e.g. no > direct > downloads to disk / uploads from disk, no global queue access > without a > password), if that is useful.. > > What proportion of users are affected by these issues though? > > On Mon, Jun 26, 2006 at 06:04:24PM -0700, Paul Forgey wrote: >> While it is probably not a good idea to run freenet on a multi user >> machine, it can almost be done in a manner that is as secure as the >> machine itself is and the option should be there to do it. I think >> participation would go up if more people could run permanently up >> freenet nodes like mine without throwing an entire machine at it. My >> server machnes are, well, servers and they have user accounts which >> means they could connect via localhost and do things to freenet >> unless I restrict fproxy access to other hosts. >> >> Currently, I run freenet under it's own "freenet" user account on >> it's own filesystem with all files and directories accessible only to >> the freeenet user. I have to pick a single user host on my network I >> want to access fproxy through and restrict it to that host. The >> telnet interface is of course disabled. >> >> As an alternative to host based access, it would be very nice to have >> an option for fproxy to support https and accept connections only >> from predefined client certificates, or at very least require a >> password. For https support, all that would be really required is a >> directory for the administrator to put .PEM encoded root certificates >> it trusts, another directory for client certificates it allows and a >> configuration option pointing to the server certificate and private >> key. Beyond that, leave it up to the administrator who knows what s/ >> he is doing to generate and manage all of this. >> >> The password option is even easier and I strongly think it should be >> there. >> > > > >> _______________________________________________ >> Tech mailing list >> Tech at freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so.
