Heh, you'll never belive, but I have had the same idea a few days before when I was first installing freenet. And in fact, in order to help those trapped inside a firewall, a more convinient for those trapped solution could be found - a tunnel. A tunnel is much more flexible in terms of protocol - it allows to transmit IRc, ICQ, email ,HTTP or whatever else, and does not require any protocol implementation. In fact, a primitive tunnel consists of a daemon which listens to a particular port and sends all packets to some other host inside freenet's internal encrypted datastream just as a simple file. Outside the firewall the very same daemon unpacks the datastream and sends packets to IP layer of the host OS, which routes them appropriately. The only thing that needs to be done is faking the sender IP so that it matches the tunnel provider's external IP address. So, exact transportation process looks like this: Sender behind firewall: IPSRC: any IPDST: banned site's IP DPORT: tunnel's entrance port SPORT: any valid port All intermediate peers transmit the packet inside encrypted datastream, so they do not care much Packet when exiting tunnel(sent from the daemon on the exit side): IPSRC: external IP of the exit IPDST: unchanged DPORT: the port the tunnel was configured for SPORT: the port which tunnel provider's tunnel daemon listens on When the response packet gets to the tunnel provider's node, it automatically gets into the tunnel and is transmitted to the firewalled machine. The only issue is that the tunnel needs to be configured separately for each connection, which is not very convinient, but will work for any protocol, not just HTTP. PS: for such cases there are some existing tunneling programs, so the banned site might consider using them. Or, we could use them as a backend - e.g. SSH. It is cross-platform, fast, and provides good level of security.
On Thu, Aug 6, 2009 at 7:33 PM, Evan Daniel <[email protected]> wrote: > On Thu, Aug 6, 2009 at 8:09 AM, Matthew > Toseland<[email protected]> wrote: > > I propose that as a darknet value-add, and as an additional tool for > those in hostile regimes who have friends on the outside, we implement a > web-proxy-over-your-darknet-peers option. Your Friends would announce > whether they are willing to proxy for you, and you could choose which > friends to use, or allow it to use all of them (assuming people on the > inside don't offer). You could then configure your browser to use Freenet as > a proxy. This would not provide any anonymity but it would get you past > network obstacles and/or out of Bad Place and into Happy Place. It's not a > long term solution, but: > > - We have expended considerable effort on making darknet viable: IP > detection, ARKs etc. > > - It could take advantage of future transport plugins, but even before > that, FNP 0.7 is quite hard to block. > > - Many people are in this situation. > > - It is easy to implement. HTTP is complex but cache-less proxies can be > very simple. > > - It could be combined with longer term measures (growing the internal > darknet), and just work for as long as it works. Most likely it would be > throttled rather than blocked outright to start with, hopefully allowing for > a smooth-ish migration of users to more robust mechanisms... > > - We could allow recursive proxying to some depth - maybe friend of a > friend. This would provide a further incentive to grow the internal darknet, > which is what we want. > > - The classic problem with proxies is that they are rare so hundreds of > people connect to them, and the government finds out and blocks them. This > does not apply here. > > I like it. Darknet features are a very good thing. This probably > also needs some care wrt bandwidth management (related to 3334 -- > similar considerations probably apply). > > However, as I mentioned on IRC, there are several things I think > should be higher priority. Of course, I'm not the one implementing > any of this, but here's my opinion anyway ;) In no particular order: > > - Documentation! Both the plugins api and making sure that the FCP > docs on the wiki are current and correct. > - Bloom filter sharing. (Probably? I have no idea what the relative > work required is for these two.) > - Freetalk and a blogging app of some sort (though these are probably > mostly for someone other than toad?). > - A few specific bugs: 3295 (percent encoding is horribly, > embarrassingly broken -- in at least 5 different ways), 2931 (split > blocks evenly between splitfile segments -- should help dramatically > with availability), fixing top block healing on splitfiles (discussed > in 3358). > - Low-latency inserts flag as per 3338. (I know, most people probably > don't care all that much, but I'd really like to see whether Freenet > can hit near-real-time latencies for the messaging app I'm working > on.) > > Also, it's worth considering other ways to make darknet connections > more useful (in addition to this, whether before or after I don't have > a strong opinion on). Enabling direct transfer of large files would > be good (at a bare minimum, this shouldn't fail silently like it does > right now). Improving messaging would be good; I should be able to > see recently sent / received messages (including timestamps), queue a > message to be sent when a peer comes online, and tell whether a > message I've sent arrived successfully. > > Evan Daniel > _______________________________________________ > Devl mailing list > [email protected] > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
