Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2014-04-08T19:30:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/11451Add new fteproxy bridges to the Tor Browser2014-04-08T19:30:22ZkpdyerAdd new fteproxy bridges to the Tor BrowserI've added three new fteproxy bridges, please merge:
https://github.com/kpdyer/tor-browser-bundle/commit/81dad04a36d085b9181cbb77eb7fbe0b87f96685
Thanks!I've added three new fteproxy bridges, please merge:
https://github.com/kpdyer/tor-browser-bundle/commit/81dad04a36d085b9181cbb77eb7fbe0b87f96685
Thanks!kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/11487FTEproxy should (maybe) select the regex on each Bridge line2014-04-28T18:58:52ZXimin LuoFTEproxy should (maybe) select the regex on each Bridge lineKevin thinks it would be nice to have the FTE regex specified on the Bridge line. However, I am confused by the subsequent discussion we had.
I originally suggested this, because I thought each server has their own regex-pair (one for r...Kevin thinks it would be nice to have the FTE regex specified on the Bridge line. However, I am confused by the subsequent discussion we had.
I originally suggested this, because I thought each server has their own regex-pair (one for reading, writing), sort of like a scramblesuit shared-secret. Then, each client needs a separate regex-pair, per Bridge line.
However, there is apparently a negotiation step to determine the actual regex-pair used:
18:50:01 <kpdyer_> the first upstream message is always a message encoded with some regex and contains a negotiation message
18:50:16 <kpdyer_> that message contains the exact upstream/downstream regexs that will be used for the session
In this case, if the negotiation happens *independently* of what the Bridge is, then
a) what does the command-line regex mean? the regex for the initial negotiation message?
b) it would be *inappropriate* to set this on the Bridge line, in which case please close this ticket as invalid.
It would be more appropriate to tell the user to edit their ClientTransportPlugin line (the current behaviour), since the regex that avoids blocking would be *dependent* on their own network, and *not* the Bridges that they want to connect to. Or even better, try multiple initial regexes and use the one that works.kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/11637libfte link failure.2014-04-28T19:14:30ZYawning Angellibfte link failure.Linking fails on my system due to missing `-fPIC`.
```
g++ -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro build/temp.linux-x86_64-2.7/fte/rank_unrank.o build/temp.linux-x86_64-2.7/fte/cDFA.o -Lthirdparty/re2/obj -Lthirdpart...Linking fails on my system due to missing `-fPIC`.
```
g++ -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro build/temp.linux-x86_64-2.7/fte/rank_unrank.o build/temp.linux-x86_64-2.7/fte/cDFA.o -Lthirdparty/re2/obj -Lthirdparty/gmp/bin -Lthirdparty/gmp/lib -L/usr/lib -lgmp -lpython2.7 -o build/lib.linux-x86_64-2.7/fte/cDFA.so thirdparty/re2/obj/libre2.a -Wl,-undefined,dynamic_lookup
/usr/bin/ld: build/temp.linux-x86_64-2.7/fte/rank_unrank.o: relocation R_X86_64_PC32 against symbol `_ZN3DFA21getNumWordsInLanguageEjj' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
error: command 'g++' failed with exit status 1
```
Adding `'-fPIC'` to `extra_compile_args` in setup.py fixes it for me.kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/11629FTE breaks with latest obfsproxy (because of move to SOCKS5)2014-05-11T18:43:41ZGeorge KadianakisFTE breaks with latest obfsproxy (because of move to SOCKS5)Hello,
Arturo was trying to setup FTE in his OONI machine today. In his attempts, FTE would crash when Tor tried to spawn it.
Here is what Arturo told me during his debugging session:
```
16:29 < asn> 16:07 < hellais> I get a useful er...Hello,
Arturo was trying to setup FTE in his OONI machine today. In his attempts, FTE would crash when Tor tried to spawn it.
Here is what Arturo told me during his debugging session:
```
16:29 < asn> 16:07 < hellais> I get a useful error message
16:29 < asn> 16:08 < hellais> AttributeError: 'module' object has no attribute 'SOCKSv4Factory'
16:29 < asn> 16:08 < hellais> could it be that I have an outdated version of obfsproxy?
16:29 < asn> 16:11 < hellais> oh no, I have a too new version of obfsproxy
16:29 < asn> 16:12 < hellais> I think that obfsproxy.network.socks.OBFSSOCKSv4Factor used to be called obfsproxy.network.socks.SOCKSv4Factor
16:29 < asn> 16:13 < hellais> actually all the SOCKSv4 stuff got removed in the last version of obfsproxy wereas they used to be present
16:29 < asn> 16:13 < hellais> so users of the old API will break
16:29 < asn> 16:14 < hellais> I would suggest you add into the obfsproxy.network.socks a subclass of OBFSSOCKSv5Factory called SOCKSv5Factory that writes a warning log stating that it's now deprecated
```
We recently moved from SOCKS4 to SOCSK5 on obfsproxy, and I forgot that FTE was borrowing code from obfsproxy, so we accidentally broke FTE. Sorry for that.
kpdyer, how would you like to fix this?kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/17996make a deb of fteproxy and get into Debian2016-04-25T13:04:46Zanadahzmake a deb of fteproxy and get into Debianhttps://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/FteEvaluationhttps://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/FteEvaluationkpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/12677fteproxy server's response to malformed messages2020-06-13T03:21:42Zkpdyerfteproxy server's response to malformed messagesRaised here: https://trac.torproject.org/projects/tor/ticket/12673
cypherpunks suggests that fteproxy, when using an HTTP regex, should tolerate a range of HTTP headers. Specifically, an fteproxy server when using HTTP will terminate th...Raised here: https://trac.torproject.org/projects/tor/ticket/12673
cypherpunks suggests that fteproxy, when using an HTTP regex, should tolerate a range of HTTP headers. Specifically, an fteproxy server when using HTTP will terminate the connection, if the following is submitted:
```
GET /<encoded_data> HTTP/1.1\r\n
Host: tpo.org\r\n
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip, deflate\r\n
Connection: keep-alive\r\n
\r\n
```
It turns out that this is a complex issue to solve in general, as one solution we could allow custom error handlers in fteproxy that are activated under certain cases.
As a step towards this, we should probably distinguish between the following two cases:
* The server receives a message that is in the language specified by the regex, but is malformed.
* The server receives a message that is NOT in the language specified by the regex, and is, by definition, malformed.
Thoughts?kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/21436fteproxy does not work on Debian stretch / document fteproxy usage on Debian ...2020-06-13T06:03:15Zadrelanosfteproxy does not work on Debian stretch / document fteproxy usage on Debian stretchUsing fteproxy on Debian stretch isn't straight easy. So far no luck.
From `/lib/systemd/system/tor@default.service`, the AppArmor profile gets into the way.
```
AppArmorProfile=system_tor
```
Also the other systemd hardening results ...Using fteproxy on Debian stretch isn't straight easy. So far no luck.
From `/lib/systemd/system/tor@default.service`, the AppArmor profile gets into the way.
```
AppArmorProfile=system_tor
```
Also the other systemd hardening results in.
> `Could not launch managed proxy executable at '/usr/bin/fteproxy' ('Permission denied').`
```
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
```
Even with all of that disabled, Tor does not successfully bootstrap.
```
Feb 11 06:26:01.000 [notice] Bootstrapped 5%: Connecting to directory server
Feb 11 06:26:01.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Feb 11 06:26:01.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 6; recommendation warn; host redacted at IP:PORT)
Feb 11 06:26:01.000 [warn] 6 connections have failed:
```
I guess my torrc config is fine. Copied that part over from TBB to system Tor /etc/tor/torrc.
```
UseBridges 1
ClientTransportPlugin fte exec /usr/bin/fteproxy --managed
Bridge fte IP:PORT redacted
```
Any hints what I am doing wrong? (Not in a censored area. TBB without bridges as well as fteproxy works for me. Debian stretch system Tor with Debian fteproxy packages does not work for me.)
I am asking for Whonix integration purposes.kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/20302FTE compilation in our gitian setup is broken for Windows with GCC 6.2.02020-06-13T07:28:24ZGeorg KoppenFTE compilation in our gitian setup is broken for Windows with GCC 6.2.0After #13893 landed (bump mingw-w64 and GCC to 6.2.0) it turns out that FTE compilation is broken:
```
+ make
wine /home/ubuntu/install/python/python.exe setup.py build_ext -c mingw32
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
...After #13893 landed (bump mingw-w64 and GCC to 6.2.0) it turns out that FTE compilation is broken:
```
+ make
wine /home/ubuntu/install/python/python.exe setup.py build_ext -c mingw32
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
running build_ext
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x81b6 ignored
building 'fte.cDFA' extension
creating build
creating build\temp.win32-2.7
creating build\temp.win32-2.7\Release
creating build\temp.win32-2.7\Release\fte
C:\windows\gcc.exe -mno-cygwin -mdll -O -Wall -Ifte -Ithirdparty/gmp/include -IZ:\home\ubuntu\install\python\include -IZ:\home\ubuntu\install\python\PC -c fte/rank_unrank.cc -o build\temp.win32-2.7\Release\fte\rank_unrank.o -O3 -fPIC
Exception WindowsError: (6, 'Invalid handle') in <bound method Popen.__del__ of <subprocess.Popen object at 0x00159130>> ignored
C:\windows\gcc.exe -mno-cygwin -mdll -O -Wall -Ifte -Ithirdparty/gmp/include -IZ:\home\ubuntu\install\python\include -IZ:\home\ubuntu\install\python\PC -c fte/cDFA.cc -o build\temp.win32-2.7\Release\fte\cdfa.o -O3 -fPIC
In file included from /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include/c++/6.2.0/math.h:36:0,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/pyport.h:325,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/Python.h:58,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc:1:
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/include/c++/6.2.0/cmath:1133:11: error: '::hypot' has not been declared
using ::hypot;
^~~~~
In file included from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/Python.h:80:0,
from /home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc:1:
/home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc: In function 'void initcDFA()':
/home/ubuntu/.wine/dosdevices/z:/home/ubuntu/install/python/include/object.h:767:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
/home/ubuntu/.wine/dosdevices/z:/home/ubuntu/build/libfte/fte/cDFA.cc:273:5: note: in expansion of macro 'Py_INCREF'
Py_INCREF(&DFAType);
^~~~~~~~~
Exception WindowsError: (6, 'Invalid handle') in <bound method Popen.__del__ of <subprocess.Popen object at 0x00159150>> ignored
error: command 'gcc' failed with exit status 1
fixme:msvcrt:__clean_type_info_names_internal (0x1d114810) stub
fixme:msvcrt:__clean_type_info_names_internal (0xa254f0) stub
fixme:msvcrt:__clean_type_info_names_internal (0x100d4460) stub
fixme:msvcrt:__clean_type_info_names_internal (0x42ba30) stub
fixme:msvcrt:__clean_type_info_names_internal (0x1e24c178) stub
make: *** [fte/cDFA.pyd] Error 1
```kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/18495Mac OS: reorganize FTE packaging2020-06-16T01:02:55ZMark SmithMac OS: reorganize FTE packagingTo finish #13252 and #6540, we need to change the way the FTE client is packaged in Tor Browser. Specifically, to meet Apple's Gatekeeper code signing requirements we should put all of the files that do not contain compiled object code (...To finish #13252 and #6540, we need to change the way the FTE client is packaged in Tor Browser. Specifically, to meet Apple's Gatekeeper code signing requirements we should put all of the files that do not contain compiled object code (e.g., the Python scripts) under:
TorBrowser.app/Contents/Resources/TorBrowser/Tor/PluggableTransports/fte/
and we should put all of the binaries (compiled executables and shared libraries) under:
TorBrowser.app/Contents/MacOS/Tor/PluggableTransports/fte/
Kevin -- it would be very helpful to have your assistance with this task. Kathy and I have limited Python knowledge and very little FTE knowledge.kpdyerkpdyerhttps://gitlab.torproject.org/legacy/trac/-/issues/28521fte is not working using default tor browser bridges2021-03-27T04:55:11Zboklmfte is not working using default tor browser bridgesWhen running fte using Tor Browser nightly, with the following bridges configured in torrc:
```
Bridge fte 128.105.214.163:8080 A17A40775FBD2CA1184BF80BFC330A77ECF9D0E9
Bridge fte 131.252.210.150:8080 0E858AC201BF0F3FA3C462F64844CBFFC729...When running fte using Tor Browser nightly, with the following bridges configured in torrc:
```
Bridge fte 128.105.214.163:8080 A17A40775FBD2CA1184BF80BFC330A77ECF9D0E9
Bridge fte 131.252.210.150:8080 0E858AC201BF0F3FA3C462F64844CBFFC7297A42
Bridge fte 128.105.214.162:8080 FC562097E1951DCC41B7D7F324D88157119BB56D
Bridge fte 128.105.214.161:8080 1E326AAFB3FCB515015250D8FCCC8E37F91A153B
```
We are getting the following log:
```
Nov 18 22:57:29.200 [notice] Tor 0.4.0.0-alpha-dev (git-bf82389e198a0cc6) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Nov 18 22:57:29.200 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 18 22:57:29.200 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Nov 18 22:57:29.200 [notice] Tor is running with Rust integration. Please report any bugs you encounter.
Nov 18 22:57:29.200 [notice] Read configuration file "/tmp/s8NAO70li5".
Nov 18 22:57:29.200 [notice] Read configuration file "/home/tbb-testsuite/tbb-testsuite/tmp/4vi3CfW2Ri/tor-browser_ar/Browser/TorBrowser/Data/Tor/torrc".
Nov 18 22:57:29.202 [notice] Opening Socks listener on 127.0.0.1:9550
Nov 18 22:57:29.202 [notice] Opened Socks listener on 127.0.0.1:9550
Nov 18 22:57:29.202 [notice] Opening Control listener on 127.0.0.1:9551
Nov 18 22:57:29.202 [notice] Opened Control listener on 127.0.0.1:9551
Nov 18 22:57:29.000 [notice] Parsing GEOIP IPv4 file /home/tbb-testsuite/tbb-testsuite/tmp/4vi3CfW2Ri/tor-browser_ar/Browser/TorBrowser/Data/Tor/geoip.
Nov 18 22:57:29.000 [notice] Bootstrapped 0%: Starting
Nov 18 22:57:29.000 [notice] Starting with guard context "bridges"
Nov 18 22:57:29.000 [notice] Delaying directory fetches: No running bridges
Nov 18 22:57:31.000 [notice] Bootstrapped 5%: Connecting to directory server
Nov 18 22:57:31.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Nov 18 22:57:31.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:57:31.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:32.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:57:32.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:34.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:57:34.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:37.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:39.000 [notice] New control connection opened from 127.0.0.1.
Nov 18 22:57:39.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:57:39.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:41.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:46.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:46.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:57:53.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:55.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:57:58.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:58:00.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:58:01.000 [warn] Proxy Client: unable to connect to 128.105.214.161:8080 ("TTL expired")
Nov 18 22:58:06.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:58:07.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:58:09.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:58:09.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:58:13.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:58:13.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:58:33.000 [warn] Proxy Client: unable to connect to 128.105.214.161:8080 ("TTL expired")
Nov 18 22:58:43.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:58:43.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:58:57.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:59:13.000 [warn] Proxy Client: unable to connect to 128.105.214.161:8080 ("TTL expired")
Nov 18 22:59:31.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:59:37.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 22:59:49.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 22:59:59.000 [warn] Proxy Client: unable to connect to 128.105.214.161:8080 ("TTL expired")
Nov 18 23:00:09.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 23:00:30.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 23:00:54.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 23:00:55.000 [warn] Proxy Client: unable to connect to 128.105.214.161:8080 ("TTL expired")
Nov 18 23:00:59.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 23:01:32.000 [warn] Proxy Client: unable to connect to 128.105.214.161:8080 ("TTL expired")
Nov 18 23:01:41.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 23:02:17.000 [warn] Proxy Client: unable to connect to 128.105.214.163:8080 ("Connection refused")
Nov 18 23:02:18.000 [warn] Proxy Client: unable to connect to 128.105.214.161:8080 ("TTL expired")
Nov 18 23:02:29.000 [warn] Proxy Client: unable to connect to 128.105.214.162:8080 ("Connection refused")
Nov 18 23:02:40.000 [notice] Catching signal TERM, exiting cleanly.
```kpdyerkpdyer