Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:54:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18263GETCONF provides incorrect value when undefined2020-06-13T14:54:07ZDamian JohnsonGETCONF provides incorrect value when undefinedThis is kinda subtle but CommaList and RouterList values mistakenly include a '=' when undefined...
```
GETCONF ExcludeNodes
250 ExcludeNodes=
```
By contrast here's what Bridge, a LineList value, provides...
```
GETCONF Bridge
250 Br...This is kinda subtle but CommaList and RouterList values mistakenly include a '=' when undefined...
```
GETCONF ExcludeNodes
250 ExcludeNodes=
```
By contrast here's what Bridge, a LineList value, provides...
```
GETCONF Bridge
250 Bridge
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18224Tor control spec doesn't properly specify reply format2020-06-13T14:53:59ZcypherpunksTor control spec doesn't properly specify reply formatThe control spec does not sufficiently specify how to generically parse multi line replies from the controller. The intent seems to be that multi line response data is terminated by a '.' line.
However, this is not specified in the con...The control spec does not sufficiently specify how to generically parse multi line replies from the controller. The intent seems to be that multi line response data is terminated by a '.' line.
However, this is not specified in the control spec section 2.3 and the reply description there is insufficient to properly recognize multi-line reply packets leading to bugs like:
https://trac.torproject.org/projects/tor/ticket/16990Tor: unspecifiedGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/18157Which hidden services am I running?2020-06-13T14:53:47ZcypherpunksWhich hidden services am I running?Please create an easy way for the user, to query the onion addresses currently running by the tor client, and their respective port mappings, using the control port.
To get the onion addresses from the control port, the user has to go t...Please create an easy way for the user, to query the onion addresses currently running by the tor client, and their respective port mappings, using the control port.
To get the onion addresses from the control port, the user has to go through the data dump of "getinfo circuit-status", and try and locate the "REND_QUERY=" lines.
There is no way for seeing the assigned port mapping of those onion addresses using the control port.
The only available mean is to log at debug level and look for the lines
[debug] rend_add_service(): Service maps port 80 to 127.0.0.1:8080
I think this is important to allow the users to investigate, what applications, that use ADD_ONION, and has access to the tor control port, are doing exactly.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18117When stem calls controller.close_circuit(circuit_id), circuits don't really c...2020-06-13T14:53:37ZteorWhen stem calls controller.close_circuit(circuit_id), circuits don't really closeI'm using master (0.2.8-alpha-dev) and a stem script similar to the example custom_path_selection.py, but that calls controller.close_circuit(circuit_id) after using each circuit.
This may be related to the abort in #18116.
I get a lot...I'm using master (0.2.8-alpha-dev) and a stem script similar to the example custom_path_selection.py, but that calls controller.close_circuit(circuit_id) after using each circuit.
This may be related to the abort in #18116.
I get a lot of messages similar to this:
```
[notice] No circuits are opened. Relaxed timeout for circuit 170239 (a Circuit made by controller 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. 20 guards are live. [59 similar message(s) suppressed in last 3600 seconds]
```
It may be that the log message is just wrong, or it may be that stem isn't doing the right thing to close the circuit, or it may be that tor isn't really cleaning up well after controller circuits. The abort in #18116 suggests the latter.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2362"GETINFO config-text" adds spurious DataDirectory, Log entries2020-06-13T14:52:53ZDamian Johnson"GETINFO config-text" adds spurious DataDirectory, Log entriesRepro steps:
- use a blank torrc (just setting the ControlPort)
- run tor
- issue a GETINFO get-text
result: it provides a 'Log notice stdout' entry
expected: we should only get back entries that differ from their defaults (in this case...Repro steps:
- use a blank torrc (just setting the ControlPort)
- run tor
- issue a GETINFO get-text
result: it provides a 'Log notice stdout' entry
expected: we should only get back entries that differ from their defaults (in this case only the ControlPort)
from irc:
15:03 < armadev> atagar: it is a tor bug, i believe. i just reproduced.
15:03 < atagar> ok, I'll file a ticket - thanks :)
15:04 < armadev> if (smartlist_len(elts) == 0)
15:04 < armadev> smartlist_add(elts, tor_strdup("stdout"));
15:04 < armadev> in options_init_logs()
15:04 < armadev> that's where it comes from. we add it if there are no other logs.
15:04 < armadev> hmmmm. no, i take that back.
15:05 < armadev> /* Special case on first boot if no Log options are given. */
15:05 < armadev> if (!options->Logs && !options->RunAsDaemon && !from_setconf)
15:05 < armadev> config_line_append(&options->Logs, "Log", "notice stdout");
15:05 < armadev> there we go.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17901Tor would bind ControlPort to public ip address if it has no localhost interface2020-06-13T14:52:48Zs7rTor would bind ControlPort to public ip address if it has no localhost interfaceFreeBSD jails or some OpenVZ virtual machines do not have a `lo` interace (no 127.0.0.1 or localhost address), they only have an interface with either a public IP address either a NAT address routed upstream on the host.
In this case, i...FreeBSD jails or some OpenVZ virtual machines do not have a `lo` interace (no 127.0.0.1 or localhost address), they only have an interface with either a public IP address either a NAT address routed upstream on the host.
In this case, if ControlPort 9051 is set, it will open the control port on the public IP address without even a warning which is not funny. This applies also to SocksPort, but that's less scary than ControlPort.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17607Clean up section 2 in control-spec2020-06-13T14:51:04ZGeorg KoppenClean up section 2 in control-specThere are some definitions missing in section 2 in the control spec and we could do some small clean-up.There are some definitions missing in section 2 in the control spec and we could do some small clean-up.Tor: unspecifiedGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/17451Tor controller [ControlPort] - bruteforce defence measures & detailed logging...2020-06-13T14:50:42ZTracTor controller [ControlPort] - bruteforce defence measures & detailed logging when listening non-locallySometimes, as a relay operator, you should open your ControlPort to the world, because of various reasons - SSH is not always an option, you have application that implements Tor control protocol and it should control your OR remotely, et...Sometimes, as a relay operator, you should open your ControlPort to the world, because of various reasons - SSH is not always an option, you have application that implements Tor control protocol and it should control your OR remotely, etc.
When this happens, current controller implementation doesn't have any mechanism to prevent bruteforcing of the HashedControlPassword or the authentication cookie, and also the hypothetic attacker will remain compleatly anonymous (in general case, possible solution is to have another service monitoring the sockets and log the remote IP), because Tor doesn't log any data about him or her, like IP address, for example. Because of this behaviour, you also can't use software like fail2ban to ban the attackers based on the logged failed attempts.
Given all this, even with a strong enough passphrase, it becomes easy to break through the authentication and do a lot of bad things.
Tor should have a configuration directive to specify a limit of the number of allowed attempts when ControlPort socket is non-local. When the threshold is reached, Tor should block future attempts from this IP for a certain period of time.
The detailed logging will allow use of another software to take care in depth.
**Trac**:
**Username**: programingsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17287All new controller features are tested, and in use from stem and chutney2020-06-13T14:50:16ZNick MathewsonAll new controller features are tested, and in use from stem and chutneySee #17283 for making sure this is easy to do with stem, and #17284 for implementing the controller side of this all.
This is due September 2016.See #17283 for making sure this is easy to do with stem, and #17284 for implementing the controller side of this all.
This is due September 2016.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17284Implement multiple new testing-focused controller features2020-06-13T14:50:15ZNick MathewsonImplement multiple new testing-focused controller featuresSee https://lists.torproject.org/pipermail/tor-dev/2015-March/008502.html for a big pile of ideas; we should try to implement as many as possible.
Due April 2016.See https://lists.torproject.org/pipermail/tor-dev/2015-March/008502.html for a big pile of ideas; we should try to implement as many as possible.
Due April 2016.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/17120Fire a circuit status control port event when circuit isolation changes.2020-06-13T14:49:18ZYawning AngelFire a circuit status control port event when circuit isolation changes.Followup from #17086.
Currently trying to track circuit isolation status via control port events is non-trivial/impossible without polling due to predictive circuits and other non-SOCKS initiated circuits being used to service SOCKS req...Followup from #17086.
Currently trying to track circuit isolation status via control port events is non-trivial/impossible without polling due to predictive circuits and other non-SOCKS initiated circuits being used to service SOCKS requests.
The current behavior is correct according to the control port spec, since the username/password are only provided when the circuit was initiated via a SOCKS request, and is silent about `BUILT` circuits being used to immediately service a request.
This *should* be easy to do, but requires a control spec change and is an enhancement so it's a 0.2.8.x thing at the earliest.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16845make unverified consensus ISOTime accessible through Tor's ControlPort2020-06-13T14:48:21Zpropermake unverified consensus ISOTime accessible through Tor's ControlPortCurrently only verified, accepted Tor consensus ISOTime is available.
Quote [Tor control protocol](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt):
```
"consensus/valid-after"
"consensus/fresh-until"
"co...Currently only verified, accepted Tor consensus ISOTime is available.
Quote [Tor control protocol](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt):
```
"consensus/valid-after"
"consensus/fresh-until"
"consensus/valid-until"
Each of these produces an ISOTime describing part of the lifetime of
the current (valid, accepted) consensus that Tor has.
[New in Tor 0.2.6.3-alpha]
```
Unverified consensus ISOTime is unavailable.
This information is interesting in context for anonymity distributions and secure network time synchronization, usability and whatnot. Used by Tails' [tordate](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh) or Whonix's [anondate](https://www.whonix.org/wiki/Dev/TimeSync#anondate).
However, these tools rely on parsing Tor's log, which is [fragile](https://labs.riseup.net/code/issues/8977).
It would be nice, if something like
* `consensus-unverified/valid-after`
* `consensus-unverified/fresh-until`,
* and `consensus-unverified/valid-until`
where accessible through Tor's ControlPort.
```
Each of these produces an ISOTime describing part of the lifetime of
the unverified (invalid, rejected) consensus that Tor has.
[New in Tor 0.2.7.x-...]
```
This feature requests completes the related one `make certificate lifetime accessible through Tor's ControlPort` (#16822).
Use cases:
* clock slightly off: verified consensus (already implemented: #10395)
* clock more off: unverified consensus (this ticket)
* clock a lot off: certificate lifetime (#16822)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16822make certificate lifetime accessible through Tor's ControlPort2020-06-13T14:48:12Zpropermake certificate lifetime accessible through Tor's ControlPortI am referring to the following. Sometimes user Tor logs contain something like this.
```
Sep 03 10:32:59.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
Sep 03 10:32:59.000 [warn] (certi...I am referring to the following. Sometimes user Tor logs contain something like this.
```
Sep 03 10:32:59.000 [warn] Certificate already expired. Either their clock is set wrong, or your clock is wrong.
Sep 03 10:32:59.000 [warn] (certificate lifetime runs from Aug 16 00:00:00 2014 GMT through Jul 29 23:59:59 2015 GMT. Your time is Sep 03 10:32:59 2015 UTC.)
```
This information is interesting in context for anonymity distributions and secure network time synchronization, usability and whatnot. Used by Tails' [tordate](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh) or Whonix's [anondate](https://www.whonix.org/wiki/Dev/TimeSync#anondate).
However, these tools rely on parsing Tor's log, which is [fragile](https://labs.riseup.net/code/issues/8977).
It would be nice, if something like
* `certificate/valid-after`
* and `certificate/valid-until`
where accessible through Tor's ControlPort.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16636Add AccountingSetBytesRead/Written2020-06-13T14:47:32ZteorAdd AccountingSetBytesRead/WrittenA relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `Acco...A relay operator asked for the ability to reset the state file's `AccountingBytesReadInInterval` and `AccountingBytesWrittenInInterval` values.
While a workaround is to edit or delete the state file, perhaps command-line arguments `AccountingSetRead` and `AccountingSetWritten` could be useful.
See also #15989 for `AccountingRule` `in` and `out`, as well as the `AccountingEnableDirPort` override.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16059Add a "rendezvous approver" control API2020-06-13T14:46:15ZJohn BrooksAdd a "rendezvous approver" control APIFrom the discussion on mitigating HS denial of service in #16052:
> Add a "rendezvous approver" control API, which gives an opted-in controller the chance to approve or deny all rendezvous circuit and stream requests before they're act...From the discussion on mitigating HS denial of service in #16052:
> Add a "rendezvous approver" control API, which gives an opted-in controller the chance to approve or deny all rendezvous circuit and stream requests before they're acted upon. This would allow us to make more complex and useful mitigations as third party software.
This might be useful for:
* Rate limiting; at most N unauthenticated clients per Y
* Extra-conservative logic like "stop accepting connections during potential guard discovery"
* Limiting capacity to control server load; only allow N simultaneous clients.
* Protocol-tuned rules for things like Ricochet
* More advanced pre-rendezvous authorization
arma also noted:
> Speaking of the mitigator, the original HS design had the services giving out tokens to preferred users, who then use the token to get access during times of high load.
This could be built by using a new auth type for access tokens, and checking them in the approver.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15692'GETINFO config-file' command on ControlPort returns the standard torrc file ...2020-06-13T14:45:19Zyurivict271'GETINFO config-file' command on ControlPort returns the standard torrc file when it was overridden in the command line> GETINFO config-file
> 250-config-file=/usr/local/etc/tor/torrc
When command line begins with: --ignore-missing-torrc -f /no/file
Tor v0.2.6.6 (git-bb8c4e69ca5c8bca) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2a and ...> GETINFO config-file
> 250-config-file=/usr/local/etc/tor/torrc
When command line begins with: --ignore-missing-torrc -f /no/file
Tor v0.2.6.6 (git-bb8c4e69ca5c8bca) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2a and Zlib 1.2.8.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15333Minor control-spec.txt corrections.2020-06-13T14:44:26ZYawning AngelMinor control-spec.txt corrections.Re: SETCONF:
> Tor responds with a "250 configuration values set" reply on success.
> If some of the listed keywords can't be found, Tor replies with a
According to git blame that hasn't been the case since... 2008? 2007?
```
...Re: SETCONF:
> Tor responds with a "250 configuration values set" reply on success.
> If some of the listed keywords can't be found, Tor replies with a
According to git blame that hasn't been the case since... 2008? 2007?
```
case SETOPT_OK:
config_free_lines(lines);
send_control_done(conn);
return 0;
```
> Sent from the client to the server. The syntax is as for GETCONF:
> "GETINFO" 1*(SP keyword) CRLF
> one or more NL-terminated strings. The server replies with an INFOVALUE
> message, or a 551 or 552 error.
"one or nor NL-terminated strings" is confusing. Did a newline and a word get cutoff somewhere, or am I just being dense?Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15061Support Ed25519 identities in controller interface2020-06-13T14:43:51ZNick MathewsonSupport Ed25519 identities in controller interfaceOnce #12498 is merged, we'll be able to identify nodes by ed25519 keys. We should allow the controller to do this too.
This might be a use case for USEFEATURE -- `USEFEATURE ed25519-ids` could allow us to describe nodes by their best k...Once #12498 is merged, we'll be able to identify nodes by ed25519 keys. We should allow the controller to do this too.
This might be a use case for USEFEATURE -- `USEFEATURE ed25519-ids` could allow us to describe nodes by their best keys, and we could accept ed25519 keys regardless.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15000bring some sanity to quoted strings in the controller api2020-06-13T14:43:32ZNick Mathewsonbring some sanity to quoted strings in the controller api#14999 is about a possible mass migration to doing QuotedString right... but we can at least fix the things introduced in #8405, since we *know* they won't break any users.#14999 is about a possible mass migration to doing QuotedString right... but we can at least fix the things introduced in #8405, since we *know* they won't break any users.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14999Most/all esc_for_log instances in control.c should change.2020-06-13T14:43:31ZNick MathewsonMost/all esc_for_log instances in control.c should change.In the discussion on ticket #14555 and earlier on #4600, we realized that esc_for_log() should not be used for strings sent to the controller.
Unfortunately it is, so in b9302fb0aa2d5b635002bc5bf50219d42b90d9d7 and later I documented th...In the discussion on ticket #14555 and earlier on #4600, we realized that esc_for_log() should not be used for strings sent to the controller.
Unfortunately it is, so in b9302fb0aa2d5b635002bc5bf50219d42b90d9d7 and later I documented that.
But we should fix it instead.Tor: unspecified