Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T03:23:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/12762Orbot 14.0.5 causes LED to flash while it is running2020-06-13T03:23:11ZTracOrbot 14.0.5 causes LED to flash while it is runningSamsung Galaxy S4 / Cyanogenmod 11 M8
Orbot 14.0.5.
Problem:
After upgrading to the latest version of Orbot (14.0.5) any time the screen goes to sleep and Orbot is running, the LED on the phone will flash. This draws attention to the p...Samsung Galaxy S4 / Cyanogenmod 11 M8
Orbot 14.0.5.
Problem:
After upgrading to the latest version of Orbot (14.0.5) any time the screen goes to sleep and Orbot is running, the LED on the phone will flash. This draws attention to the phone due to the brightness of LED. Previous versions of Orbot did not display this behavior
Reproduce:
- Install Orbot
- Run Orbot
- Let screen go to sleep or manually put it to sleep
- LED starts to flash
- Wake screen and unlock, LED stops flashing
Expected outocme:
- With orbot running if screen goes to sleep, LED should not flash
**Trac**:
**Username**: torieNathan FreitasNathan Freitashttps://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/12663Orbot, libevent and BSD sed ( includes patch )2020-06-13T03:21:28ZcypherpunksOrbot, libevent and BSD sed ( includes patch )Compilation of Orbot stops at libevent if using BSD sed rather than GNU sed.
The error is :
sed -i 's@\(SUBDIRS = . include\) sample test@\1@' libevent/Makefile.am
sed: 1: "libevent/Makefile.am": extra characters at the end of l comman...Compilation of Orbot stops at libevent if using BSD sed rather than GNU sed.
The error is :
sed -i 's@\(SUBDIRS = . include\) sample test@\1@' libevent/Makefile.am
sed: 1: "libevent/Makefile.am": extra characters at the end of l command
I have traced the problem to Orbot's external/Makefile.
There is a difference between BSD and GNU sed with regards to the inplace -i flag, both accept an argument for a file extension to backup to, if no extension is provided no backup is made, however BSD sed requires an argument even if it is empty, whereas GNU sed ignores it.
The attached patch adds an extension rather than provide an empty argument, this *should* work with both GNU and BSD sed, though I haven't tried it with the former.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/12413Orbot doesn't use separate torrcs, and overrides & overwrites user-set torrcs2020-06-13T03:16:33ZIsis LovecruftOrbot doesn't use separate torrcs, and overrides & overwrites user-set torrcsYou _can_ use multiple `torrc` files simultaneously. [RTFM](https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/tor.1.txt#l52)You _can_ use multiple `torrc` files simultaneously. [RTFM](https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/tor.1.txt#l52)Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/12412Orbot broke using TransPort2020-06-13T03:16:32ZIsis LovecruftOrbot broke using TransPortOrbot (as of 14.0.3.1 and later) [sets `TransPort 0`](https://gitweb.torproject.org/orbot.git/commitdiff/2ce9ea92f14f7b5c04798809f0c262475766977e), which disables tor's `TransPort` entirely. This means that people who use iptables script...Orbot (as of 14.0.3.1 and later) [sets `TransPort 0`](https://gitweb.torproject.org/orbot.git/commitdiff/2ce9ea92f14f7b5c04798809f0c262475766977e), which disables tor's `TransPort` entirely. This means that people who use iptables scripts outside of Orbot (as described in [Mike Perry's recent blog post](https://blog.torproject.org/blog/mission-impossible-hardening-android-security-and-privacy)) to redirect TCP traffic to the `TransPort` cannot do so.
Related, see #12411.
>
> Leaks are not the problem; they are the symptom. --Heather Brooke
>Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/12411Orbot broke using DNSPort2020-06-13T03:16:31ZIsis LovecruftOrbot broke using DNSPortOrbot 14.0.3.1 completely breaks networking, if you have firewall scripts which don't allow leaks.
**THIS MEANS THAT ORBOT IS LEAKING LIKE THE FUCKING PENTAGON PAPERS, EXCEPT NOT IN A GOOD WAY.**
This is because Orbot (as of 14.0.3.1 ...Orbot 14.0.3.1 completely breaks networking, if you have firewall scripts which don't allow leaks.
**THIS MEANS THAT ORBOT IS LEAKING LIKE THE FUCKING PENTAGON PAPERS, EXCEPT NOT IN A GOOD WAY.**
This is because Orbot (as of 14.0.3.1 and later) [sets `DNSPort 0`](https://gitweb.torproject.org/orbot.git/commitdiff/2ce9ea92f14f7b5c04798809f0c262475766977e), which disables tor's `DNSPort` entirely. This means that people who use iptables scripts outside of Orbot (as described in [Mike Perry's recent blog post](https://blog.torproject.org/blog/mission-impossible-hardening-android-security-and-privacy)) to redirect UDP DNS traffic to the `DNSPort` cannot do so. It also means that _every other application will leak traffic all over the place_.
Currently, the only way to fix this mess is to force stop and uninstall Orbot, download an older (14.0.1) .apk onto another device, and copy it over manually to the broken one to reinstall it. This is ridiculous. You're practically bricking people's devices, and you're forcing them to jump through extreme hoops to preserve their anonymity.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11728Torbirdy shouldn't allow clearnet connections on startup if started in Transp...2020-06-13T03:08:46ZMatt PaganTorbirdy shouldn't allow clearnet connections on startup if started in Transparent Torification modeHere's the situation: Alice uses Torbirdy in "Transparent Torification" mode to check her email on her laptop with her Tor router at home. She later takes her laptop to an internet cafe and checks her email there. As soon as she opens Th...Here's the situation: Alice uses Torbirdy in "Transparent Torification" mode to check her email on her laptop with her Tor router at home. She later takes her laptop to an internet cafe and checks her email there. As soon as she opens Thunderbird, a connection is made in the clear to her email provider before she has a chance to change Torbirdy's settings to "Use Tor Onion Router". This is an identity leak, and Torbirdy should prevent this possibility.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/11560Orbot-v13.0.7-BETA-1: "Tor Tethering" > Warnings about Listeners on 0.0.0.02020-06-13T14:30:21ZcypherpunksOrbot-v13.0.7-BETA-1: "Tor Tethering" > Warnings about Listeners on 0.0.0.0
"
WARN: You specified a public address '0.0.0.0:9050' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
WARN: You specified a public ...
"
WARN: You specified a public address '0.0.0.0:9050' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
WARN: You specified a public address '0.0.0.0:5400' for DNSPort. Other people...
WARN: You specified a public address '0.0.0.0:9040' for TransPort. Other people...
WARN: You have a ControlPort set to accept connections from a non-local address. This means that programs not running on you computer can reconfigure you Tor. That's pretty bad, since the controller protocol isn't encrypted! Maybe you should ...
"
I assume these listeners are there due to the enabled "Tor Tethering", but wouldn't it be possible to bind these listeners to the WIFI interface only (I assume they are only needed there)?Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11559Orbot-v13.0.7-BETA-1: "Tor Tethering" not working2020-06-13T03:06:29ZcypherpunksOrbot-v13.0.7-BETA-1: "Tor Tethering" not workingHi,
I'm running the latest Orbot version [1] on a rooted Android 4.0.4 and enabled
"Tor Tethering" while enabling Internet via 3G, but the devices connecting to the hotspot are not routed over Tor (tested via checkip.dyndns.org).
Sho...Hi,
I'm running the latest Orbot version [1] on a rooted Android 4.0.4 and enabled
"Tor Tethering" while enabling Internet via 3G, but the devices connecting to the hotspot are not routed over Tor (tested via checkip.dyndns.org).
Should this work or is this a experimental feature anyway?
How can I help to debug this?
https://guardianproject.info/releases/Orbot-v13.0.7-BETA-1.apkNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11355Provide obfsproxy nightlies in our debian repositories2020-06-13T03:03:10ZGeorge KadianakisProvide obfsproxy nightlies in our debian repositoriesPeople are asking for obfsproxy nightlies (#10954). It would be brilliant if people could add our debian repo, and get the latest obfsproxy master through it.
How can I help you do this?
No hurry on this one. I mainly made this ticket ...People are asking for obfsproxy nightlies (#10954). It would be brilliant if people could add our debian repo, and get the latest obfsproxy master through it.
How can I help you do this?
No hurry on this one. I mainly made this ticket because #10954 was not very specific.
Thanks!LunarLunarhttps://gitlab.torproject.org/legacy/trac/-/issues/11354Make obfsproxy more fork-friendly2020-06-13T03:07:31ZGeorge KadianakisMake obfsproxy more fork-friendlyPTs need to support a few PT interfaces. For example:
a) The managed-mode PT configuration protocol
b) SOCKS support (also support for proposal229)
c) Extended ORPort (and eventually TransportControlPort)
d) Proxy support to connect to p...PTs need to support a few PT interfaces. For example:
a) The managed-mode PT configuration protocol
b) SOCKS support (also support for proposal229)
c) Extended ORPort (and eventually TransportControlPort)
d) Proxy support to connect to proxies
pyptlib can help with (a), but does nothing about the other points (e.g. check #7903).
It has been suggested that instead of trying to fit those features in pyptlib, we instead implement them in obfsproxy, and suggest to people to use obfsproxy to developer their PTs.
However, it is the case that obfsproxy is optimized for the "app that supports multiple PTs" use case, and not for the "app that can be forked to support your PT".
If we get more people interested in writing PTs, it might make sense to start designing/fork obfsproxy with that use case in mind.https://gitlab.torproject.org/legacy/trac/-/issues/11245Orbot bootstraped problem2020-06-13T03:00:57ZTracOrbot bootstraped problemOn my un rooted samsung galaxy note 10.1 Orbot only gets to bootstrapped 25%.
My system information:
Android version: 4.1.2
Model Number: GT - N8010
Log:
Orbot is starting…
Orbot is starting…
Tor binary exists: /data/data/org.torproje...On my un rooted samsung galaxy note 10.1 Orbot only gets to bootstrapped 25%.
My system information:
Android version: 4.1.2
Model Number: GT - N8010
Log:
Orbot is starting…
Orbot is starting…
Tor binary exists: /data/data/org.torproject.android/lib/libtor.so
Privoxy binary exists: /data/data/org.torproject.android/lib/libprivoxy.so
Obfsproxy binary exists: /data/data/org.torproject.android/lib/libobfsproxy.so
Xtables binary exists: /data/data/org.torproject.android/lib/libxtables.so
link RM err=0 out:
link LN err=0 out:
libtor.so: PRE: Is binary exec? true
(re)Setting permission on binary: /data/data/org.torproject.android/lib/libtor.so
libtor.so: POST: Is binary exec? true
tor: PRE: Is binary exec? true
(re)Setting permission on binary: /data/data/org.torproject.android/app_bin/tor
tor: POST: Is binary exec? true
libprivoxy.so: PRE: Is binary exec? true
(re)Setting permission on binary: /data/data/org.torproject.android/lib/libprivoxy.so
libprivoxy.so: POST: Is binary exec? true
libobfsproxy.so: PRE: Is binary exec? true
(re)Setting permission on binary: /data/data/org.torproject.android/lib/libobfsproxy.so
libobfsproxy.so: POST: Is binary exec? true
libxtables.so: PRE: Is binary exec? true
(re)Setting permission on binary: /data/data/org.torproject.android/lib/libxtables.so
libxtables.so: POST: Is binary exec? true
Orbot is starting…
got tor proc id: 21351
Tor process id=21351
Connecting to control port: 9051
SUCCESS connected to control port
SUCCESS authenticated to control port
Starting Tor client… complete.
adding control port event handler
SUCCESS added control port event handler
updating settings in Tor service
Starting privoxy process
/data/data/org.torproject.android/lib/libprivoxy.so /data/data/org.torproject.android/app_bin/privoxy.config &
orConnStatus (madiba): LAUNCHED
NOTICE: Bootstrapped 10%: Finishing handshake with directory server.
Privoxy is running on port:8118
Privoxy process id=21371
NOTICE: Bootstrapped 15%: Establishing an encrypted directory connection.
orConnStatus (itpol2): CONNECTED
orConnStatus (madiba): CONNECTED
NOTICE: Bootstrapped 20%: Asking for networkstatus consensus.
Circuit (1) BUILT: itpol2
NOTICE: I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.
Circuit (2) BUILT: madiba
NOTICE: Bootstrapped 25%: Loading networkstatus consensus.
Circuit (2) CLOSED: madiba
NOTICE: I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.
**Trac**:
**Username**: isaac868Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11203ScrambleSuit CSPRNG for Probability Distributions2020-06-13T03:00:09ZYawning AngelScrambleSuit CSPRNG for Probability DistributionsAs discussed in #10893, ScrambleSuit should use a CSPRNG when generating/sampling the probability distributions for the packet length and inter packet arrival times.
I have went ahead and implemented this in a branch at https://github.c...As discussed in #10893, ScrambleSuit should use a CSPRNG when generating/sampling the probability distributions for the packet length and inter packet arrival times.
I have went ahead and implemented this in a branch at https://github.com/yawning/obfsproxy/tree/ctr_drbg
It appears to work though packet distributions for existing bridges will change when they update to use the new PRNG (for obvious reasons). There also are some unit tests that use the NIST AES CTR test vectors to make sure that the bytes that are expected to come out with a given key/initial counter do.
phw said I should be doing development vs the scramblesuit repo, but since the plan is to fold the repo with history into obfsproxy, I did it the other way. If needed, I will move the ctr_drbg module into scramblesuit/transports and make a scramblesuit branch for this, but since it's not a critical thing, merging this can wait till after the repo madness is done.https://gitlab.torproject.org/legacy/trac/-/issues/11197obfsproxy should provide congestion feedback2020-06-13T02:59:59ZYawning Angelobfsproxy should provide congestion feedbackI went over this in IRC tonight to a poor GSOC student who was thinking about doing a CBR plugin, so I'll file a bug while it's fresh on my mind.
Currently there is nothing in place to prevent unbound buffer growth in obfsproxy. This p...I went over this in IRC tonight to a poor GSOC student who was thinking about doing a CBR plugin, so I'll file a bug while it's fresh on my mind.
Currently there is nothing in place to prevent unbound buffer growth in obfsproxy. This problem arises when the bottleneck link is extremely narrow.
For example, examine the following network topology:
Client <-> obfsproxy <-> 14.4 kbit modem <-> ISP <-> 100 Mbit <-> obfsproxy <-> Server
The Client opens a connection, and initiates a bulk download from the Server. Since there is no mechanism to indicate congestion, the outgoing buffer in the Server side obfsproxy process will grow because feedback from the Client in the form of the shrinking TCP/IP receive window will not get propagated.
The same thing will happen on the Client side with a bulk upload, because the loopback interface has a gigantic amount of bandwidth compared to the bottleneck link.
Twisted connections have a producer/consumer interface (and can handle stopping reading once the send buffer reaches a certain threshold 'self.bufferSize'), so refactoring the base transport to use this interface to glue the upstream/downstream together would be the "correct" approach to solving this problem.
See https://twistedmatrix.com/documents/current/core/howto/producers.html for more details.https://gitlab.torproject.org/legacy/trac/-/issues/11190obfsproxy shebang should point to "python2", not "python"2020-06-13T02:59:48ZYawning Angelobfsproxy shebang should point to "python2", not "python"It currently points at "python" which is not version specific and will break horribly on systems where the default system python is python3.
This isn't a issue when it is installed with setup.py, but was when I tried a TBB nightly a few...It currently points at "python" which is not version specific and will break horribly on systems where the default system python is python3.
This isn't a issue when it is installed with setup.py, but was when I tried a TBB nightly a few days ago. As far as I can tell every system that has python2.x installed with have a "python2" symlink so changing the shebang won't break places where this works now, but will allow it to work on more systems without breaking in horrible unintuitive ways for the user.https://gitlab.torproject.org/legacy/trac/-/issues/11134obfsproxy's SOCKS server should send success response post handshake2020-06-13T14:34:35ZYawning Angelobfsproxy's SOCKS server should send success response post handshakeCurrently the obfsproxy SOCKS server sends the response back to tor immediately after the TCP/IP connection has been established, instead of after the underlying transport has been fully initialized.
This behavior is incorrect, and shou...Currently the obfsproxy SOCKS server sends the response back to tor immediately after the TCP/IP connection has been established, instead of after the underlying transport has been fully initialized.
This behavior is incorrect, and should be changed to each of the underlying transports signalling that they are ready to relay data after they manage to handshake.
With the current SOCKSv4Protocol based listener this would require further monkey patching which may be a good argument for defering this till after #9221 or similar gets merged.https://gitlab.torproject.org/legacy/trac/-/issues/11093obfsproxy should use C implementation of UniformDH2020-06-13T02:57:56ZGeorge Kadianakisobfsproxy should use C implementation of UniformDHWe are currently using a C implementation of UniformDH that is quite slow (even with gmpy2 for mod exp).
Yawning implemented UniformDH in C using OpenSSL and we should use his library.
He posted an obfsproxy patch in #11015 :
https://t...We are currently using a C implementation of UniformDH that is quite slow (even with gmpy2 for mod exp).
Yawning implemented UniformDH in C using OpenSSL and we should use his library.
He posted an obfsproxy patch in #11015 :
https://trac.torproject.org/projects/tor/attachment/ticket/11015/0001-Add-support-for-using-py-uniformdh.patch
And the implementation can be found in:
https://github.com/Yawning/py-uniformdhhttps://gitlab.torproject.org/legacy/trac/-/issues/11050pycrypto's AES implementation is not constant time2020-06-13T02:57:18ZYawning Angelpycrypto's AES implementation is not constant timeThis is a non-issue when AES-NI is supported by the host CPU since a separate code path is taken.
https://github.com/dlitz/pycrypto/blob/master/src/AES.c
It's not too bad in the pluggable transport case since traffic is super-enciphere...This is a non-issue when AES-NI is supported by the host CPU since a separate code path is taken.
https://github.com/dlitz/pycrypto/blob/master/src/AES.c
It's not too bad in the pluggable transport case since traffic is super-enciphered, the session keys are ephemeral, and actually extracting sufficiently accurate timing information is probably non-trivial, but it probably should be addressed somehow.https://gitlab.torproject.org/legacy/trac/-/issues/10874TorButton won't "blink" for update if using local Tor2020-06-13T02:54:08ZcypherpunksTorButton won't "blink" for update if using local TorWhen using a local Tor and setting TorLauncher not to spawn Tor (about:config, extensions.torlauncher.start_tor is false, as is extensions.torlauncher.prompt_at_startup), the TorButton turns into a big 'X' and doesn't tell me about updat...When using a local Tor and setting TorLauncher not to spawn Tor (about:config, extensions.torlauncher.start_tor is false, as is extensions.torlauncher.prompt_at_startup), the TorButton turns into a big 'X' and doesn't tell me about updates. Even if I had no Tor at all, I still need security updates!
In any case, I still am using Tor. I am using a local system Tor, I do not want to connect twice and I like to manage my bridges and everything else in one place. Thanks!https://gitlab.torproject.org/legacy/trac/-/issues/10836Enable mail account autoconfig dialog in TorBirdy2020-06-13T02:53:26ZTracEnable mail account autoconfig dialog in TorBirdyCurrently, TorBirdy entirely blocks the mail account autoconfig dialog in Thunderbird. It requires the user to manually configure the mail account servers.
-----
This is suboptimal, because the declared goal of TorBirdy is to reach com...Currently, TorBirdy entirely blocks the mail account autoconfig dialog in Thunderbird. It requires the user to manually configure the mail account servers.
-----
This is suboptimal, because the declared goal of TorBirdy is to reach common users (not geeks), and common users have massive problems with this configuration. This is why they use webmail, and why we write this dialog to help them with Thunderbird - they simply *can't* do it alone.
Furthermore, if they try to find the settings themselves on the web, they
* expose themselves to similar or worse phishing attempts (if you can serve a bad config XML file, you can serve a bad HTML documentation page)
* more importantly, the mail configs published by the ISPs are often without encryption.
With the ISPDB, I took great care to find and use the best config that an ISP offers, esp. SSL and encrypted passwords, even if that config is undocumented and not officially supported. In a way, you could compare the ISPDB with HTTPS Everywhere, because it performs a similar function (use SSL where possible, even if not advertized by site) and even similar means (HTTPS Everywhere communicates with some central servers, just like the Mozilla ISPDB).
Thus, I think disabling the autoconfig dialog does users a dis-service not only in convenience and usability (in the literal sense of the word), but more importantly in security, because we know about SSL configs that users might not know or find.
-----
The reason why the autoconfig dialog was disabled were some HTTP (without SSL) calls and direct socket calls.
Thus, in Mozilla bug 669282 [1], I attached a patch to disable them. I wrote this patch specifically for TorBirdy.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=669282
**Trac**:
**Username**: ben