Though obfsproxy is hosted by tor project, it doesn't rely on tor when running or compiling. And it is pointed out that obfsproxy is a separate application in its project page: https://www.torproject.org/projects/obfsproxy Reproducible: Always
(In reply to comment #0) > Though obfsproxy is hosted by tor project, it doesn't rely on tor when > running or compiling. > > And it is pointed out that obfsproxy is a separate application in its > project page: https://www.torproject.org/projects/obfsproxy > > Reproducible: Always Understood, but would you ever rung obfsproxy on your system *without* tor. Is there a use case?
(In reply to comment #1) > Understood, but would you ever rung obfsproxy on your system *without* tor. > Is there a use case? Yes. For example it can be used to obfuscate the traffic of ssh/openvpn, as described in http://www.void.gr/kargig/blog/2012/10/05/bypassing-censorship-devices-by-obfuscating-your-traffic-using-obfsproxy/
okay done. but before i close this bug, if you think people will be using obfsproxy as a stand alone, we may want to set up init scripts for it. What do you think?
(In reply to comment #3) > okay done. but before i close this bug, if you think people will be using > obfsproxy as a stand alone, we may want to set up init scripts for it. What > do you think? I once tried to write a init script. But obfsproxy cannot read a config file, and its command line arguments varies according to the protocal you want to use. For example, currently two protocals are available in obfsproxy: dummy and obfs2. The command line are as follow: obfsproxy dummy server 192.168.1.99:11253 127.0.0.1:9005 obfsproxy obfs2 --dest=127.0.0.1:666 --shared-secret=himitsu server 127.0.0.1:1026 So it's hard to make the config file to meet this arguments (and there are more protocals using different arguments may appear!). Or we can simply let user write down all arguments he want in the configuration file (which is a bit ugly). What' your opinion?
(In reply to comment #4) > (In reply to comment #3) > > okay done. but before i close this bug, if you think people will be using > > obfsproxy as a stand alone, we may want to set up init scripts for it. What > > do you think? > > I once tried to write a init script. But obfsproxy cannot read a config > file, and its command line arguments varies according to the protocal you > want to use. > > For example, currently two protocals are available in obfsproxy: dummy and > obfs2. The command line are as follow: > obfsproxy dummy server 192.168.1.99:11253 127.0.0.1:9005 > obfsproxy obfs2 --dest=127.0.0.1:666 --shared-secret=himitsu server > 127.0.0.1:1026 > > So it's hard to make the config file to meet this arguments (and there are > more protocals using different arguments may appear!). > > Or we can simply let user write down all arguments he want in the > configuration file (which is a bit ugly). > > What' your opinion? PROTOCOL is set in /etc/conf.d/obfsproxy and then in /etc/init.d/obfsproxy we have if [ ${PROTOCOL} = "dummy" ] ; then CMDLINE="...." elif [ ${PROTOCOL} = "obfs2" ] ; then CMDLINE="...." else eend 1 fi start-stop-daemon --start --pidfile "${PIDFILE}" --quiet --exec ${OBFSPROXY} -- ${CMDLINE} Give it a go, see if you can make it work.
oh wait, you said there might even be more than coming? In that case case ${PROTOCOL} in dummy) CMDLINE="...." ;; obfs2) CMDLINE="...." ;; *) eend 1 ;; ecas This is easily expanded.
Okay obfsproxy-0.1.4-r1 is int the tree with init scripts. Please give it a test.
(In reply to comment #7) > Okay obfsproxy-0.1.4-r1 is int the tree with init scripts. Please give it a > test. Well, I am busy these two days, so I am not working on the init script... And, thanks for your script. It works perfectly! Closing this bug.
