Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:11:55Zhttps://gitlab.torproject.org/legacy/trac/-/issues/3587Accounting should work with pluggable transports2020-06-13T14:11:55ZGeorge KadianakisAccounting should work with pluggable transportsA bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to #3586)A bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to #3586)Tor: unspecifiedhttps://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/7875debian obfsproxies can't advertise ports under 10242020-06-13T14:26:16ZRoger Dingledinedebian obfsproxies can't advertise ports under 1024We don't have (m)any obfsproxies running on port 443. That's a shame.
But if you're on debian and want to follow our instructions (https://www.torproject.org/projects/obfsproxy-debian-instructions), even if you know how to set up port f...We don't have (m)any obfsproxies running on port 443. That's a shame.
But if you're on debian and want to follow our instructions (https://www.torproject.org/projects/obfsproxy-debian-instructions), even if you know how to set up port forwarding, there's no way for your Tor to advertise that your obfsproxy is listening on a low-numbered port.
One option is for Tor to launch obfsproxy as root before Tor drops privs, and then obfsproxy binds its low-numbered port and then drops privs too. That sounds awful.
Another option is to complexify ServerTransportListenAddr, or add a new config option like it, so we can tell Tor what address to pretend obfsproxy listens on. That sounds less awful but still not great.
Other options? It would be ideal if the Tor and obfsproxy debs could somehow do this themselves, since an "add this line to your iptables" component in our instructions places it out of reach of most users.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/8001obfsproxy makes tor warn when one bridge is down2020-06-13T14:26:37ZRoger Dingledineobfsproxy makes tor warn when one bridge is downWhen you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("...When you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get
```
Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("server rejected connection")
```
That's because that bridge is down currently.
When a bridge fails, we should probably only [warn] if no bridges have succeeded.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9125Allow reporting different obfs ports to bridge db2020-06-13T18:34:24ZTracAllow reporting different obfs ports to bridge db`ServerTransportListenAddr` needs to be extended to allow listen on one port and announce to bridge database another because in most cases tor can not listen on low ports.
Something like NoAdvertise and NoListen ORPort flags.
**Trac**:...`ServerTransportListenAddr` needs to be extended to allow listen on one port and announce to bridge database another because in most cases tor can not listen on low ports.
Something like NoAdvertise and NoListen ORPort flags.
**Trac**:
**Username**: hsnhttps://gitlab.torproject.org/legacy/trac/-/issues/9363test_pt_configure_proxy() tests should be improved.2020-06-13T14:30:49ZNick Mathewsontest_pt_configure_proxy() tests should be improved.From #9288:
>Could we expand the unit tests so that they actually *check* the expected outputs? That is, I expect that configuring a proxy is supposed to result in some changes to the proxy, to the or_state_t object, calls to other func...From #9288:
>Could we expand the unit tests so that they actually *check* the expected outputs? That is, I expect that configuring a proxy is supposed to result in some changes to the proxy, to the or_state_t object, calls to other function, and changes or calls to other stuff. There are lots of bugs that could lurk here that wouldn't get tested if all we check for is "return 0 five times, then return 1."Tor: 0.2.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/9580Tor should accept combined pluggable transport names2020-06-13T18:34:31ZGeorge KadianakisTor should accept combined pluggable transport namesThe plan for #7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for #7167 is that it requires no real modifications to little...The plan for #7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for #7167 is that it requires no real modifications to little-t-tor. However, in little-t-tor we do some checks on the transport names (in torrc, etc.) and ensure that they are C-identifiers -- but "websocket|obfs2" is not a C-identifier.
We should relax those checks so that they don't choke when we give them "websocket|obfs2".https://gitlab.torproject.org/legacy/trac/-/issues/9627Document ExtORPort in tor manual page2020-06-13T14:31:23ZDavid Fifielddcf@torproject.orgDocument ExtORPort in tor manual pageI did `man doc/tor.1` to see if my current checkout had support for ExtORPort and what the syntax was; it did have support but the option was not in the manual page.I did `man doc/tor.1` to see if my current checkout had support for ExtORPort and what the syntax was; it did have support but the option was not in the manual page.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9650create_managed_proxy_environment: lack of checks for values returned by get_f...2020-06-13T14:31:29Zcypherpunkscreate_managed_proxy_environment: lack of checks for values returned by get_first_listener_addrport_stringget_first_listener_addrport_string() can return NULL according to it's documentation.
No checks in create_managed_proxy_environment() so NULL can be passed to smartlist_add_asprintf()
If you sure NULL never returns for such case then it...get_first_listener_addrport_string() can return NULL according to it's documentation.
No checks in create_managed_proxy_environment() so NULL can be passed to smartlist_add_asprintf()
If you sure NULL never returns for such case then it needs proper assert check at least.Tor: 0.2.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/9665if no bridges are usable, tor should report a bootstrap error2020-06-13T14:31:36ZMark Smithif no bridges are usable, tor should report a bootstrap errorIn testing Tor Launcher changes while working on #9445, Kathy Brade and I found that when tor is only configured with bridges it cannot use due to a lack of PT plugins, the bootstrap process just stops making progress. It would be much ...In testing Tor Launcher changes while working on #9445, Kathy Brade and I found that when tor is only configured with bridges it cannot use due to a lack of PT plugins, the bootstrap process just stops making progress. It would be much better if an error was reported via the control port. Here is our torrc:
AvoidDiskWrites 1
bridge obfs2 91.143.91.97:34770
ControlPort 9151
CookieAuthentication 1
DataDirectory /Users/brade/dev/tor/tbb-for-tl-testing/TBB-3.0a2.app/Contents/Resources/Data/Tor
DirReqStatistics 0
GeoIPFile ../../Contents/Resources/Data/Tor/geoip
Log notice stdout
SocksListenAddress 127.0.0.1
SocksPort 9150
UseBridges 1
Here is the tor log:
Sep 04 11:37:33.689 [notice] Tor v0.2.4.14-alpha (git-f5729b8c1d45933f) running on Darwin with Libevent 2.0.21-stable and OpenSSL 1.0.1e.
Sep 04 11:37:33.689 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 04 11:37:33.689 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 04 11:37:33.710 [notice] Read configuration file "/Users/brade/dev/tor/tbb-for-tl-testing/TBB-3.0a2.app/Library/Vidalia/torrc".
Sep 04 11:37:33.714 [notice] Opening Socks listener on 127.0.0.1:9150
Sep 04 11:37:33.714 [notice] Opening Control listener on 127.0.0.1:9151
Sep 04 11:37:33.000 [notice] New control connection opened.
Sep 04 11:37:33.000 [notice] New control connection opened.
Sep 04 11:37:34.000 [notice] Bootstrapped 5%: Connecting to directory server.
Sep 04 11:37:34.000 [warn] We were supposed to connect to bridge '91.143.91.97:34770' using pluggable transport 'obfs2', but we can't find a pluggable transport proxy supporting 'obfs2'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9691Merge the torspec changes of #89292020-06-13T14:31:45ZGeorge KadianakisMerge the torspec changes of #8929I made the mistake of not creating a new ticket for the spec changes of #8929 and instead I just posted them in that same ticket. Unfortunately, they didn't get merged along with the tor.git changes.
Nick, can you please merge branch `b...I made the mistake of not creating a new ticket for the spec changes of #8929 and instead I just posted them in that same ticket. Unfortunately, they didn't get merged along with the tor.git changes.
Nick, can you please merge branch `bug8929_take2` in `https://git.torproject.org/user/asn/torspec.git`.
Thanks!https://gitlab.torproject.org/legacy/trac/-/issues/9894Sandbox doesn't work with obfsproxy2020-06-13T14:36:45ZTracSandbox doesn't work with obfsproxyWhen running tor [0.2.5.1-alpha-dev (git-a6b4934037d1308e)] with sandbox enabled and using obfsproxy [0.2.4] I get the following error:
(Sandbox) Caught a bad syscall attempt (syscall 0x2A)
after which tor terminates.
**Trac**:
**Us...When running tor [0.2.5.1-alpha-dev (git-a6b4934037d1308e)] with sandbox enabled and using obfsproxy [0.2.4] I get the following error:
(Sandbox) Caught a bad syscall attempt (syscall 0x2A)
after which tor terminates.
**Trac**:
**Username**: zoltanTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9957Tor should consider stderr output of transport proxies2020-06-13T14:35:38ZwfnTor should consider stderr output of transport proxiesCurrently, Tor cares about what transport proxies (e.g. obfsproxy) say over stdout (it echoes stdout in its log, etc.) Not so with stderr, the reason being, as far as I can tell, the presumed/standard signaling channel for transport prox...Currently, Tor cares about what transport proxies (e.g. obfsproxy) say over stdout (it echoes stdout in its log, etc.) Not so with stderr, the reason being, as far as I can tell, the presumed/standard signaling channel for transport proxies to communicate with Tor is their standard output stream, as per design.
It so happens that as of now, obfsproxy may complain about some things (e.g. it not being able to write to its own log file) over stderr. If one runs obfsproxy as intended (using the ServerTransportPlugin directive in torrc), obfsproxy may exit (Tor will report this, of course) without any verbal explanation.
Using the "run a transport proxy manually (without Tor) to figure out what's wrong" method (which some bridge operators have (had) to resort to (that is, at least me and someone else who talked with asn)) in order to debug things seems suboptimal.
Three ways out, as I see it:
1. Make sure all transport proxies adhere to the "use stdout to complain about things" protocol.
2. Have Tor treat both stdout and stderr streams of transport proxies as meaningful, and include their contents in log. This requires changing the design in regards to transport proxy <-> Tor signaling channels.
3. Care about stderr instead of stdout (most easy in terms of code changes, I think; not sure if makes much sense / is elegant, though.)
Are there any specific design-level nuances that block option 2?
For option 2, the [tor_get_lines_from_handle() function](https://gitweb.torproject.org/tor.git/blob/43f95e38abefced37ad24966d56298e972cebf81:/src/common/util.c#l4483) seems to be overall more or less handle-type-agnostic; it uses variable names like "stdout_buf", but it all really depends on what's passed via "handle", which could be any kind of stream.
[configure_proxy() in or/transports.c](https://gitweb.torproject.org/tor.git/blob/43f95e38abefced37ad24966d56298e972cebf81:/src/or/transports.c#l596) is what would need changing. Depending on design changes, the streams would have to be combined, or (simply) stderr would have to be used instead of stdout (so to remain clean, there'd need to be a tor_process_get_stderr_pipe(), which would simply `return process_handle->stderr_pipe`).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10088pyptlib - use JobObjects on windows to automatically kill PT children when PT...2020-06-13T18:34:41ZGeorge Kadianakispyptlib - use JobObjects on windows to automatically kill PT children when PT itself diesThis allows obfs-flash-client to work smoothly on windows. Otherwise, some orphan processes sometimes hang around, using up listen-ports, and prevent the next PT from starting *its* children.
Patch is here: https://github.com/infinity0/...This allows obfs-flash-client to work smoothly on windows. Otherwise, some orphan processes sometimes hang around, using up listen-ports, and prevent the next PT from starting *its* children.
Patch is here: https://github.com/infinity0/pyptlib/compare/w32-subproc
Note that this is just a temporary measure to get things working on windows, until we implement #10047.
original ticket contents, obsolete since #comment:7:
_Allow tor helpers to use JobObjects by setting CREATE_BREAKAWAY_FROM_JOB (Windows-only)_
While building Windows pbfs-flash PTTB bundles, we encountered an issue where the obfsproxy child of obfs-flash would not be terminated properly after closing the PTTBB. More information can be found in comment:5:ticket:10006 .
After lots of digging around, the problem was solved by toggling the `CREATE_BREAKAWAY_FROM_JOB` flag of `CreateProcess()` in `tor_spawn_background()`. More info in comment:26:ticket:10006.
We should look at the possible side-effects of adding the `CREATE_BREAKAWAY_FROM_JOB` flag there, and if it's innocuous then we should implement the change and get it merged.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/10218Provide "users-per-transport-per-country" statistics for obfsbridges2020-06-13T18:13:36ZGeorge KadianakisProvide "users-per-transport-per-country" statistics for obfsbridgesIn our `bridge-stats` file we currently have `bridge-ips` which tracks the number of connections per-country, and `bridge-ip-transports` which counts the number of connections per-transport.
Still, these two data points don't allow you ...In our `bridge-stats` file we currently have `bridge-ips` which tracks the number of connections per-country, and `bridge-ip-transports` which counts the number of connections per-transport.
Still, these two data points don't allow you to infer the users-per-transport-per-country; which would give us useful information in case of blocked transports in specific jurisdictions, etc.
gamambel today suggested that we add such functionality, which seems like a marvelous idea.
`wfn` and `grindhold` seem interested in coding this. As discussed in IRC, interesting functions here are:`geoip_get_transport_history()` `geoip_format_bridge_stats()` `validate_bridge_stats()`.
We should also define a nice format for this new line in `bridge-stats`. A not nice format is:
`bridge-ip-transports-per-country cn::obfs2:42,obfs3:46 ir::obfs2:10,obfs3:666`
we might be able to find a better one (or even one that is used currently somewhere else in tor).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10297Set CREATE_NO_WINDOW in tor_spawn_background2020-06-13T14:33:09ZDavid Fifielddcf@torproject.orgSet CREATE_NO_WINDOW in tor_spawn_backgroundThe CREATE_NO_WINDOW flag prevents the creation of a console window popup on Windows. We need it for pluggable transport executables under the 3.x browser bundle—otherwise you get blank console windows when you start it up with transport...The CREATE_NO_WINDOW flag prevents the creation of a console window popup on Windows. We need it for pluggable transport executables under the 3.x browser bundle—otherwise you get blank console windows when you start it up with transports enabled.
http://msdn.microsoft.com/en-us/library/ms684863.aspx#CREATE_NO_WINDOW
The project to make pluggable transports bundles based on 3.x TBB is #9444. A summary of the CREATE_NO_WINDOW situation is in comment:30:ticket:9444.
In short: The old browser bundles that used Vidalia used to set this flag when launching tor itself; it was apparently inherited by the pluggable transports launched by tor. In the 3.x bundles, tor is launched by some JavaScript code, which doesn't have the ability to set CREATE_NO_WINDOW. tor itself is now being compiled with the -mwindows option, so that it is a GUI application, not a console application, and doesn't show a console window in any case. This workaround doesn't work for pluggable transports, because they need to be able to write control messages to stdout.
In a function called tor_spawn_background it makes sense that console windows shouldn't be popping up. In addition to pluggable transports, I think the function is used for tor-fw-helper.
There may be other ways to solve the problem of console windows, but I haven't been able to think of them.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/10614pt-spec.txt describes using `keyid=fingerprint` in torrc `Bridge` lines2020-06-13T14:33:46ZIsis Lovecruftpt-spec.txt describes using `keyid=fingerprint` in torrc `Bridge` linesdcf pointed out in [this comment](https://trac.torproject.org/projects/tor/ticket/10559#comment:1) on #10559 that `pt-spec.txt` claims that little-t tor's parsing of `Bridge` lines was extended to support `keyid=fingerprint` (where `fing...dcf pointed out in [this comment](https://trac.torproject.org/projects/tor/ticket/10559#comment:1) on #10559 that `pt-spec.txt` claims that little-t tor's parsing of `Bridge` lines was extended to support `keyid=fingerprint` (where `fingerprint` is the digest of the bridge's ID key).
Little-t tor does not support this `keyid=` prefix. I've tested it; see [comment 3](https://trac.torproject.org/projects/tor/ticket/9499#comment:3) and [comment 4](https://trac.torproject.org/projects/tor/ticket/9499#comment:4) on #9449. Since it wasn't ever implemented, the `keyid=` prefix to bridge fingerprints should be removed from `pt-spec.txt` [L27](https://gitweb.torproject.org/torspec.git/blob/782dacf43035892a0025b252f99018a6a1082b0e:/pt-spec.txt#l27).Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/10629PT spec changes for better interoperability with other projects2020-06-13T18:34:47ZXimin LuoPT spec changes for better interoperability with other projectsI spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.
Major improvements:
- better spec documentation
- less Tor jarg...I spoke with the i2p guys today and here are some of their suggestions for the PT spec. These would make it easier for them (and future other projects) to use Tor's PTs.
Major improvements:
- better spec documentation
- less Tor jargon, split Tor-specific information into separate sections (e.g. Tor env vars)
- some guidelines for non-Tor programs to use PTs
- better handling of per-endpoint config params such as pubkeys, instead of current hack via SOCKS auth params
Smaller enhancements, "good to have":
- possibility of letting a single process to act as both a client (outgoing) and server (incoming).
- flashproxy must allow client-specific remote endpoints (already as #10196)
- don't trust the entire localhost machine to make outgoing connections, e.g. if one users wants to run his own instance. two options here:
- SSL connection with user/pass to the SOCKS transport client
- use unix domain sockets. This also frees up ports, which is extra-useful in PT composition. Doesn't work on windows, though.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/10957Be more aggressive about enabling Extended ORPort2020-06-13T14:34:15ZGeorge KadianakisBe more aggressive about enabling Extended ORPortBridges without Extended ORPort do not publish statistics about usage. Some people really care about statistics.
In #9651 (merged in 0.2.5.1) we decided to add a warning if the user has PTs but no Extended ORPort.
Maybe we should be a ...Bridges without Extended ORPort do not publish statistics about usage. Some people really care about statistics.
In #9651 (merged in 0.2.5.1) we decided to add a warning if the user has PTs but no Extended ORPort.
Maybe we should be a bit more aggressive about enabling Extended ORPort, since many operators might simply ignore that warning.
Some solutions:
a) (Most aggressive) Just enable Extended ORPort by default if ORPort and PTs are in effect. Of course, make it listen only on localhost.
b) Turn the warning into an error, so that people can't start their bridge without it. The problem here is that it's not really an error, since the bridge will work fine without ExtORPort, but there will be no stats.
c) Use Unix sockets in platforms that support it; similar to how we do it for ControlPort.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11043Improve the "You should enable Extended ORPort" log message.2020-06-13T14:34:23ZGeorge KadianakisImprove the "You should enable Extended ORPort" log message.As can be seen in
https://lists.torproject.org/pipermail/tor-relays/2014-February/003908.html
people get confused about the new "You should enable Extended ORPort" log message.
This is kind of related to #10957 , but in this ticket we ...As can be seen in
https://lists.torproject.org/pipermail/tor-relays/2014-February/003908.html
people get confused about the new "You should enable Extended ORPort" log message.
This is kind of related to #10957 , but in this ticket we should figure out a better log message for the short term.
We currently log:
```
We are a bridge with a pluggable transport
proxy but the Extended ORPort is disabled. The Extended ORPort helps Tor
communicate with the pluggable transport proxy. Please enable it using
the ExtORPort torrc option.
```
we should at least mention that users can simply put `ExtORPort auto` in their torrc to fix this issue. And maybe we should include an online link to further documentation about ExtORPort.Tor: 0.2.5.x-final