lyrebird issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues2024-03-12T00:09:26Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40012Domain fronting requests don't work on some older Android versions2024-03-12T00:09:26ZPier Angelo VendrameDomain fronting requests don't work on some older Android versionsTor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894)....Tor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894).
While checking if things worked, I noticed that domain fronting requests don't (I don't get the special countries list).
As written in that MR, I tried to enable logging (I added `"-enableLogging", "-logLevel", "DEBUG", "-unsafeLogging"` as arguments), but I could get only these messages:
```
2024/01/22 10:20:23 [NOTICE]: obfs4proxy-0.0.14 - launched
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - initializing client transport listeners
2024/01/22 10:20:23 [INFO]: meek_lite - registered listener: 127.0.0.1:55852
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - accepting connections
2024/01/22 10:20:23 [WARN]: meek_lite(bridges.torproject.org:443) - closed connection: readfrom tcp 127.0.0.1:55852->127.0.0.1:48836: io: read/write on closed pipe
```
I think there might be some problems with some HTTPS certificate (at least letsencrypt had this problem a few years ago, indeed cohosh mentioned snowflake#40087. Fastly isn't using letsencrypt, but maybe they have a similar problem).
I can open bridges.torproject.org both in TBA and in the system browser, but I can't open https://moat.torproject.org.global.prod.fastly.net/ because it has a wrong certificate.
I don't think I'm using the latest version of Lyrebird, because in the last one the log file should be called lyrebird.log (I submitted a patch for that, unless I missed the log filename), but I can try to build one from a nightly build.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40010fork the project2024-02-28T10:10:24Zmeskiomeskio@torproject.orgfork the projectIt looks like we [can't agree](https://gitlab.com/yawning/obfs4/-/merge_requests/10) with upstream on some changes that we need, I think the best path forward is to fork it.
Things that need to be updated:
* [x] go.mod
* [x] README
* [...It looks like we [can't agree](https://gitlab.com/yawning/obfs4/-/merge_requests/10) with upstream on some changes that we need, I think the best path forward is to fork it.
Things that need to be updated:
* [x] go.mod
* [x] README
* [x] LICENSE
* [x] internal/REAME.md maintainers rant
* [x] make a release (update ChangeLog)
* [x] update Tor Browser build
* [x] notify iptproxy about the change
* [ ] update docker image to use it
* [ ] package into debianmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40009Considering add a server version indication as connection parameter in obfs42022-10-04T17:06:02ZshelikhooConsidering add a server version indication as connection parameter in obfs4Currently, we are encountering the issue that obfs4 servers are not updating to the most recent version which are creating connection stability issues during handshake phase.
We already propose an [amendment](https://gitlab.torproject.o...Currently, we are encountering the issue that obfs4 servers are not updating to the most recent version which are creating connection stability issues during handshake phase.
We already propose an [amendment](https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/63) However, it will take a while to get it accepted and working.
One of the way we could fix this right now, is add a new connection parameter to indicate protocol version. This will allow client to connect to server in a way server can understand.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40005Fix active attack on length field2022-10-12T18:34:47ZAaron JohnsonFix active attack on length fieldThere is an active attack to identify obfs4. Each data packet begins with an unauthenticated 2-byte length field. That length field is encrypted but it can be modified in a predictable way because the encryption is XORing. The adversary ...There is an active attack to identify obfs4. Each data packet begins with an unauthenticated 2-byte length field. That length field is encrypted but it can be modified in a predictable way because the encryption is XORing. The adversary can therefore test if there is an encrypted two-byte length field by flipping some bits, which adds a known amount X to the received length if the adversary has seen the entire message and thus knows its true length. The adversary then follows that up with X arbitrary bytes, and the advesrary concludes the connection is running obfs4 if the server immediately closes the connection after the Xth added byte is sent (because at that point it believes it has the whole message and attempts unsuccessfully to authenticate the message). Having an obfuscated 2-byte length field at the beginning of data packets seems unique to obfs4, at least among all the encrypted protocols that I am familiar with.
Unfortunately, there is no obviously great solution to this problem. An obvious "fix" is to add a 16-byte MAC tag on (and immediately after) the 2-byte length field. This solution does still allow the adversary to test for such structure in the packet by flipping some bits in the length field and observing if the server closes the connection as soon as the subsequent 16 bytes are received. An authenticated 2-byte field beginning a data packet seems fairly unique as well.
Another option is to get rid of the length field and instead use a sentinal field marking the end of a variable-length message. This strategy is actually used by obfs4 for the handshake packets. Of course, the sentinal byte would have to look random, achievable easily enough by adding a counter into the HMAC. The adversary could, however, test for this strategy as well by replacing all data with random bytes to see at what point the server closes the connection, which would presumably happen when some fixed maximum frame length is reached. Perhaps that maximum frame length could be somewhat randomly chosen per-server, based on the bridge nodeID and/or public key.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/33560Settings immediately after install2021-06-17T14:23:19ZTracSettings immediately after install3/9/20, 04:33:18.780 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
3/9/20, 04:33:19.122 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
3/9/20, 04:33:19.336 [NOTICE] Bootstrapped 15% (handshake_done): Handsh...3/9/20, 04:33:18.780 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
3/9/20, 04:33:19.122 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
3/9/20, 04:33:19.336 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
3/9/20, 04:33:19.337 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
3/9/20, 04:33:19.338 [NOTICE] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
3/9/20, 04:33:19.340 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
3/9/20, 04:33:20.168 [NOTICE] Bootstrapped 100% (done): Done
3/9/20, 04:33:21.105 [NOTICE] New control connection opened from 127.0.0.1.
3/9/20, 04:33:21.354 [NOTICE] New control connection opened from 127.0.0.1.
3/9/20, 04:34:59.416 [WARN] CreateProcessA() failed: The system cannot find the file specified.
3/9/20, 04:34:59.416 [WARN] Pluggable Transport process terminated with status code 0
3/9/20, 04:34:59.417 [WARN] Failed to start process: (null)
3/9/20, 04:34:59.417 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\obfs4proxy.exe' failed at launch.
3/9/20, 04:34:59.417 [NOTICE] Switching to guard context "bridges" (was using "default")
3/9/20, 04:34:59.504 [NOTICE] Delaying directory fetches: No running bridges
3/9/20, 04:34:59.504 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:34:59.504 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:34:59.504 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:00.507 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:00.508 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:00.509 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:01.511 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:01.511 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:02.523 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:02.523 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:03.529 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:03.529 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:04.542 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:04.543 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:05.546 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:06.556 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:06.556 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:07.582 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:07.583 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:07.584 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:08.567 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:09.575 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:09.576 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:11.593 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:12.611 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:14.621 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:15.635 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:16.645 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:17.648 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:18.660 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:19.672 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:22.546 [WARN] CreateProcessA() failed: The system cannot find the file specified.
3/9/20, 04:35:22.547 [WARN] Pluggable Transport process terminated with status code 0
3/9/20, 04:35:22.547 [WARN] Failed to start process: (null)
3/9/20, 04:35:22.548 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\obfs4proxy.exe' failed at launch.
3/9/20, 04:35:22.760 [NOTICE] Bridge at '217.12.199.130:42367' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:22.760 [NOTICE] Bridge at '5.2.75.181:9785' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:22.760 [NOTICE] Bridge at '96.41.145.139:42260' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:23.767 [NOTICE] Bridge at '217.12.199.130:42367' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:23.767 [NOTICE] Bridge at '5.2.75.181:9785' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:23.767 [NOTICE] Bridge at '96.41.145.139:42260' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:24.759 [NOTICE] Bridge at '217.12.199.130:42367' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:24.759 [NOTICE] Bridge at '96.41.145.139:42260' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:25.759 [NOTICE] Bridge at '217.12.199.130:42367' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:25.759 [NOTICE] Bridge at '5.2.75.181:9785' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:26.771 [NOTICE] Bridge at '217.12.199.130:42367' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:26.771 [NOTICE] Bridge at '96.41.145.139:42260' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:27.790 [NOTICE] Bridge at '217.12.199.130:42367' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:27.791 [NOTICE] Bridge at '5.2.75.181:9785' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:28.775 [NOTICE] Bridge at '217.12.199.130:42367' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:28.775 [NOTICE] Bridge at '96.41.145.139:42260' isn't reachable by our firewall policy. Asking bridge authority instead.
3/9/20, 04:35:29.290 [WARN] CreateProcessA() failed: The system cannot find the file specified.
3/9/20, 04:35:29.290 [WARN] Pluggable Transport process terminated with status code 0
3/9/20, 04:35:29.290 [WARN] Failed to start process: (null)
3/9/20, 04:35:29.300 [WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\obfs4proxy.exe' failed at launch.
3/9/20, 04:35:29.761 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:29.761 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:29.761 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:30.763 [WARN] We were supposed to connect to bridge '217.12.199.130:42367' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:30.763 [WARN] We were supposed to connect to bridge '5.2.75.181:9785' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
3/9/20, 04:35:30.763 [WARN] We were supposed to connect to bridge '96.41.145.139:42260' using pluggable transport 'obfs4', but we can't find a pluggable transport proxy supporting 'obfs4'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
**Trac**:
**Username**: KatBloodgoodhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/33461Multiarch docker obfs4 bridge2021-06-17T14:23:19ZTracMultiarch docker obfs4 bridgeHaving more images enables the bridge operators to directly pull an image instead of modifying the Dockerfile and consequently building that image. For example, the supported architectures can be x86_64, aarch64 and arm.
In order to do s...Having more images enables the bridge operators to directly pull an image instead of modifying the Dockerfile and consequently building that image. For example, the supported architectures can be x86_64, aarch64 and arm.
In order to do so we can have multiple `Dockerfile.arch` where is used https://github.com/multiarch/qemu-user-static in order to build such image.
For example in the Dockerfile.arm file the content should be something like:
```
# Base docker image
FROM multiarch/qemu-user-static:x86_64-arm as qemu
FROM arm32v7/debian:buster-slim
COPY --from=qemu /usr/bin/qemu-arm-static /usr/bin
# Install remaining dependencies.
RUN apt-get update && apt-get install -y \
tor \
tor-geoipdb \
obfs4proxy \
libcap2-bin \
--no-install-recommends
# Allow obfs4proxy to bind to ports < 1024.
RUN setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
RUN setcap cap_net_bind_service=+ep /usr/bin/tor
# Our torrc is generated at run-time by the script start-tor.sh.
RUN rm /etc/tor/torrc
RUN chown debian-tor:debian-tor /etc/tor
RUN chown debian-tor:debian-tor /var/log/tor
COPY start-tor.sh /usr/local/bin
RUN chmod 0755 /usr/local/bin/start-tor.sh
COPY get-bridge-line /usr/local/bin
RUN chmod 0755 /usr/local/bin/get-bridge-line
USER debian-tor
CMD [ "/usr/local/bin/start-tor.sh" ]
```
**Trac**:
**Username**: thymbahutymbahttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/32550Static tor in docker container2020-10-29T20:26:58ZTracStatic tor in docker containerI was wondering about how to improve the docker image. The current version of provided image, in such case for bridges, uses debian. This ends up in a "big" image that, in my honest opinion waste a lot of space.
In order to improve the ...I was wondering about how to improve the docker image. The current version of provided image, in such case for bridges, uses debian. This ends up in a "big" image that, in my honest opinion waste a lot of space.
In order to improve the deployment and the space required by such container, which can be even extended for all relay, I wrote a Makefile for statically build tor. Once there is a statically build of tor, it should be enough provide just it inside the container.
```
PREFIX=$(shell pwd)/dist
RELEASE=$(shell pwd)/release
TOR=https://dist.torproject.org
TOR_VER=0.4.1.6
LIBEVENT=https://github.com/libevent/libevent/releases/download
LIBEVENT_VER=2.1.11-stable
OPENSSL=https://github.com/openssl/openssl/archive
OPENSSL_VER=1_0_2t
ZLIB=https://zlib.net
ZLIB_VER=1.2.11
CLEAN_DIRS=$(dir .)
all: tor
tor: tor-${TOR_VER} libevent libseccomp zlib openssl
cd $< && \
./configure \
--prefix=${RELEASE} \
--enable-static-tor \
--with-openssl-dir=${PREFIX} \
--with-libevent-dir=${PREFIX} \
--with-zlib-dir=${PREFIX} \
--disable-asciidoc \
--disable-system-torrc \
--disable-seccomp \
&& $(MAKE) $(MAKEFLAGS) && $(MAKE) install
libevent: libevent-${LIBEVENT_VER}
cd $< && \
./configure --prefix=${PREFIX} --enable-shared=no && \
$(MAKE) $(MAKEFLAGS) && $(MAKE) install
openssl: OpenSSL_${OPENSSL_VER}
cd $< && \
./config no-shared no-dso no-zlib --prefix=${PREFIX} && \
$(MAKE) depend && $(MAKE) $(MAKEFLAGS) && $(MAKE) install_sw
zlib: zlib-${ZLIB_VER}
cd $< && \
./configure --prefix=${PREFIX} --static && \
$(MAKE) $(MAKEFLAGS) && $(MAKE) install
## Download and extract source if required
tor-${TOR_VER}:
wget -qO- ${TOR}$@.tar.gz | \
bsdtar xzf -
libevent-${LIBEVENT_VER}:
wget -qO- ${LIBEVENT}/release-${LIBEVENT_VER}/$@.tar.gz | \
bsdtar xzf -
OpenSSL_${OPENSSL_VER}:
wget -qO- ${OPENSSL}/$@.tar.gz | \
bsdtar xzf -
mv openssl-$@ $@
zlib-${ZLIB_VER}:
wget -qO- ${ZLIB}/$@.tar.gz | \
bsdtar xzf -
```
**Trac**:
**Username**: thymbahutymbahttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/32439tor can't bootstrap with obfs4 bridge and skewed clock2022-06-22T07:35:54Zintrigeritor can't bootstrap with obfs4 bridge and skewed clockEnvironment: Debian unstable, Tor Browser 9.0.1, system clock set 2h in the future.
Observed behavior: Tor Launcher says "Connected to bridge" but the progress bar is stuck at a very low percentage. After a while, the "Copy Tor Log To C...Environment: Debian unstable, Tor Browser 9.0.1, system clock set 2h in the future.
Observed behavior: Tor Launcher says "Connected to bridge" but the progress bar is stuck at a very low percentage. After a while, the "Copy Tor Log To Clipboard" button appears.
Impact: Tails users whose hardware clock is set to local time, in a timezone that's not close enough to UTC, cannot use obfs4 bridges. Unfortunately, that's quite common, because:
* Windows sets the hardware clock to local time by default (as opposed to Unix systems, that tend to assume the hardware clock is in UTC)
* many places where one needs obfs4 to use Tor are 4-7 hours ahead of UTC
* Tails can't guess whether the hardware clock is set to UTC time or to local time; it assumes it's UTC time
Corresponding tor log (actual obfs4 bridges IP & port redacted):
```
11/9/19, 16:39:11.903 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
11/9/19, 16:39:11.903 [NOTICE] Switching to guard context "bridges" (was using "default")
11/9/19, 16:39:11.903 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
11/9/19, 16:39:11.903 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
11/9/19, 16:39:11.903 [NOTICE] Opening Socks listener on 127.0.0.1:9150
11/9/19, 16:39:11.903 [NOTICE] Opened Socks listener on 127.0.0.1:9150
11/9/19, 16:39:11.903 [NOTICE] Renaming old configuration file to "/home/toto/tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc.orig.1"
11/9/19, 16:39:12.885 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
11/9/19, 16:39:12.887 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
11/9/19, 16:40:06.330 [WARN] Proxy Client: unable to connect to $IP1:$PORT1 ("general SOCKS server failure")
11/9/19, 16:40:12.957 [WARN] Proxy Client: unable to connect to $IP2:$PORT2 ("general SOCKS server failure")
11/9/19, 16:40:13.120 [WARN] Proxy Client: unable to connect to $IP3:$PORT3 ("general SOCKS server failure")
11/9/19, 16:41:10.165 [WARN] Proxy Client: unable to connect to $IP1:$PORT1 ("general SOCKS server failure")
11/9/19, 16:41:14.240 [WARN] Proxy Client: unable to connect to $IP2:$PORT2 ("general SOCKS server failure")
11/9/19, 16:41:20.420 [WARN] Proxy Client: unable to connect to $IP3:$PORT3 ("general SOCKS server failure")
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/32047Sharing Keys Through HTML?2021-06-17T14:23:19ZTracSharing Keys Through HTML?If you read how RSA works, it is obvious that decrypting something that is not meant to be decrypted still works to get random digits that are similar length. Here, an idea would be to hide some random digits in HTML, for example into th...If you read how RSA works, it is obvious that decrypting something that is not meant to be decrypted still works to get random digits that are similar length. Here, an idea would be to hide some random digits in HTML, for example into the first hundred colors in <style> or counting the number of letters inside the first fifty <p>s. These are numerical fields inside HTML that could have a string, encrypted by a Preshared RSA key (people know both the private and public key), put into it to be hidden. People will then decrypt that to get a public key to do the key sharing. While the censor cannot distinguish a regular HTML and a keysharing HTML because decrypting any regular HTML also gets you a salted public key, because both look like nothing. This is weak on its own because the censor could easily try to decrypt anything with the gotten key that originates from the requesting address, and if it works it is a tor connection, but at the same time, with two different connections originating from different addresses (could be two connections to WiFi to get different port forwarding), it is difficult for the censor to check every single connection against each HTML file for the key across the same public IP. I believe that obfs4 has this problem with the keysharing which reveals that it is a obfs4 connection.
**Trac**:
**Username**: Aphrodites1995https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/31719obfs4proxy should be more helpful if state file is empty2021-06-17T14:23:19ZPhilipp Winterphw@torproject.orgobfs4proxy should be more helpful if state file is emptyWe had a user on IRC who ran into the following error message:
```
[warn] Server managed proxy encountered a method error. (obfs4 failed to load statefile '/var/db/tor/pt_state/obfs4_state.json': unexpected end of JSON input)
```
It turn...We had a user on IRC who ran into the following error message:
```
[warn] Server managed proxy encountered a method error. (obfs4 failed to load statefile '/var/db/tor/pt_state/obfs4_state.json': unexpected end of JSON input)
```
It turns out that the user's state file was empty. Removing the state file and then having obfs4proxy re-create it fixed the problem. Obfs4proxy should realise that the state file is empty (was opposed to corrupt) and either re-create it itself or advise the user to delete it and try again.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/31153Create a "tor-bridge" Debian meta package2022-04-07T16:13:19ZPhilipp Winterphw@torproject.orgCreate a "tor-bridge" Debian meta packageInstalling an obfs4 bridge on Debian currently requires installing tor, obfs4proxy, and then figuring out how to configure it. We could create a meta package, say tor-bridge, that simplifies this process. This package would:
* Ship with...Installing an obfs4 bridge on Debian currently requires installing tor, obfs4proxy, and then figuring out how to configure it. We could create a meta package, say tor-bridge, that simplifies this process. This package would:
* Ship with a script that automatically determines a free and random OR and obfs4 port.
* Help us retire a transport by replacing, say, obfs4 with obfs5.
* Ship with a tool that helps operators get their bridge line.
* Write its torrc to a different file than the tor package, to be compliant with Debian policy.
* After installation, ask the operator about their nickname, contact info, and if they want a vanilla or obfs4 bridge.
* Maybe ship with [nyx](https://nyx.torproject.org) so operators have a sense of how their bridge is doing.
I hear that infinity0 already thought about this problem a lot in the context of tor-bridge-helper.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/30716Improve the obfs4 obfuscation protocol2023-03-31T17:37:37ZPhilipp Winterphw@torproject.orgImprove the obfs4 obfuscation protocolAs part of our work for Sponsor 28, we will evaluate and improve the obfs4 obfuscation protocol, which may result in obfs5.
Roger started the discussion [on our anti-censorship-team mailing list](https://lists.torproject.org/pipermail/a...As part of our work for Sponsor 28, we will evaluate and improve the obfs4 obfuscation protocol, which may result in obfs5.
Roger started the discussion [on our anti-censorship-team mailing list](https://lists.torproject.org/pipermail/anti-censorship-team/2019-May/000015.html). Relevant reading is the CCS'15 paper [Seeing through Network-Protocol Obfuscation](https://censorbib.nymity.ch/#Wang2015a) and the S&P'16 paper [SoK: Towards Grounding CensorshipCircumvention in Empiricism](https://censorbib.nymity.ch/#Tschantz2016a).
Let's use this ticket to keep track of this effort. Below is a list of ideas that we may or may not want to incorporate in obfs5.
== Randomisation
Obfs4 already implements randomisation for packet lengths and inter-arrival times but there are other protocol aspects that we can randomise. Note that the adoption of these strategies may complicate censorship analysis: if obfs5 instance X looks very different from obfs5 instance Y, then X may end up getting blocked while Y still works. Instead of saying "obfs5 is blocked," one may then have to be more specific and say "the obfs5 instances that rely on UDP are blocked."
* **Payload**: All bytes that obfs4 writes to the wire are randomly distributed. These high-entropy packets may or may not be common on the Internet. We could evade a "high-entropy filter" by having obfs4 servers derive a formal language from the shared secret. This language could, say, use dummy clear-text headers. The [LibFTE](http://libfte.org/) library may be helpful here.
* **Cover traffic**: [dcf](https://lists.torproject.org/pipermail/tor-dev/2017-June/012310.html) explains that obfs4 only sends data when it's given data to send. To improve on this, as dcf suggests, we could make obfs5 send data even when the application has nothing to send.
* **Packet directions**: An obfs4 flow begins with the client sending data to the server. We could randomise packet directions and have, say, the server talk first with a server-specific probability.
* **Transport protocol**: An obfs4 server could talk either TCP or UDP or SCTP. This may very well not be worth the effort.
== Lessons learned from [CCS'15 paper](https://censorbib.nymity.ch/#Wang2015a)
* DPI boxes tend to classify flows by only inspecting the first N packets of a flow. Keeping state is expensive, after all. We could exploit this by relaxing our obfuscation techniques after N packets to increase throughput.
* The paper's data set may not be representative of what countries or ISPs would see:
* It's "only" a university uplink. Universities typically have policies that prohibit file sharing such as BitTorrent. BitTorrent's "message stream encryption" may look similar to obfs3 and obfs4.
* The data sets are from 2014, 2012, and 2010, respectively. That's a long time in Internet years.
* The detectors' false positive rates are non-trivial and, as the authors point out themselves, would be problematic for a censor given that non-obfuscated traffic significantly outweighs obfuscated traffic.
* Does the data set only contain one obfs4 server instance? This may have affected their results.
== Miscellaneous
* [yawning writes](https://trac.torproject.org/projects/tor/ticket/30716#comment:1) that obfs4 doesn't easily support backward incompatible protocol alterations.
* [yawning writes](https://trac.torproject.org/projects/tor/ticket/30716#comment:3) that the framing could use better cryptography.
* Crazy idea: Use a modified TCP stack that ignores RST and FIN segments, so the GFW's on-path devices cannot tear down the connection. Instead, the obfs5 protocol could signal the end of the connection in an authenticated control frame. We could ignore RST and FIN segments by using firewall rules, or to get more crazy, by shipping a user space TCP stack (this may be easy to fingerprint, though).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40004Ubuntu 16.04 apparmor policy blocks obfs4proxy without modification2022-03-01T17:25:19ZTracUbuntu 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 legacy/trac#14014, on a Ubuntu 16.04 system with Tor 0.3.0.9 (git-100816d92ab5664d), th...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 legacy/trac#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**: ccppuu