Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:16:09Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23959Задолбало ваше пидарство!2020-06-13T15:16:09ZTracЗадолбало ваше пидарство!Доброе время суток!
У меня складывается стойкое впечатление, что вы и ваша анонимная сеть
TOR работаете на мировые спецслужбы, т. к.:
1. Происходит очевидный перехват трафика TOR, что проявляется в
длительном первоначальном установлени...Доброе время суток!
У меня складывается стойкое впечатление, что вы и ваша анонимная сеть
TOR работаете на мировые спецслужбы, т. к.:
1. Происходит очевидный перехват трафика TOR, что проявляется в
длительном первоначальном установлении соединений, длительность ожидания
может быть несколько минут, а также в периодических частых сбросах
соединений!!!
2. Для Ubuntu 16.04 снова не работают obfs4proxy и обычные мосты для
сборки TOR daemon!!! Как же вы заебали с вашим пидарством, уроды!!! У
вас кривые руки или вы сознательно это делаете? А может вы
предоставляете исходные тексты спецслужбам и они мне подсовывают сборку
TORa, собранную спецслужбами, а не вами? Я, если честно, больше
объяснений не нахожу.
3. Когда у вас начнут расти руки не из вашей жопы, а из нужного места?
Или вам за это хорошо платят мировые спецслужбы?
Жду от вас, хитрожопые, ответа!
Никитушкин Андрей.
**Trac**:
**Username**: avnhttps://gitlab.torproject.org/legacy/trac/-/issues/22860Ubuntu 16.04 apparmor policy blocks obfs4proxy without modification2020-06-13T18:35:24ZTracUbuntu 16.04 apparmor policy blocks obfs4proxy without modificationMoving the discussion from https://trac.torproject.org/projects/tor/ticket/14014#comment:5 to avoid recycling an old issue.
As reported by @alimj in #14014, on a Ubuntu 16.04 system with Tor 0.3.0.9 (git-100816d92ab5664d), the latest re...Moving the discussion from https://trac.torproject.org/projects/tor/ticket/14014#comment:5 to avoid recycling an old issue.
As reported by @alimj in #14014, on a Ubuntu 16.04 system with Tor 0.3.0.9 (git-100816d92ab5664d), the latest release at the time of writing, AppArmor will block obfs4proxy from operating unless the `/etc/apparmor.d/abstractions/tor` entries for the obfs4proxy binaries are changed from `PUx` to `ix`.
[Streisand](https://github.com/jlund/streisand) is currently carrying a [a workaround patch](https://github.com/jlund/streisand/blob/5cab34a22892666eeba9411b810f9d039706ba56/playbooks/roles/tor-bridge/tasks/main.yml#L50:L66) that I would love to remove :-)
Frustratingly while this fix works I can't easily demonstrate that it is required. I've increased the verbosity of the tor daemon to `debug` and don't see any failure messages, but configuring a tor browser client fails. I've also tried updating my `torrc` `ServerTransportPlugin` config line to add `--enableLogging -logLevel=debug` to the obfs4 exec but it doesn't seem to produce any logs indicating failure either, probably because apparmor is preventing it from executing at all. I also don't see any audit messages from the apparmor profile in dmesg or the systemd journal. Changing the abstractions file entries to `ix` and running `apparmor_parser -r /etc/apparmor.d/system_tor && systemctl restart tor` is enough to fix the configured Tor browser client that fails without the modification.
How can I help resolve this bug upstream? Is there someone more familiar with AppArmor that could explain the intention of the `PUx` modifiers present in the debian package's abstractions file? I do not have much experience debugging tor and would happily provide more information with guidance.
Thanks! -- @cpu
**Trac**:
**Username**: ccppuuhttps://gitlab.torproject.org/legacy/trac/-/issues/19496Remove deb.tpo obfs4proxy Debian packages2020-06-13T16:51:30ZirlRemove deb.tpo obfs4proxy Debian packagesobfs4proxy was package in Debian in #12910, but is currently only available in Debian testing and unstable.
Producing backports for Debian jessie and currently supported Ubuntu suites would improve availability to relay operators, and m...obfs4proxy was package in Debian in #12910, but is currently only available in Debian testing and unstable.
Producing backports for Debian jessie and currently supported Ubuntu suites would improve availability to relay operators, and make it easier for relay operators to run useful bridges.
I'm happy to do this work, but it should be coordinated with infinity0/lunar who currently maintain the package in Debian. I'm also happy for them to do the backporting work.
For the Ubuntu backports, we should host these on deb.tpo (and if we choose to do so we should host Debian packages (sid, stretch, jessie) there too for completeness.irlirlhttps://gitlab.torproject.org/legacy/trac/-/issues/18356obfs4proxy cannot bind to <1024 port with systemd hardened service unit2020-06-13T14:54:36ZTracobfs4proxy cannot bind to <1024 port with systemd hardened service unitHi,
I was running an obfs4proxy Debian Wheezy bridge with such configuration in torrc:
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443 any more, while tor l...Hi,
I was running an obfs4proxy Debian Wheezy bridge with such configuration in torrc:
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443 any more, while tor logs had such messages:
```
Feb 21 22:51:09.000 [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied)
Feb 21 22:51:09.000 [warn] Managed proxy at '/usr/bin/obfs4proxy' failed the configuration protocol and will be destroyed.
```
Mind that I have already set the appropriate capability to the obfs4proxy binary:
```
getcap /usr/bin/obfs4proxy
/usr/bin/obfs4proxy = cap_net_bind_service+ep
```
I took some time moving things around and I think the problem resides on the systemd service unit: https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in and specifically the option introduced in b4170421cc58d8c57254f4224ba259e817f48869 .
```
NoNewPrivileges=yes
```
I assume so because flipping 'NoNewPrivileges=no' results in obfs4proxy binding to 443. Also, 'PR_SET_NO_NEW_PRIVS' section in 'man 2 prctl' implies so:
```
PR_SET_NO_NEW_PRIVS (since Linux 3.5)
Set the calling process's no_new_privs bit to the value in arg2. With
no_new_privs set to 1, execve(2) promises not to grant privileges to do
anything that could not have been done without the execve(2) call (for
example, rendering the set-user-ID and set-group-ID permission bits, and
file capabilities non-functional). Once set, this bit cannot be unset.
The setting of this bit is inherited by children created by fork(2) and
clone(2), and preserved across execve(2).
For more information, see the kernel source file Documenta‐
tion/prctl/no_new_privs.txt.
```
I understand that 'NoNewPrivileges=no' is a system security drawback but I also consider a regression to not be able to bind obfs4proxy to ports <1024. Could we find a middle ground?
If that helps, I'm running:
```
tor: 0.2.7.6-1~d80.jessie+1
deb.torproject.org/torproject.org/ jessie/main amd64 Packages
obfs4proxy: 0.0.4-1~tpo1
deb.torproject.org/torproject.org/ obfs4proxy/main amd64 Packages
```
Also:
```
cat /etc/debian_version
8.3
cat /proc/version
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)
```
Thanks for your work.
**Trac**:
**Username**: irregulatorTor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/15702Update obfs4proxy to 0.0.5, remove the old go.net code.2020-06-15T23:25:22ZYawning AngelUpdate obfs4proxy to 0.0.5, remove the old go.net code.New tag for socks5 and to change the upstream dependency.
The new tag gets:
* SOCKS5 support, for obfs4proxy's PTs, separate from #12535.
* Changed from `code.google.com/p/go.net` to `golang.org/x/net` for a dependency.
The gitian de...New tag for socks5 and to change the upstream dependency.
The new tag gets:
* SOCKS5 support, for obfs4proxy's PTs, separate from #12535.
* Changed from `code.google.com/p/go.net` to `golang.org/x/net` for a dependency.
The gitian descriptor already handles pulling down the required code from the new location thanks to #15265, so all that's left is to remove the mentions of the old code and stop fetching the tarball from my people.tp.o directory, and updating the tag.https://gitlab.torproject.org/legacy/trac/-/issues/15576obfs4proxy provide logging as a package under common.2020-06-13T18:35:12ZYawning Angelobfs4proxy provide logging as a package under common.This was a request from Blanu, so I'm filing it so I don't forget to do it. To ease development, obfs4proxy should provide a log package under common that contains the logging code currently part of the main package.
This will allow in...This was a request from Blanu, so I'm filing it so I don't forget to do it. To ease development, obfs4proxy should provide a log package under common that contains the logging code currently part of the main package.
This will allow individual transport implementations to do logging on their own in a sane manner that is log level aware.Yawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/15265obfs4proxy should use "golang.org/x/net/proxy"2020-06-15T23:25:22ZYawning Angelobfs4proxy should use "golang.org/x/net/proxy"I should have changed this when I dealt with the "go.crypto" repository move, but I didn't.
It's a simple change of import paths in 3 files, but this breaks packaging and the TBB nightly builds if I commit it, so I'm opening a ticket to...I should have changed this when I dealt with the "go.crypto" repository move, but I didn't.
It's a simple change of import paths in 3 files, but this breaks packaging and the TBB nightly builds if I commit it, so I'm opening a ticket to ensure that the right things happen in all the relevant places.
This isn't particularly high priority since the old code still works, but switching to this, and having Tor Browser pull it in will let me kill off the go.net tarball that's used as part of the 4.5a build.Yawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/13793obfs4proxy causes issues on Windows with certain AV products.2020-06-13T18:35:08ZYawning Angelobfs4proxy causes issues on Windows with certain AV products.From the [Tor Browser 4.5-alpha1 post](https://blog.torproject.org/blog/tor-browser-45-alpha-1-released#comment-79170):
> my system was crashed and shut down when i Run obfs4 transport!!!
> also my antivirus acted (Bitdefender)
>
> win 7...From the [Tor Browser 4.5-alpha1 post](https://blog.torproject.org/blog/tor-browser-45-alpha-1-released#comment-79170):
> my system was crashed and shut down when i Run obfs4 transport!!!
> also my antivirus acted (Bitdefender)
>
> win 7/ultimate 32 bit
I don't have BitDefender, and I verified that obfs4proxy works on:
* Windows 7 Professional (32 bit)
* Windows 8.1 (64 bit)
As other people also report that it works fine, for now I assume this is a weird AV false positive/interaction, but further research is needed.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/13633obfs4proxy should support ScrambleSuit2020-06-13T18:35:07ZYawning Angelobfs4proxy should support ScrambleSuitI'm not entirely sure what the plan going forward for mobile is going to be re obfs4. At this point to get obfs4 on mobile, it would either require adding obfs4 to obfsclient (doable, but a decent amount of work), or adding ScrambleSuit...I'm not entirely sure what the plan going forward for mobile is going to be re obfs4. At this point to get obfs4 on mobile, it would either require adding obfs4 to obfsclient (doable, but a decent amount of work), or adding ScrambleSuit to obfs4client.
Assuming golang is easy to compile and run on mobile I'm inclined to do the latter since obfs4proxy is memory safe, fully supports #8402, and this would reduce obfsproxy in Tor Browser to "there so fte works".
In practical terms the work required for this isn't massive (at least for client support), due to how close obfs4 and ScrambleSuit are under the hood.Yawning AngelYawning Angel