On Mon, Aug 28, 2000 at 03:58:06PM -0500, Will Dye wrote:
>
> On Mon, 28 Aug 2000 21:47:07 +0700, Oskar Sandberg writes:
>
> > In fact, a setup class that generates the .freenetrc might
> > not be such a bad idea - maybe I'll write on tomorrow.
>
> FWIW, I like the aesthetics of the general idea. Have a program
> generate a good 'default' config file, then allow for hand
> editing by those who want it. Since the server code is going to
> read .freenetrc, it makes sense that the same general code base
> is used to generate a suggested .freenetrc.
>
> As for switching ports, I have three concerns...
>
> 1. How do we generate a reliable list of which ports to avoid?
> Wether we automatically generate the port number, or advise users
> to "pick a port number", this issue will need to be addressed.
Well, we obviously can't use /etc/services as Signal11 wanted, since the
is not cross platform. In fact, we can't use it even if we find out
another way to do it in Windows, since the platform we are writing for is
not "Unix and Windows" but Java. Only if there is a way in Java is it good
enough.
> 1a. What cross-platform technique will generate a good list of
> ports that are already in use? Of ports that might be in use
> later, even if they are not in use now? "Ask your local
> sysadmin" is what I usually see in instructions. I suspect that
> this is not what Oskar has in mind. :-)
a:
boolean failed;
do {
failed = false;
try {
new ServerSocket(Core.randSource.nextInt() % 64512 + 1024))
catch (BindException e) {
failed = true;
}
} while (failed);
b:
Ask the user to confirm the random selection.
> 1b. Trying to use certain ports can attract attention, even if
> those ports are not in use. Two examples:
>
> 1b1. At my weekday job, I found out that our firewall
> blocked ports above a certain number only when I tried to install
> ZKS Freedom, which used a number that was higher. My attempt to
> use the higher port number was detected & showed up on the
> security logs as a potential problem. AFAIK, there was no way for
> Joe Average User to know in advance which ports were blocked.
This sounds like you are discussing OUTGOING ports, which is really not
something that can be helped by configuring your system (you can't really
go "My weird firewall blocks all connections to ports > 1234, everybody
reset your Freenet nodes" regardless of how good the config tool is).
> 1b2. A while back there was a discussion on Slashdot about
> port scanning. In it, one sysadmin commented that he investigates
> any attempt to use the port '37337', just because at one time that
> was a popular port in certain circles.
So now he'll find Freenet traffic on it sometimes. Remember, this is not a
attempt to stop people from discovering nodes, it's lousy for that, but
meant to make it harder to block (Sysadmin's are lazy, if something is not
harming the system in any way most will not go on a witch hunt constantly
packet sniffing all ports and bringing everyone who uses encrypted
communications in for interrogation and the water trial - they may however
consider blocking port 19114 is a boss happens to complain about that evil
Freenet thing).
> 2. If this is implemented, we need to insure that people have
> an easy way to find the right address and current port number
> of nodes they wish to contact. If someone says "you can start
> your Freenet node by connecting to my node at f00bar.net",
> they may not include current information about the port being
> used. I don't want to encourage port scanning. That would
> *definately* curry the attention and ire of many a sysadmin. OTOH,
> some sort of registry like inform.php has its own problems. Hmm.
> I guess people will just have to get in the habit of specifying a
> current port whenever they give a contact point to someone. The
> clients could have a nice error message saying "did you get the
> right port?" when connection attempts fail, along with a warning
> about the hazards of finding it via repeated trial and error.
Ultimately you'll need to know the address, the port, and the public key
fingerprint of any nodes you add yourself, so...
> 3. Will randomizing port usage fix what it is supposed to fix?
> The purpose for switching the port used is to make it harder
> for someone trying to shut down nodes to even find the nodes,
> yes? Is there some other reason?
Shutting down. Not finding.
> Last I heard, we are nowhere near the ability to run nodes
> undetected. The protections were in the form of being able to
> say that there was no proof that a particular node operator
> accessed an 'illegal' file, which seems to be in the same
> spirit of the Napster defense -- their service was for legit
> stuff, and the 'illegal' stuff was the fault of those awful
> users. Yes, yes, I am fully aware that Freenet is *not* the
> same as Napster, but in this case the point is still valid. If
> you can't hide the node, then your best defense is that the node
> is for approved uses. It doesn't look good if you make clumsy
> attempts to hide the existence of your node, then claim after
> you're caught that the node was only for good bits instead of
> bad bits.
Yes, this is not about running undectected.
> In this context, it may be better to be very open about running
> Freenet nodes, and emphasize the legal uses of it. "Those
> Freenet nodes are great! Now I can get movie previews and web
> pages from slow servers in a tenth the time that it takes on
> the regular web. Freenet is faster, inherently more efficient,
> and far more secure in terms of both authentication and
> privacy. Every college and business should run these, to speed
> up response time, lower bandwidth charges, and protect
> themselves from corporate espionage and lawsuits!" Yes, I'm
> aware that 0.3 is not quite ready for all that, and indeed there
> are some who regard such a sales pitch as an anathema to What
> Freenet Is All About. Suit yourself, but if you are only
> interested in the up-the-authority aspect of Freenet, just think
> of the "legit" traffic as steganographic chaff. :-)
The train has left the station on convincing the world Freenet is another
benign IPO making technology. A long time ago...
> I'm all in favor of using random ports, because it's a step
> towards true "dissident mode" stego nodes. All the same, I
> don't want this port-switching thing to backfilre in the short
> run. Come to think of it, maybe the best compromise is to go
> ahead and intall port switching, and document that this does not
> mean that nodes are expected to be hidden. Having standard
> Freenet use random ports by default will be helpful to future
> stego nodes, so I *do* want to see it. Just put it in the docs
> that the mere existence of nodes is still nowhere near hidden.
Exactly.
Truly hiding a node is something completely different - it may be
possible in a Freenet-like network, but not the one we have to today (your
nodes address is made publicly available after all).
> Argh. I spent to long on this. Shut up, willdye. Bugs to
> fix....
>
> --Will
> (not speaking for his employers, and for the last half hour
> not working for them either)
> willdye at willdye.com
>
>
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--
\oskar
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
