Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:21:52Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2020-06-13T18:21:52ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32753Tor should lower-case its BridgeDistribution string2020-06-13T15:49:08ZRoger DingledineTor should lower-case its BridgeDistribution stringSee comment:8 in #32547, where phw tells a bridge operator that they need to set BridgeDistribution to "none", because using "None" is not right.
That isn't a good user experience, and it's easy to fix.
One option is that inside check_...See comment:8 in #32547, where phw tells a bridge operator that they need to set BridgeDistribution to "none", because using "None" is not right.
That isn't a good user experience, and it's easy to fix.
One option is that inside check_bridge_distribution_setting() when we do `if (!strcmp(bd, RECOGNIZED[i]))` we should do strcasecmp instead. That is, don't complain if it's a recognized value and the only issue is that it's not all lowercase.
But a better option imo is that we lowercase it in place first, so that if the user types None, bridgedb still sees none.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32622Fix misleading STATUS_CLIENT warning message2020-06-13T15:48:40ZPhilipp Winterphw@torproject.orgFix misleading STATUS_CLIENT warning messageAfter Tor 0.4.3.0-alpha-dev successfully established a TCP connection with a bridge but failed to finish its handshake, it sends the following `STATUS_CLIENT` message to the controller:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=10 TA...After Tor 0.4.3.0-alpha-dev successfully established a TCP connection with a bridge but failed to finish its handshake, it sends the following `STATUS_CLIENT` message to the controller:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server" WARNING="DONE" REASON=DONE COUNT=1 RECOMMENDATION=warn HOSTID="0000000000000000000000000000000000000000" HOSTADDR="[scrubbed]"
```
One can reproduce this by using torproject.org's web server as a bridge: 95.216.163.36:80. The substring `WARNING="DONE"` is misleading and should – if I'm interpreting [control-spec.txt](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2682) correctly – contain a human-readable description of what went wrong. Other `STATUS_CLIENT` messages do a better job; for example:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server" WARNING="Connection refused" REASON=CONNECTREFUSED COUNT=1 RECOMMENDATION=warn HOSTID="0000000000000000000000000000000000000000" HOSTADDR="[scrubbed]"
```
Here, the substring `WARNING="Connection refused"` gives me a good idea of what's going on.
I suggest to fix the warning in this particular error case.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31009Tor lets transports advertise private IP addresses in descriptor2020-06-13T15:43:09ZPhilipp Winterphw@torproject.orgTor lets transports advertise private IP addresses in descriptorWhile dealing with broken obfs4 bridges, I realised that our bridge authority has several obfs4 bridges in its cached-extrainfo document that have private IP addresses, e.g.:
```
transport obfs4 10.0.254.17:[redacted]
```
The PT spec [e...While dealing with broken obfs4 bridges, I realised that our bridge authority has several obfs4 bridges in its cached-extrainfo document that have private IP addresses, e.g.:
```
transport obfs4 10.0.254.17:[redacted]
```
The PT spec [explicitly allows private addresses](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt?id=4707f3604cd06e3a627980c6863cca556f9f21a4#n305) in `TOR_PT_SERVER_BINDADDR`:
> The <address> MAY be a locally scoped address as long as port forwarding is done externally.
BridgeDB however ignores bridges with private IP addresses, so these obfs4 bridges are effectively useless. We could address this issue in BridgeDB by replacing an obfs4 bridge's private IP address with the address in its ORPort but I think that tor shouldn't be writing private addresses to a descriptor in the first place.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30477Tor should self-test reachability of TCP listeners exposed by PT's2020-06-13T15:41:30ZAlexander Færøyahf@torproject.orgTor should self-test reachability of TCP listeners exposed by PT'sIt would be useful if Tor would do self-test of TCP port reachability for bridge listeners and not just the ORPort itself.
Currently when a bridge operator starts their Bridge Relay, Tor will test whether their ORPort is available from ...It would be useful if Tor would do self-test of TCP port reachability for bridge listeners and not just the ORPort itself.
Currently when a bridge operator starts their Bridge Relay, Tor will test whether their ORPort is available from the internet, but we do not test the reachability of, for example, the obfs4 TCP port.
We believe that *just* testing for whether the port is available to the internet is better than to actually test if the port, for example, is able to speak the obfs4 protocol.
We should probably have a way to disable the warning that is emitted if a port is not reachable if, for example, the bridge is actually lying to Tor about its port, does not have a port, or the port is exposed via UDP instead of TCP.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29128Place complete obfs4 bridge line in accessible location2020-06-13T15:36:59ZColin ChildsPlace complete obfs4 bridge line in accessible locationCurrently operators wanting to distribute or use personal obfs4 bridges must follow 5 steps:
1. Determine their bridge's IP address
2. Check logs for their bridge's fingerprint
3. Check logs for which port obfs4 is running on
4. Retrie...Currently operators wanting to distribute or use personal obfs4 bridges must follow 5 steps:
1. Determine their bridge's IP address
2. Check logs for their bridge's fingerprint
3. Check logs for which port obfs4 is running on
4. Retrieve their obfs4 cert from /var/lib/tor/pt_state/obfs4_bridgeline.txt
5. String the above together in the following format:
```
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=$FROMSTEP4 iat-mode=0
```
This can be a confusing process, and is only fully explained upon opening `/var/lib/tor/pt_state/obfs4_bridgeline.txt`; however it leaves filling in the fields (with the exception of the cert) to the user.
Having the complete bridge line placed somewhere accessible would make this process much less painful for operators.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7349Obfsbridges should be able to "disable" their ORPort2021-07-29T15:06:00ZGeorge KadianakisObfsbridges should be able to "disable" their ORPortIn the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPo...In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPort of obfsbridges.
Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5304Obfsproxy should respect OutboundBindAddress in torrc2020-06-13T14:17:58ZTracObfsproxy should respect OutboundBindAddress in torrcRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovTor: 0.4.4.x-final