Support more transports - TCP, HTTP, steganography etc
Some of us, "live" behind a restrictive firewall, mine only accepts Http conections and drops others then i cannot connect to the freenet, can you implement standart ports like 80,443,53,1863, etc for connection???
There has been significant progress on this feature, “transport plugins”, but Chetan’s work is not yet part of the main Freenet, and doesn’t yet support TCP; it only supports packet-like transports, so e.g. cloaking traffic as VoIP to avoid blocking. More work is needed, by me and Chetan, to get this working, but first steps have been taken.
Also see this request for TCP transport: http://freenet.uservoice.com/forums/8861-general/suggestions/94861-support-more-transports-tcp-http-steganography
(can you merge these duplicate requests?)
what happened with this idea?
I am also allowed to use only ports 80 and 443.
when I administate my vps, I had to use web base ssh and to install shell in a box and now I can do it with 443. But I can't run Freenet.
I can see the appeal myself. I love the idea of having extensible purpose built languages and schemas and soft coded interpreters or protocol descriptors. The ability to define what a browser will read, is as important as being able to define what content a server should deliver. Why not go the whole hog and implement code that replaces the hard coded aspect of browser protocol handlers, put it up as f/fox & chrome extensions until people find they cant do without it and any protocol definition or descriptor for a URI schema, can actually be published on freenet itself as convenient DNS independent, extensible, browser code repository.
That way ANY arbitrary potocol/URI schema may be implemented and the code extensible nature of the browser as it exists, may be able then, to escape from such a web documents only context, predicated upon DNS and the constraints of the existing transport layer encapsulation.
Since Freenet only depends on IP for machine/node identity, why not offer extensible protocol features for browser code then let developers roll their own protocols. Then URI schemas can be handled by generic protocols that abstract away the constraints of hard coded URI handling. Server code might also avoid constraints on data encapsulation for transliteration to the browser. Instead the browser can be co-opted into accommodation of a purpose made protocol and functional definition, may be implemented as easily as a
#INCLUDE pre-processor directive in C is used to link in some library code.
The more that can be done to co-opt browser developers, the more leverage the freenet project may have towards being an incoporated component of the base-code and default installation. Code abstracting and repository of library source code, would in general, might I suspect be a good way to use the network, in a way that endears it to other developers.
The first steganography plugin which would be interesting to me is (after some thought) not skype, but jingle (audio and video via Jabber).
This has three advantages:
* It is really hard to justify blocking
* It gives jingle a boost, instead of the proprietary skype
* The specs are all free
PS: Thank you for adapting the title!
New packet format makes this significantly easier, at least for packet-based transports with mid-sized packets (e.g. disguising as video streams). Skype would be difficult because it uses ridiculously small packets, but is planned eventually.
I now added a seperate wish for steganography to differenciate it from simple connection issues: http://freenet.uservoice.com/forums/8861-general/suggestions/1452285-add-steganography-hidden-connections-via-transpo?ref=comments
I use Freenet itstead of tor or similar, because I think that we might need a safe harbour for resistance against censorship, soon. Transport plugins are the only way to ensure that ISPs cannot disrupt the darknet (while keeping the general internet alive) when ordered to do so. That is why I vote on this.
Why not just maskerade as skype? Skype is encrypted, so the traffic should be quite hard to distinguish.
Why hiding freenet as other traffic is important to me: I want it to be ready before it gets blocked. Moreover: I want it to disappear from view, before people start really searching for it.
Would it be possible to add automated steganography by analyzing the traffic which doesn’t originate from freenet and then replicating that traffic? Something like synthesizing the traffic (I’m currently reading into texture synthesis from image creation).
Look at what you send other connections and replicate that for the freenet contacts.
To make that more efficient, you can replicate only certain kinds of traffic which are plausible for direct p2p connections, like voice-over-ip/skype/video-streaming(rtsp,etc.)/…. Protocols which can be identified by the port number, so it’s easy to identify them (and split their data from the IP address).
One serious problem with HTTP tunneling is that you need to be able to have incoming connections. If you only have HTTP this is unlikely, so you will only be able to connect to "normal" nodes which can forward ports and talk any protocol.
Basically allow anyone who can run a google search to get onto the network...
Right now I have to use 3rd party tools like http-tunnel or your-freedom, but the ideal would be a client that can tunnel over http itself.
If you accomplished this I think freenet would be the first p2p since all the other I've tried don't have this ability.
There's lotsa FAQ's on using HTTP CONNECT but this has to be built into the client apparently...
I'd think it would be useful to just test a list of ports normally used for
communication (ideally encrypted), so that encrypted data wouldn't draw
suspicions (and so we don't need to implement full steganography at once, but
can move towards it).
Maybe the option could include a list with the note "Only select services you
DON'T want to run!"
Some ideas, not all encrypted:
- 2190/UDP TiVoConnect Beacon
- 2593/TCP,UDP RunUO—Ultima Online server
- 3723/TCP,UDP Used by many Battle.net Blizzard games (Diablo II, Warcraft
II, Warcraft III, StarCraft)
- 3724/TCP,UDP World of Warcraft Online gaming MMORPG
- 4000/TCP,UDP Diablo II game
- 6619/TCP,UDP odette-ftps, Odette File Transfer Protocol (OFTP) over TLS/SSL
- 6891–6900/TCP,UDP Windows Live Messenger (File transfer)
- 6901/TCP,UDP Windows Live Messenger (Voice)
- 28910 Nintendo Wi-Fi Connection
(all information from
I'm sure there are more...)
(comment copied from an email)
My ISP blocks all UDP traffic between friday and monday, and between 6pm and 12pm. I have to use port 53, so I vote this!
Hey toad.. I know ISPs would be suspicious to see active HTTPS servers popping up all over their network, but outgoing HTTPS connections are very normal so ISPs wouldn't want to touch those. Also, there are alot of residential customers who do have HTTPS servers on some device (remote admin on a router, remote security cam, file server) and usually they will default to some higher port instead of 443, but regardless I'm sure ISPs would get a flood of complaints if they blocked 443.
Most ISPs have very few non-business customers who run HTTPS websites!
443 would be a great default port, because it can easily be disguised as HTTPS (just start TLS) and is many networks it is the ONLY outgoing port that would be suitable. And ISP's would have a hell of a time trying to block or filter it without disrupting all HTTPS websites.
If you use port 80 or 443, it must be valid http(s) traffic to be conform with transparent proxy caches. I have some customer who has trouble with a tax application of my gouverment, because this boy are running a vpn over a tcp with port 80 expecing this is alwais open in firewalls to reduce support amount. But a transpanert cache did not understand an crash the connection!