Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:43:13Zhttps://gitlab.torproject.org/legacy/trac/-/issues/14895SENTCONNECT TCP RST/TIMEOUT print IP in FAILED/CLOSED2020-06-13T14:43:13ZgrarpampSENTCONNECT TCP RST/TIMEOUT print IP in FAILED/CLOSEDConnect requests resulting in TCP ACK properly print the IP resolved and connected to by the exit in SUCCEEDED and CLOSED...
NEW torproject.org:80 PURPOSE=USER
SENTCONNECT torproject.org:80
REMAP 154.35.132.70:80 SOURCE=EXIT
SUCCEEDED 1...Connect requests resulting in TCP ACK properly print the IP resolved and connected to by the exit in SUCCEEDED and CLOSED...
NEW torproject.org:80 PURPOSE=USER
SENTCONNECT torproject.org:80
REMAP 154.35.132.70:80 SOURCE=EXIT
SUCCEEDED 154.35.132.70:80
CLOSED 154.35.132.70:80 REASON=DONE
Yet those resulting in TCP RST or TIMEOUT fail to print the IP even though the IP is (if not it should be) returned and known to client in those cases as well...
NEW torproject.org:800 PURPOSE=USER
SENTCONNECT torproject.org:800
FAILED torproject.org:800 REASON=END REMOTE_REASON=CONNECTREFUSED
CLOSED torproject.org:800 REASON=END REMOTE_REASON=CONNECTREFUSED
NEW example.com:800 PURPOSE=USER
SENTCONNECT example.com:800
DETACHED example.com:800 REASON=TIMEOUT
...
FAILED example.com:800 REASON=CANT_ATTACH
CLOSED example.com:800 REASON=CANT_ATTACH
Fix:
- Instead of the printing the SENTCONNECT fwd name, print the IP in those FAILED and CLOSED lines.
- The IP should also be printed in DETACHED if we have it (which we should if the TIMEOUT is being returned to us in a cell from the exit, as opposed to the client timing it out).
Also, in the case of a RST, it seems something (like CONNECTING, REMAP, DETACHED or some relavent label and line) could/should be printed between SENTCONNECT and FAILED.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14827Tor controller command to write its file to disk2020-06-13T14:42:43ZSebastian HahnTor controller command to write its file to diskatagar wants that for the tests.atagar wants that for the tests.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14164Controller method to get our own descriptor2020-06-13T14:41:41ZtoralfController method to get our own descriptorI'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_...I'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_version()
try:
desc = controller.get_microdescriptor()
print " flags : %s" % desc.flags()
print " measured bandwidth : %i" % desc.measured()
except Exception as exc:
print exc
#pass
```
gives
```
Tor was unable to provide the descriptor for 'F1BE15429B3CE696D6807F4D4A58B1BFEC45C822'
```
Does this means that stems asks tor and tor doesn't know itself ?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11179Combine setevents circ and stream2020-06-13T14:34:44ZgrarpampCombine setevents circ and streamToday there are three key parts printed...
# the request
NEW 0 trac.torproject.org:443 PURPOSE=USER
# the result
SUCCEEDED 335 38.229.72.30:443
# the resultant path
335 BUILT $FP.<nickname>... <xN>... $exitFP.<nick>
It would be very ha...Today there are three key parts printed...
# the request
NEW 0 trac.torproject.org:443 PURPOSE=USER
# the result
SUCCEEDED 335 38.229.72.30:443
# the resultant path
335 BUILT $FP.<nickname>... <xN>... $exitFP.<nick>
It would be very handy to have a combined log format for
tracking requests to exits (bad exits, looking back), or
to hidden service midpoints in that case. This should be
put in the controller "setevents_streamcirc", and maybe
in some optional torrc syslog form.
# combined shortlog
SUCCEEDED <epoch/ISO8601> <circN> <streamN> trac.torproject.org:38.229.72.30:443 $exitFP
In the event an IP is supplied, just put it in place
of the usual forward fqdn. IPv6 applies. The circN
and streamN are really optional since there is no
longer need to match them up for said log purpose.
SUCCEEDED ISO8601 trac.torproject.org:38.229.72.30:443 $exitFP
And second extended form could include them and the
full path if desired by user.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11044No consensus results in empty 'GETINFO ns/name/*' responses2020-06-13T14:34:23ZDamian JohnsonNo consensus results in empty 'GETINFO ns/name/*' responsesHi Nick, spotted an interesting tor oddity during my flight (due to not having any network connectivity). When calling 'GETINFO ns/name/blarg' without a cached consensus it returns an empty string rather than the expected "Unrecognized k...Hi Nick, spotted an interesting tor oddity during my flight (due to not having any network connectivity). When calling 'GETINFO ns/name/blarg' without a cached consensus it returns an empty string rather than the expected "Unrecognized key" response.
Repro details...
1. With a data directory containing a cached consensus things work as expected...
```
% telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE
250 OK
GETINFO ns/all
[ ... lots of output... ]
GETINFO ns/name/blarg
552 Unrecognized key "ns/name/blarg"
```
2. Blow away your data directory when you lack network connectivity.
```
% mv ~/.tor ~/.tor_bak
% mkdir ~/.tor
% cp ~/.tor_bak/torrc ~/.tor
% cat ~/.tor/torrc
ControlPort 9051
% tor -f ~/.tor/torrc
...
```
3. Now GETINFO for 'ns/all' and any requrest for a relay returns an empty response.
```
% telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE
250 OK
GETINFO ns/all
250-ns/all=
250 OK
GETINFO ns/name/blarg
250-ns/name/blarg=
250 OK
```
Interestingly this only seems to concern router status entries. Server descriptors and microdescriptors give us a 'Unrecognized key'...
```
GETINFO desc/name/blarg
552 Unrecognized key "desc/name/blarg"
GETINFO md/name/blarg
552 Unrecognized key "md/name/blarg"
```
For my part I noticed this because it caused an integ testing failure during my flight...
```
======================================================================
ERROR: test_get_network_status
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/atagar/Desktop/stem/test/integ/control/controller.py", line 977, in test_get_network_status
self.assertRaises(stem.ControllerError, controller.get_network_status, "blargg")
File "/usr/lib/python2.7/unittest/case.py", line 471, in assertRaises
callableObj(*args, **kwargs)
File "/home/atagar/Desktop/stem/stem/control.py", line 1427, in get_network_status
raise exc
ValueError: Router status entries (v3) must have a 'r' line:
```
This doesn't seem like the right tor behavior but if you think it is I can simply have stem check for the empty string. :)
Cheers! -DamianTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10052Tor Windows service should reload its configuration on SERVICE_CONTROL_PARAMC...2020-06-13T14:32:47ZTracTor Windows service should reload its configuration on SERVICE_CONTROL_PARAMCHANGE control codeThe Tor Windows service does not currently support reloading its configuration without stopping or restarting. This functionality is provided on other operating systems by sending the `SIGHUP` signal to a Tor process.
Windows services i...The Tor Windows service does not currently support reloading its configuration without stopping or restarting. This functionality is provided on other operating systems by sending the `SIGHUP` signal to a Tor process.
Windows services implement this kind of functionality by [registering](http://msdn.microsoft.com/en-us/library/ms685054%28v=vs.85%29.aspx) to the service manager to [listen](http://msdn.microsoft.com/en-us/library/ms683240%28v=vs.85%29.aspx) for control codes. Therefore the Tor Windows service should implement reloading its configuration on `SERVICE_CONTROL_PARAMCHANGE`.
**NOTE:** Because service control codes are only supported since Windows XP, it does not need to be implemented for Windows 2000.
**NOTE 2:** Functionality that is provided by sending other signals to a Tor process on other operating systems should be implemented as user defined control codes. Initial documentation on implementing every single one of those control codes should be recorded as separate trac tickets while probably being a child of this ticket.
**Trac**:
**Username**: GITNETor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9982Use a better password-based KDF for controller passwords, authority identity ...2020-06-13T14:32:41ZNick MathewsonUse a better password-based KDF for controller passwords, authority identity key encryption, and moreWith the ed25519 key transition, we'll want to start bringing offline identity keys to regular relay operators (and ideally hidden service operators too somehow, if we can figure out a non-stupid way for it to interact with #8106).
As w...With the ed25519 key transition, we'll want to start bringing offline identity keys to regular relay operators (and ideally hidden service operators too somehow, if we can figure out a non-stupid way for it to interact with #8106).
As we do this, we'll want a better password-based KDF. Right now we have the very silly "NID_pbe_WithSHA1And3_Key_TripleDES_CBC" for protecting authority keys, and the very silly OpenPGP KDF for hashing controller passwords. Let's do something from the 21st century.
This is a bikeshed discussion. I nominate: "Derive keys with scrypt-jane, with salsa20/8 and SHA512."Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8369Option to limit information Tor's control port discloses2020-06-13T14:27:49ZproperOption to limit information Tor's control port disclosesCurrently getinfo address spills the external IP address, which could jeopardize the user's anonymity in certain use cases.
Please add add an option to torrc (ControlLockdown or so) to leave such requests unanswered if activated.
Use c...Currently getinfo address spills the external IP address, which could jeopardize the user's anonymity in certain use cases.
Please add add an option to torrc (ControlLockdown or so) to leave such requests unanswered if activated.
Use cases:
* One goal of a [Transparent Proxy](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy) (Isolating Middlebox) or an [Isolating Proxy](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IsolatingProxy) is to strengthen proxy obedience. In essence the idea of is, that the operating system is not aware of it's own external IP address and can therefore not spill it, because Tor is running on a separate machine. At the moment such setups have the disadvantage, that they must forbid access to Tor's control port - because the control port could spill the IP. Users can therefore not use the "New identity" feature of TorButton and will in future be unable to use other improvements such as #3059 ("Adapt browser time based on tor's notion of clock skew...").
* Building a [Bridge Firewall](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/BridgeFirewall) is impossible because of lack of this lock down feature.
There may be other features similar to "getinfo address" in the Tor control protocol, which could be potentially harmful. I haven't looked yet. If this feature get's accepted (as in "we could imagine to add such an option"), we (and I of course as well) could look for other things in the control protocol, which are potentially harmful for anonymity.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8323Missing 'GETINFO md/all'2020-06-13T14:27:45ZDamian JohnsonMissing 'GETINFO md/all'Hi Nick. The control spec has GETINFO options to fetch a microdescriptor via its fingerprint or nickname ('md/id/*' and 'md/name/*') but no method for getting them all (like 'ns/all' or 'desc/all-recent').
Processing all descriptors is ...Hi Nick. The control spec has GETINFO options to fetch a microdescriptor via its fingerprint or nickname ('md/id/*' and 'md/name/*') but no method for getting them all (like 'ns/all' or 'desc/all-recent').
Processing all descriptors is a pretty common need, hence the priority (feel free to lower it if appropriate). In the meantime I'll hack around this in stem by having controller read microdescriptors from the data directory.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/8214"getinfo address" should work more consistently soon after startup2020-06-13T14:27:26ZRoger Dingledine"getinfo address" should work more consistently soon after startupTor learns its own address, either by using the interface or by reading the http headers in directory responses.
But if your Tor had enough dir info cached when it came back up, it doesn't make any directory requests for a while. And th...Tor learns its own address, either by using the interface or by reading the http headers in directory responses.
But if your Tor had enough dir info cached when it came back up, it doesn't make any directory requests for a while. And then getinfo address will not have any opinion.
I think the best plan here is to expand the set of things inside Tor that remembers address guesses, to include address guesses we get from netinfo cells.
Wanted by #7348.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7899We forget to set tls_error sometimes2020-06-13T14:26:20ZGeorge KadianakisWe forget to set tls_error sometimesA weird guy in IRC mentioned that Tor forgets to set `or_connection_t.tls_error` sometimes.
He/she gave the call to `flush_buf_tls()` in `connection_handle_write_impl()` as an example of a situation that `tls_error` should be set but it...A weird guy in IRC mentioned that Tor forgets to set `or_connection_t.tls_error` sometimes.
He/she gave the call to `flush_buf_tls()` in `connection_handle_write_impl()` as an example of a situation that `tls_error` should be set but it's not.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7059TorControl: Unrecognized (node) key errors2020-06-13T14:25:23ZTracTorControl: Unrecognized (node) key errorsOK, I am not 100% sure whether this is a new bug, though I thought to report it anyway, just in case.
Some background: Alongside tor, sometimes I use event handler, which reports all tor events I am interested in (mainly to create and c...OK, I am not 100% sure whether this is a new bug, though I thought to report it anyway, just in case.
Some background: Alongside tor, sometimes I use event handler, which reports all tor events I am interested in (mainly to create and close streams and also to display the full path of those streams, together with their IP address and country code).
All this is java based (I will try to attach the java code - 3 files in total - at the end of this report).
Up until I upgraded to 0.2.4.3, everything was OK, but since the upgrade I started getting a lot of errors like these:
Error from Tor process: dash.four.tor.torctl.TorControlError: Error reply: Unrecognized key "desc/id/$97B867190D2A0387F3259EA65664A90884A8BDC4" [null]
Error from Tor process: dash.four.tor.torctl.TorControlError: Error reply: Unrecognized key "desc/id/$A1130635A0CDA6F60C276FBF6994EFBD4ECADAB1" [null]
Error from Tor process: dash.four.tor.torctl.TorControlError: Error reply: Unrecognized key "desc/id/$8894CAA82AA1DC8B72B679ACB54FFED561737B68" [null]
Error from Tor process: dash.four.tor.torctl.TorControlError: Error reply: Unrecognized key "desc/id/$F4EAE475A7117DD53EF631F031F000966972A2F5" [null]
Error from Tor process: dash.four.tor.torctl.TorControlError: Error reply: Unrecognized key "desc/id/$6330CCF8FEED2EF9B12FCF6688E2577C65522BA4" [null]
Exception in thread "Thread-0" dash.four.tor.torctl.TorControlError: Error reply: Unrecognized key "desc/id/$B749E078AD23AFA33D5BD2FF1AD15EE6409E3D04"
These are caused by the DebuggingEventHandler, and con.getInfo("desc/id/" + node) in particular.
Am I missing something or has the API changed in 0.2.4.3? the same code used to work, with very small exceptions in 0.2.3.x.
Let me know if you need any more info from me.
**Trac**:
**Username**: mr-4Tor: unspecifiedAaron GibsonAaron Gibsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7646fix/enhance getinfo ns/id/* commands2020-06-13T14:25:23ZTracfix/enhance getinfo ns/id/* commands1. Fix getinfo ns/id/*
See the last few comments on #7059 with regards to the ns/id/* getinfo command.
Currently, it only returns information about tor nodes which have microdescriptors and ignores those that use "normal" descriptors, i...1. Fix getinfo ns/id/*
See the last few comments on #7059 with regards to the ns/id/* getinfo command.
Currently, it only returns information about tor nodes which have microdescriptors and ignores those that use "normal" descriptors, in other words, it behaves exactly like the md/id/node command.
I can understand the rationale behind having desc/id/node to only show information about tor nodes with "normal" descriptors and I can understand the reasons for md/id/node to do the same for tor nodes with microdescriptors, but ns/id/node should, in my view, be implemented in such a way to return information about all tor nodes, regardless of whether or not they use microdescriptors, particularly so because by definition of this command in control-specs.txt it is supposed to return V2 directory info on all nodes without making such distinctions.
2. Enhance ns/* - just an idea (not a bug!): currently, there is no way I could get information on a tor node by specifying its ip address.
I would love to be able to get that information by executing something like "getinfo ns/ip/<ip_address>" (note the "ip" in the middle!). This should return information on all tor nodes with the specified ip address (and/or netmask), regardless of whether they use microdescriptors or not.
**Trac**:
**Username**: mr-4Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7282Create consensus-info directory commands2020-06-13T14:24:22ZMike PerryCreate consensus-info directory commandsWe should create a class of directory commands for use at dir mirrors that can be used to query for information about the current consensus without downloading the whole document.
The two commands that would be most useful are "What is ...We should create a class of directory commands for use at dir mirrors that can be used to query for information about the current consensus without downloading the whole document.
The two commands that would be most useful are "What is the timestamp of your current consensus?", and "What is the hash of your current consensus?".
These two will be useful for defense-in-depth items like #7126.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6505GETINFO dir/status-vote/current/consensus returns "Unrecognized key" if no co...2020-06-13T14:21:35ZZack WeinbergGETINFO dir/status-vote/current/consensus returns "Unrecognized key" if no consensus availableIf there is no consensus available, issuing a GETINFO command for dir/status-vote/current/consensus will return an "Unrecognized key" error instead of an empty string, which will make pytorctl crash.
Patch attached.If there is no consensus available, issuing a GETINFO command for dir/status-vote/current/consensus will return an "Unrecognized key" error instead of an empty string, which will make pytorctl crash.
Patch attached.Tor: unspecifiedZack WeinbergZack Weinberghttps://gitlab.torproject.org/legacy/trac/-/issues/6245Formatting 'getinfo address-mappings/all', and others2020-06-13T14:20:42ZgrarpampFormatting 'getinfo address-mappings/all', and othersPlease adjust the output of 'getinfo address-mappings/all' such
that when there is only one entry, it is presented on a new line
separate from the leading 250 header. ie: not this one liner...
250-address-mappings/all=*.example.com <fin...Please adjust the output of 'getinfo address-mappings/all' such
that when there is only one entry, it is presented on a new line
separate from the leading 250 header. ie: not this one liner...
250-address-mappings/all=*.example.com <fingerprint>.exit NEVERTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5847Better error message on GETINFO desc/* when you only have MDs.2020-06-13T14:19:34ZTracBetter error message on GETINFO desc/* when you only have MDs.The "GETINFO desc/id/OR identity" and "GETINFO desc/name/OR nick" options don't seem to work on the Tor control port:
GETINFO desc/id/DD397148A4AB4D43E5E6CB9C5F45E922872CC2D3
552 Unrecognized key "desc/id/DD397148A4AB4D43E5E6CB9C5F45E92...The "GETINFO desc/id/OR identity" and "GETINFO desc/name/OR nick" options don't seem to work on the Tor control port:
GETINFO desc/id/DD397148A4AB4D43E5E6CB9C5F45E922872CC2D3
552 Unrecognized key "desc/id/DD397148A4AB4D43E5E6CB9C5F45E922872CC2D3"
If I replace "desc" with "md" I get the expected response, and they're both described in the spec as taking the same arguments...
**Trac**:
**Username**: mickeycTor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5401tag control log events so arm can know they're from the same place in the code2020-06-13T14:18:16ZRoger Dingledinetag control log events so arm can know they're from the same place in the codeDamian told me at the dev mtg that arm is doing regexp backbends to recognize log line duplicates (it will merge all the logs that are basically saying the same thing into one, to make it easier to see what else is going on). If we provi...Damian told me at the dev mtg that arm is doing regexp backbends to recognize log line duplicates (it will merge all the logs that are basically saying the same thing into one, to make it easier to see what else is going on). If we provide a tag along with the log event, we would make his life easier.
It occurred to me that we could easily add a new "filename:line" param to controller events, since we already know it. (The tag doesn't have to be consistent across runs, just within a run.) We would probably want to declare the tag string opaque, so controllers don't get any ideas about doing more with it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5241Log location at DEBUG / INFO level2020-06-13T14:17:51ZDamian JohnsonLog location at DEBUG / INFO levelDuring the dev meeting I mentioned to Roger that a log message identifier would help me to deduplicate log messages with dynamic content.
Roger made the counter proposal that at high runlevels (NOTICE and above) any noisy logging is a b...During the dev meeting I mentioned to Roger that a log message identifier would help me to deduplicate log messages with dynamic content.
Roger made the counter proposal that at high runlevels (NOTICE and above) any noisy logging is a bug and at low runlevels (DEBUG and INFO) we could log the file and line number where the logging occurred. This would both help with tracing through the code and also be something that I could use for deduplication.
Cheers! -DamianTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4700Tor should provide a mechanism for hidden services to differentiate authorize...2020-06-13T14:16:00ZTracTor should provide a mechanism for hidden services to differentiate authorized clients and circuitsTor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exporte...Tor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exported.
**Trac**:
**Username**: katmagicTor: 0.3.5.x-final