Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2012-02-15T17:50:28Zhttps://gitlab.torproject.org/legacy/trac/-/issues/5138"Error talking to" should not be a warn2012-02-15T17:50:28ZRoger Dingledine"Error talking to" should not be a warn```
2012-02-13 08:33:54 [warn] Error talking to x.x.x.x:3980: Connection reset by peer
```
I have a lot of these in my logs. They're not actually things we want the human operator to notice and do something about, right? Several operato...```
2012-02-13 08:33:54 [warn] Error talking to x.x.x.x:3980: Connection reset by peer
```
I have a lot of these in my logs. They're not actually things we want the human operator to notice and do something about, right? Several operators have reported them so far. I think they should be info level.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/5560'obfsproxy --version' is buggy2012-04-12T21:12:52ZGeorge Kadianakis'obfsproxy --version' is buggyobfsproxy --version does not work outside of the obfsproxy git repository:
```
$ ./obfsproxy --version
obfsproxy git
```
and even inside a git repository, it doesn't report the actual version/release, it just reports the commit hash of ...obfsproxy --version does not work outside of the obfsproxy git repository:
```
$ ./obfsproxy --version
obfsproxy git
```
and even inside a git repository, it doesn't report the actual version/release, it just reports the commit hash of HEAD.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/9255(py)obfsproxy doesn't support --version2013-07-15T14:46:21ZRoger Dingledine(py)obfsproxy doesn't support --version```
$ /usr/bin/obfsproxy --version
usage: obfsproxy [-h] [--log-file LOG_FILE]
[--log-min-severity {error,warning,info,debug}] [--no-log]
[--no-safe-logging]
{managed,obfs2,dummy,obfs3,b...```
$ /usr/bin/obfsproxy --version
usage: obfsproxy [-h] [--log-file LOG_FILE]
[--log-min-severity {error,warning,info,debug}] [--no-log]
[--no-safe-logging]
{managed,obfs2,dummy,obfs3,b64} ...
obfsproxy: error: too few arguments
```George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/14211--data-dir argument is not properly recognized.2020-06-13T03:51:34ZTrac--data-dir argument is not properly recognized.Summing up the following command does not work:
```
bin/obfsproxy --log-file=obfsproxy.log --log-min-severity=debug \
scramblesuit --data-dir=/path/to/data --password=VERYREALPASSWORD \
--dest=172.31.9.199:1195 server 0.0.0.0:80
```
...Summing up the following command does not work:
```
bin/obfsproxy --log-file=obfsproxy.log --log-min-severity=debug \
scramblesuit --data-dir=/path/to/data --password=VERYREALPASSWORD \
--dest=172.31.9.199:1195 server 0.0.0.0:80
```
The `--data-dir` if not recognized as a parameter is invoked after the obfuscation protocol.
References:
https://lists.torproject.org/pipermail/tor-talk/2015-January/036461.html
https://lists.torproject.org/pipermail/tor-talk/2015-January/036463.html
**Trac**:
**Username**: masterkorphttps://gitlab.torproject.org/legacy/trac/-/issues/9825-v returns 'unknown' for Obfsproxy.exe from '2.4.17-beta-2-pt3'2020-06-13T02:33:00Zbastik-v returns 'unknown' for Obfsproxy.exe from '2.4.17-beta-2-pt3'> obfsproxy.exe -v
prints out
> unknown
It was included in 'tor-pluggable-transports-browser-2.4.17-beta-2-pt3_en-US.exe' and its (obfsproxy.exe) checksums are:
```
SHA-1: 8690778C86542ABC3596C65EF42903E943C843A9
SHA-256: F75A997308B6...> obfsproxy.exe -v
prints out
> unknown
It was included in 'tor-pluggable-transports-browser-2.4.17-beta-2-pt3_en-US.exe' and its (obfsproxy.exe) checksums are:
```
SHA-1: 8690778C86542ABC3596C65EF42903E943C843A9
SHA-256: F75A997308B689335AEA9705BF7DF57EEA0636CB7C2EB7D75BCAC41389F0F84F
SHA-512: 89459D5189C2490C22FA63AC8509AEF8B7902B38174C73BB2902C57F73DFAFC4EC42B1C361ADDBEB019D7709882589594D94FD264FD20A2712592326596B1107
```https://gitlab.torproject.org/legacy/trac/-/issues/5639a2012-04-18T16:12:37ZTraca
**Trac**:
**Username**: malek3333
**Trac**:
**Username**: malek3333George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/5674Add --with-libevent-dir and --with-openssl-dir args, instead of using env. vars.2013-09-25T17:01:32ZGeorge KadianakisAdd --with-libevent-dir and --with-openssl-dir args, instead of using env. vars.rsavoye has prepared a patch for obfsproxy that introduces `--with-libevent-lib` and `--with-libcrypto-lib`, that do the job of '{libevent,libcrypto}_{LIBS,CFLAGS}.
note: maybe we should rename those options to match with tor's (that is...rsavoye has prepared a patch for obfsproxy that introduces `--with-libevent-lib` and `--with-libcrypto-lib`, that do the job of '{libevent,libcrypto}_{LIBS,CFLAGS}.
note: maybe we should rename those options to match with tor's (that is, `--with-libevent-dir` and `--with-openssl-dir`).George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/10244Add Bananaphone transport to obfsproxy2013-11-27T22:05:32ZTracAdd Bananaphone transport to obfsproxy
The Bananaphone transport needs tor#10243 to be completed:
https://trac.torproject.org/projects/tor/ticket/10243#ticket
After that happens then we can test and then merge the Bananaphone transport. Right now these tor#10243 related cha...
The Bananaphone transport needs tor#10243 to be completed:
https://trac.torproject.org/projects/tor/ticket/10243#ticket
After that happens then we can test and then merge the Bananaphone transport. Right now these tor#10243 related changes are here:
https://github.com/david415/obfsproxy/tree/david-bananaphone-public-options
**Trac**:
**Username**: davidGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/5679add libtool support to obfsproxy2013-09-25T17:01:58ZTracadd libtool support to obfsproxyUse libtool, rather than managing shared library compiler and linker flags manually.
**Trac**:
**Username**: rsavoyeUse libtool, rather than managing shared library compiler and linker flags manually.
**Trac**:
**Username**: rsavoyeGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/5100Add notice log level to obfsproxy2012-02-13T15:44:44ZKarsten LoesingAdd notice log level to obfsproxyWhile working on heartbeat log messages (#5083) I was wondering which log level I should use. info doesn't make much sense if we're logging sensitive information to info. warn doesn't make sense, because a heartbeat message shouldn't m...While working on heartbeat log messages (#5083) I was wondering which log level I should use. info doesn't make much sense if we're logging sensitive information to info. warn doesn't make sense, because a heartbeat message shouldn't make operators think something's wrong. Having a notice log level and making it the new default might be useful.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/6201Add obfsproxy to Tor stable repository2014-03-27T20:14:17ZproperAdd obfsproxy to Tor stable repositoryThe Tor stable repository currently contains 0.2.3.17-beta-2.
It might be a good idea to grab obfsproxy from the Tor alpha repository and to add it to the Tor stable repository.
Related to #6046.The Tor stable repository currently contains 0.2.3.17-beta-2.
It might be a good idea to grab obfsproxy from the Tor alpha repository and to add it to the Tor stable repository.
Related to #6046.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/10240Additional unit tests for obfsproxy/test/test_socks.py2015-07-27T17:57:57ZDavid Fifielddcf@torproject.orgAdditional unit tests for obfsproxy/test/test_socks.pyobfsproxy uses the Python csv module to parse SOCKS parameters. That causes it to inherit some behavior involving quotes that's not in pt-spec.txt.
Here are some tests that fail.
```
socks_args = socks.split_socks_args("key=val...obfsproxy uses the Python csv module to parse SOCKS parameters. That causes it to inherit some behavior involving quotes that's not in pt-spec.txt.
Here are some tests that fail.
```
socks_args = socks.split_socks_args("key=value\na=b")
self.assertListEqual(socks_args, ["key=value\na=b"])
socks_args = socks.split_socks_args("key=\"value\";\"key\"=value;\"key=value\";key=\"\"value\"\"")
self.assertListEqual(socks_args, ["key=\"value\"", "\"key\"=value", "\"key=value\"", "key=\"\"value\"\""])
# ValueError? I dunno.
self.assertRaises(ValueError, socks.split_socks_args, "key=endingescape\\")
self.assertRaises(ValueError, socks.split_socks_args, "=value")
```George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/14217Address translation is not working2015-03-16T03:14:57ZTracAddress translation is not workingAddress translation is not working on obfsproxy.
When running obfsproxy with OpenVPN both obfsproxy server and client need to be on the same machine was the OpenVPN server and client, so the the address used to communicate is 127.0.0.1...Address translation is not working on obfsproxy.
When running obfsproxy with OpenVPN both obfsproxy server and client need to be on the same machine was the OpenVPN server and client, so the the address used to communicate is 127.0.0.1
References:
https://forums.openvpn.net/topic17960.html
**Trac**:
**Username**: masterkorpGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/5130Allow obfsproxy to daemonize2020-06-13T01:19:17ZTracAllow obfsproxy to daemonizeI've been working on setting up obfsproxy and I ran into a minor issue: It doesn't seem possible to send the obfsproxy process into the background (i.e. daemonize it) if I'm running it as an external server and not in managed mode. If ...I've been working on setting up obfsproxy and I ran into a minor issue: It doesn't seem possible to send the obfsproxy process into the background (i.e. daemonize it) if I'm running it as an external server and not in managed mode. If I want to be able to specify the listening port for a bridge server I don't think there's a way to do this without running obfsproxy as an external server (please correct me if I'm wrong). However, there's no option to fork/detach from the terminal in the case of an external server, which seems a rather significant issue.
I've written a small patch for main.c that seems to correct this problem (see attached). This implements two command line arguments, "--daemonize", which, when specified will just send the program into the background and "--daemonize_with_pid=<pid_file>", which will daemonize and write the process id to the specified file. This patch only works on unix systems, but I've added #ifdef directives that only enable this code if unistd.h is defined, otherwise it will be completely ignored.
**Trac**:
**Username**: ericpaulbishophttps://gitlab.torproject.org/legacy/trac/-/issues/5156assertion failure at src/network.c:931: circ2020-06-13T01:16:58ZRoger Dingledineassertion failure at src/network.c:931: circMy Tor client launched obfsproxy in managed mode, configured to use the 14 obfsproxy bridges that are in the bundle. My network went down, and it looks like obfsproxy bit it when the network returned.
```
2012-02-16 21:56:13 [warn] Conn...My Tor client launched obfsproxy in managed mode, configured to use the 14 obfsproxy bridges that are in the bundle. My network went down, and it looks like obfsproxy bit it when the network returned.
```
2012-02-16 21:56:13 [warn] Connection error: No route to host
2012-02-16 21:56:13 [warn] Connection error: No route to host
2012-02-16 21:56:14 [info] [scrubbed]: socks: trying to connect to [scrubbed]:36609
2012-02-16 21:56:14 [info] [scrubbed]: socks: trying to connect to [scrubbed]:42401
2012-02-16 21:56:16 [warn] Connection error: No route to host
2012-02-16 21:56:19 [warn] Connection error: No route to host
2012-02-16 21:57:09 [info] [scrubbed]: socks: trying to connect to [scrubbed]:53999
2012-02-16 21:57:09 [error] assertion failure at src/network.c:931: circ
```
I'm not sure quite what version of obfsproxy it was, since it has no versions and no releases. It was built Feb 13 (Monday morning) at 07:30 EST, so it's presumably missing what we've committed since then.
```
#0 0x00007fa14925a475 in *__GI_raise (sig=<optimized out>)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
pid = <optimized out>
selftid = <optimized out>
#1 0x00007fa14925d6f0 in *__GI_abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0x7fff6f4278ec,
sa_sigaction = 0x7fff6f4278ec}, sa_mask = {__val = {0,
140330701343215, 140330693892389, 210380881921, 17689675,
140330693487520, 140330705588224, 17689660, 4294967295,
17689660, 1, 6361672, 0, 32, 17690208, 0}},
sa_flags = 1237092162, sa_restorer = 0x1}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x0000000000406cf9 in log_error_abort (format=<optimized out>)
at src/util.c:585
ap = {{gp_offset = 32, fp_offset = 48,
overflow_arg_area = 0x7fff6f427750,
reg_save_area = 0x7fff6f427690}}
#3 0x0000000000404a68 in pending_socks_cb (bev=0x10dee60, what=32,
arg=0x10e0df0) at src/network.c:931
down = 0x10e0df0
circ = 0x0
up = <optimized out>
socks = <optimized out>
__func__ = "pending_socks_cb"
#4 0x00007fa1499904c3 in bufferevent_socket_connect ()
from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#5 0x00007fa14999058f in ?? () from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#6 0x00007fa1499a7129 in evdns_getaddrinfo () from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#7 0x00007fa149997276 in evutil_getaddrinfo_async ()
from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#8 0x00007fa1499906c8 in bufferevent_socket_connect_hostname ()
from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#9 0x0000000000404558 in open_outbound_hostname (port=53999,
addr=0x10dec3c "109.105.109.163", af=2, conn=0x10d7060)
at src/network.c:609
base = <optimized out>
buf = 0x10dee60
newconn = 0x10e0df0
#10 socks_read_cb (bev=<optimized out>, arg=0x10d7060) at src/network.c:654
af = 2
r = <optimized out>
port = 53999
addr = 0x10dec3c "109.105.109.163"
status = <optimized out>
conn = 0x10d7060
socks_ret = <optimized out>
__func__ = "socks_read_cb"
#11 0x00007fa14998fe1d in ?? () from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#12 0x00007fa14998597c in event_base_loop () from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#13 0x00000000004032c4 in launch_managed_proxy () at src/managed.c:696
r = -1
proxy = 0x10c40d0
#14 0x00000000004028dc in obfs_main (argc=<optimized out>,
argv=<optimized out>) at src/main.c:293
begin = 0x7fff6f427cc0
#15 0x00007fa149246ead in __libc_start_main (main=<optimized out>,
argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff6f427c98)
at libc-start.c:228
result = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 3345274397001419417,
4203448, 140735060016288, 0, 0, -3345589772015203687,
-3373654480587683175}, mask_was_saved = 0}}, priv = {pad = {
0x0, 0x0, 0x40bc90, 0x7fff6f427ca8}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 4242576}}}
not_first_call = <optimized out>
#16 0x00000000004023e1 in _start ()
No symbol table info available.
```
```
(gdb) print circ
$3 = (circuit_t *) 0x0
(gdb) print *down
$2 = {cfg = 0x10d78d0, peername = 0x10df200 "109.105.109.163:53999",
circuit = 0x0, buffer = 0x10dee60, mode = LSN_SOCKS_CLIENT}
```George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/23520Assume iat-mode=0 if the input is unknown instead of failing2017-09-14T16:27:19ZcypherpunksAssume iat-mode=0 if the input is unknown instead of failingHow to reproduce:
1. Get an obfs4 bridge from BridgeDB http://z5tfsnikzulwicxs.onion/
2. In `torrc` change `iat-mode=0` or `iat-mode=1` or `iat-mode=2` with `iat-mode=मस्तेआपकै`.
3. Relaunch tor, it should fail.How to reproduce:
1. Get an obfs4 bridge from BridgeDB http://z5tfsnikzulwicxs.onion/
2. In `torrc` change `iat-mode=0` or `iat-mode=1` or `iat-mode=2` with `iat-mode=मस्तेआपकै`.
3. Relaunch tor, it should fail.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/5131auditing obfsproxy2020-06-13T01:06:43ZJacob Appelbaumauditing obfsproxyHi,
At the request of asn, I started to audit obfsproxy - I started and have been making some commits as I go along:
Here's my gcc/ld hardening one trick pony:
https://gitweb.torproject.org/user/ioerror/obfsproxy.git/commit/b3367507b46...Hi,
At the request of asn, I started to audit obfsproxy - I started and have been making some commits as I go along:
Here's my gcc/ld hardening one trick pony:
https://gitweb.torproject.org/user/ioerror/obfsproxy.git/commit/b3367507b465703762c0c6dd9816f9eef133c350
A basic start at an apparmor profile:
https://gitweb.torproject.org/user/ioerror/obfsproxy.git/commit/d1599cf358bb2471014b1aaaed2b10fe22516bc2
Spec notes:
https://gitweb.torproject.org/user/ioerror/obfsproxy.git/commit/4d0405a6269f3abf0bb862e9e0a7587cbe5fbeef
Threat model notes:
https://gitweb.torproject.org/user/ioerror/obfsproxy.git/commit/053b267d96053624daa326d3ad6171dd3763b498
Here's the full branch:
https://gitweb.torproject.org/user/ioerror/obfsproxy.git/shortlog/refs/heads/compile_hardeningGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/9824Better integration tests for Python-based obfsproxy2016-12-09T01:10:21ZGeorge KadianakisBetter integration tests for Python-based obfsproxyobfsproxy integration tests are not robust.
* We need some integration tests that check how obfpsroxy works under different managed-mode environment variables.
* The `obfsproxy/test/tester.py`, which is our basic integration test, coul...obfsproxy integration tests are not robust.
* We need some integration tests that check how obfpsroxy works under different managed-mode environment variables.
* The `obfsproxy/test/tester.py`, which is our basic integration test, could use some love.
* I once started coding PITS, an advanced integration tester for obfsproxy. You can find the design docs here: https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/blob/HEAD:/obfsproxy/test/int_tests/pits_design.txt Unfortunately, while I still like the idea, I'm not happy with its code. As a matter of fact, I have probably forgotten how it works and I should rip it off the obfsproxy codebase since it's pretty much useless.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/3473Better signal handling for obfsproxy2020-06-13T02:37:03ZGeorge KadianakisBetter signal handling for obfsproxyWe currently treat SIGINT and SIGTERM equally, by terminating obfsproxy asap.
180-pluggable-transport.txt dictates that:
Proxies should respond to a single INT signal by closing their
listener ports and not accepting any new connec...We currently treat SIGINT and SIGTERM equally, by terminating obfsproxy asap.
180-pluggable-transport.txt dictates that:
Proxies should respond to a single INT signal by closing their
listener ports and not accepting any new connections, but keeping
all connections open, then terminating when connections are all
closed. Proxies should respond to a second INT signal by shutting
down cleanly.
I think we should conform SIGINT with the 180 spec, and leave SIGTERM as is.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/3201bug in network.c:error_or_eof()2012-02-04T00:20:07ZGeorge Kadianakisbug in network.c:error_or_eof()error_or_eof() is currently setting the callbacks of conn->output statically, instead of setting the callbacks of the bufferevent to be flushed dynamically.
I'm not sure if it's a bug because I suck in libevent so I'm making this trac t...error_or_eof() is currently setting the callbacks of conn->output statically, instead of setting the callbacks of the bufferevent to be flushed dynamically.
I'm not sure if it's a bug because I suck in libevent so I'm making this trac ticket.
You can find the uber trivial fix in my bug_error_or_eof branch (sorry for the non-bugxxxx name)George KadianakisGeorge Kadianakis