Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:23:34Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25609Investigate Tor client retry behavior on failing onions2020-06-13T15:23:34ZGeorge KadianakisInvestigate Tor client retry behavior on failing onionsAn attacker can cause a Tor client to create many circuits by continuously serving a broken/failing onion over and over again.
We should investigate how many circuits a Tor client is willing to setup for an onion with a non-existent des...An attacker can cause a Tor client to create many circuits by continuously serving a broken/failing onion over and over again.
We should investigate how many circuits a Tor client is willing to setup for an onion with a non-existent descriptor, or an onion that is unwilling to rendezvous, and see if this is a security issue.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25568hs: Lookup failure cache when introducing to an intro point2020-06-13T15:23:25ZDavid Gouletdgoulet@torproject.orghs: Lookup failure cache when introducing to an intro pointIt turns out that if a descriptor contains 10 times the same intro point, and that the first introduction attempt fails, we'll try to connect to the same failing intro point again for all subsequent remaining intro points.
The intro poi...It turns out that if a descriptor contains 10 times the same intro point, and that the first introduction attempt fails, we'll try to connect to the same failing intro point again for all subsequent remaining intro points.
The intro point failure cache was introduced to avoid such a situation but it is only used between two descriptors that is if an intro point failed from the first descriptor and that intro point is still present in the second descriptor fetched, we ignore it.
However, this situation is about the same intro point in the same descriptor. In normal circumstances, this can't happen but it is still allowed by the protocol.
One issue with this is that a malicious service would induce many circuits out of the client than necessary. This can be used, theoretically, for a client guard discovery attack.
This affects both v2 and v3.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25477Stop warning users about bug #210182020-06-13T15:22:56ZGeorge KadianakisStop warning users about bug #21018While working on #14389 we figured out that when a Tor client connects to an onion service with authorization without the proper authorization client config (or non-existent auth config), Tor will throw out 6 warnings like this:
```
[wa...While working on #14389 we figured out that when a Tor client connects to an onion service with authorization without the proper authorization client config (or non-existent auth config), Tor will throw out 6 warnings like this:
```
[warn] Failed to parse introduction points. Either the service has published a corrupt descriptor or you have provided invalid authorization data, or (maybe!) the server is deliberately serving broken data in an attempt to crash you with bug 21018.
```
We should consider removing the alarmist warn about bug #21018 at some point, and maybe that point is now, since it might freak out users for no reason and there is no way for us to learn whether the attack took place.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/25456tor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernate2020-06-13T15:22:51ZIsis Lovecrufttor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernateI very often need to SIGHUP my tor process after reopening my laptop after the new guard algorithm was merged (I had to also do so before, but now it's seemingly worse), and I hear from other users who are more technically-inclined that ...I very often need to SIGHUP my tor process after reopening my laptop after the new guard algorithm was merged (I had to also do so before, but now it's seemingly worse), and I hear from other users who are more technically-inclined that there experience is the same. Humans doing things computers can do is bad UX. I propose, at the very least, on *nix systems that we modify the systemd `.service` file(s) we already distribute to do this for the human. (We should also figure out some equivalent for MacOS, Windows, and mobile, if possible, but those can be separate tickets.)
From reading [this question](https://askubuntu.com/questions/661715/make-a-script-start-after-suspend-in-ubuntu-15-04-systemd/661747#661747) that femme linked me to, it looks like the way to do it is either a script which gets installed into `/lib/systemd/system-sleep/`, or a second `.service` file that is wanted by `suspend.target`. I'm not sure which is cleaner? I would assume the `.service` file approach is cleaner, because then it can be selectively enabled/disabled by the human more easily.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25441Occasional timing? failures in hs_descriptor/validate_cert unit test2020-06-13T15:22:49ZteorOccasional timing? failures in hs_descriptor/validate_cert unit testI see failures like this occasionally on a macOS VM when using Rust. Is there some weird timing issue, or is the Rust code interfering with the validation?
```
hs_descriptor/validate_cert: [forking]
FAIL ../src/test/test_hs_descripto...I see failures like this occasionally on a macOS VM when using Rust. Is there some weird timing issue, or is the Rust code interfering with the validation?
```
hs_descriptor/validate_cert: [forking]
FAIL ../src/test/test_hs_descriptor.c:710: assert(ret OP_EQ 1): 0 vs 1
[validate_cert FAILED]
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25436Remove from fallback.whitelist, add to fallback.blacklist 328E54981C6DDD7D89B...2020-06-13T16:06:28ZTracRemove from fallback.whitelist, add to fallback.blacklist 328E54981C6DDD7D89B89E418724A4A7881E3192-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please remove:
80.127.117.180:80 orport=443 id=328E54981C6DDD7D89B89E418724A4A7881E3192 ipv6=[2001:985:e77:10::4]:443 # sjc01
from fallback.whitelist, and add it to the fallback.blacklis...-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please remove:
80.127.117.180:80 orport=443 id=328E54981C6DDD7D89B89E418724A4A7881E3192 ipv6=[2001:985:e77:10::4]:443 # sjc01
from fallback.whitelist, and add it to the fallback.blacklist. I'll keep the relay running for the next year and a half as requested / promissed.
-----BEGIN PGP SIGNATURE-----
iQQzBAEBCgAdFiEEjP0TTVqsQl6bFzvJtbKWBxlMOw8FAlqeMq4ACgkQtbKWBxlM
Ow//AyAAkQf+v8pb1jFyxxlr1bhkWEwu7vPe5WK55bOVCbE/fhT5K864sLfeNA0s
gFGJR57GPS5XHDmtP3x9XIT4TkwsByYoKXikW1Enr3NGspuODjF5JQi8IAtahVdg
kqHOeyMufVdYPRfKE9YFZqeF0gkYMo9nRi7/3x/EmF7AXZSR836RYonpAvj7FW7C
n3nDHSOG3t5iewL3dJFYk4pvPsvHMgoytJAXcsyjXL7Srnf6Gtk4SqA9/0QUcDOm
PGFSPjiysoJ20GF1OxCO5A153ENL92P81K9hq/RJV9KlM0POBah5ioGwEs4OskbA
hIMuD9ccKiAyPTgtufcfGstocADPkCDGj+AYQe842t3PdC+n7snEv3mcQBtcU1qa
yxiljyWA2DOAE5SYyieESE73aJ9jK5i85UWk7yxJHxnKmQrtZ0a2LK+eAijQ8QrI
HcmkKf+tyLycftZv35j0tDeDsSvy2aMAOlmnwSUr9cP8tH3hX3yyN9SyHcoVib/h
6sozasisxdMjENFD3kjWl/PO3XDGDuvGXOFVHso1GyKeQRbHSqL12hS/chQFwYx7
FF1qR2F22ZV0CWugNjBve1mStcqUbkAzMPddRI7IWw3dDK3wreedBDwuBq+13Muv
mWtmfDcPUIBaUOUHZlCHgFuHyUj3CpoGL9oVgM+YuzkT90rVHwUkxEVweirs48X8
lQ+xb5dSxVxWaXTxJ5h7tkzWcf1i2QQmrY/GLcOWZEvkBIar7RUgIuMOyzzTVZaY
27EyJuWtPpt5tQ/klE8VAWrOEAHGw8P/dflBgDdMiVrnREy3wpN0DltkDVldIHKT
YE6MpBqxUFBwMe7Waf3IH7ODDDr2qjhSIlbFGWs8Ax27GRB/TrN/Gl3Eu05GpdU1
DSIzkcDpYJ0DFA+UrRWjoYDBuJnPhsdbFjIVLPj95xRxTdQCQZhMYZ8oQnIwISIS
d1R1Tc6nbRzQ1gqmsgn0SWdpjPYthCcqrs7nqD/woe3hHR7n2CMDFgI/73FozH40
3p6Zj/Nzxg2KH00Q1tckP7uEMQpjnMlM93M1phm8HAycYsclKWXSrgo/z7pwwW0+
+ZpZwThq2tYxqmWyivuGqA9gfyyAwtv15n2xx+pv3D1yzBaeMDyaXBZG1Ky+gXZR
Mj7ObME8ber8EYdX3IQ5GMdkQnNURKxlUw5arjcutKl7w5L2pK6+qI7uC81JIhqL
SvAPONWI9SUgblmHxhOMtUlQesazEdURjhDqHjtGyO3EyYcFM0BrNinQTHBN8uwU
A/zzqZVHf4MhXOQdWjJc5y4v0mgeJhRFV3+JBZuZAE5CWnCF8AROYujnZZOPXcFO
8elWAN+Ah9g/CUQMh1AMu+8TzIl7pA==
=O9d/
-----END PGP SIGNATURE-----
**Trac**:
**Username**: sjcjonkerTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25416[warn] Received http status code 404 ("Consensus is too old") from server '19...2020-06-13T15:22:44Ztoralf[warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, strat...the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, stratum 2, offset -0.000601, delay 0.02594
server 2a01:238:439c:1900::3:1, stratum 2, offset 0.000477, delay 0.04520
server 2a02:16d0:0:4::4, stratum 2, offset -0.002245, delay 0.03976
server 90.187.7.5, stratum 2, offset -0.002271, delay 0.04788
server 129.70.132.36, stratum 2, offset 0.002152, delay 0.04262
server 145.239.3.131, stratum 2, offset 0.001487, delay 0.03177
server 85.236.36.4, stratum 2, offset -0.000501, delay 0.03650
3 Mar 17:18:09 ntpdate[18195]: adjust time server 2a01:4f8:221:3b02::101:1 offset -0.000601 sec
```
And I still get once a day or so _:
```
Mar 03 17:18:01.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
Mar 03 17:18:01.000 [notice] Tor 0.3.4.0-alpha-dev (git-efc105716283bbdf) opening log file.
Mar 03 17:18:02.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
```
tor version is 0.3.4-alpha-devTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25414Fallback details changed for 9FBEB75E8BC142565F12CBBE078D63310236A3342020-06-13T16:06:28ZTracFallback details changed for 9FBEB75E8BC142565F12CBBE078D63310236A334Hi!
Please remove "Lindon" 9FBEB75E8BC142565F12CBBE078D63310236A334 from the fallback directory list. The tor node will be shut down in the near future.
Best regards
Sven
**Trac**:
**Username**: svengoHi!
Please remove "Lindon" 9FBEB75E8BC142565F12CBBE078D63310236A334 from the fallback directory list. The tor node will be shut down in the near future.
Best regards
Sven
**Trac**:
**Username**: svengoTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25412TrackHostExits option in torrc file not working as documented2020-06-13T15:22:41ZTracTrackHostExits option in torrc file not working as documented1. Shut down Tor
2. Edit torrc file at c:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc so that it has the line:
TrackHostExits .
According to docs, this should mean to use the same exit node for all websites.
3. L...1. Shut down Tor
2. Edit torrc file at c:\Program Files (x86)\Tor Browser\Browser\TorBrowser\Data\Tor\torrc so that it has the line:
TrackHostExits .
According to docs, this should mean to use the same exit node for all websites.
3. Launch Tor, and open any two websites - let's say https://duckduckgo.com/ and https://www.nasa.gov/
4. Note that the exit node for each website may differ. If not reproducing, try using the IP addresses rather than URLs.
Why is this a problem? Some sites will generate a link that only works from the same IP as the original page. (In my case, one link is an IP that cannot be resolved to a URL, so using a URL isn't an option.)
Version: Tor 7.5 (The versions in the picker are massively out of date - not a good sign.)
**Trac**:
**Username**: LittleTorFanAnnieTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25381Add crypto_rand_double_sign() in C and Rust2020-06-13T15:22:33ZteorAdd crypto_rand_double_sign() in C and RustWe need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in bot...We need a function that returns 1.0 or -1.0 with equal probability, so we can avoid weird tricks that waste floating point precision.
Since we want to use this in the laplace and guassian distributions, it needs to be implemented in both C and Rust.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25371Add a consensus parameter for blocking single hop client intro2020-06-13T15:22:26ZteorAdd a consensus parameter for blocking single hop client introIn #22689, we allow single hop client intro when the service is multi-hop.
But we might want to block it entirely some time in the future.In #22689, we allow single hop client intro when the service is multi-hop.
But we might want to block it entirely some time in the future.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25328cmux: Refactor, test and improve performance of the circuitmux subsystem2020-06-13T15:22:18ZDavid Gouletdgoulet@torproject.orgcmux: Refactor, test and improve performance of the circuitmux subsystemThe cmux subsystem (`src/or/circuitmux.c`) is part of tor's fast path. It gets called at every cell or at every few cell and every new or dying circuit.
It is currently in our top 5 of CPU hugger (see #25152) and also has a certain comp...The cmux subsystem (`src/or/circuitmux.c`) is part of tor's fast path. It gets called at every cell or at every few cell and every new or dying circuit.
It is currently in our top 5 of CPU hugger (see #25152) and also has a certain complexity to it. However, in practice, it should be quite simple. #25268 helps a lot by removing dead code and helping making the code more readable.
In order to improve that subsystem, there are few steps that need to be taken before we can address something like #25152. Furthermore, in order to fix some things in the scheduler (#23993), this work should be done so we don't add more complexity to that code.
Refactoring this subsystem to something more simple also will help testing it for which right now, it is virtually untested (see `src/test/test_circuitmux.c`).
I'm taking this ticket because I do have planned out this work already and it might change over time.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25312circ: We can pick an active circuit that is marked for close2020-06-13T15:22:15ZDavid Gouletdgoulet@torproject.orgcirc: We can pick an active circuit that is marked for closeThe issue lies in when we detach cicuits from the cmux.
The function `circuitmux_get_first_active_circuit()` returns the first active circuit from the given cmux (attached to the channel).
But, when we mark for close a circuit, we don'...The issue lies in when we detach cicuits from the cmux.
The function `circuitmux_get_first_active_circuit()` returns the first active circuit from the given cmux (attached to the channel).
But, when we mark for close a circuit, we don't detach it from the cmux, it is only done "before free" so the result is that `cmux->policy->pick_active_circuit()` can return a marked for close circuit then a cell is dequeued from it and sent on the wire.
In my experimentation, I only saw END, DROP and TRUNCATED relay commands being sent on the wire from a marked for close circuit. Thus, I don't think that is currently such a big problem but still, not that good I would say.
We should assume that from the time the circuit is marked for close, nothing should go outbound on it from that point on.
Possible solution would be to detach the circuit from the cmux when marked for close or make the active circuit function ignore closed circuit.
Not sure at this point about backport.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25284hidden-service-dir description in dir-spec should reference HSDir protovers2020-06-13T17:58:08Zteorhidden-service-dir description in dir-spec should reference HSDir protoversSince 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified...Since 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified, it defaults to version 2 descriptors"Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25277Summarise the format of v3 hidden service addresses in the Tor man page2020-06-13T15:22:08ZTracSummarise the format of v3 hidden service addresses in the Tor man pageWe have regexes for ~~v1~~ v3:
```
^[a-z2-7]{56}\.onion$
```
where the last digit is always "d".
and v2:
```
^[a-z2-7]{16}\.onion$
```
What do the new addresses look like, do they have the same characters and just 56 of them? This sho...We have regexes for ~~v1~~ v3:
```
^[a-z2-7]{56}\.onion$
```
where the last digit is always "d".
and v2:
```
^[a-z2-7]{16}\.onion$
```
What do the new addresses look like, do they have the same characters and just 56 of them? This should be in the manual, which says:
```
Valid onion addresses contain 16 characters in a-z2-7 plus ".onion", and valid auth cookies contain 22 characters in A-Za-z0-9+/.
```
**Trac**:
**Username**: ageisp0lisTor: unspecifiedtraumschuletraumschulehttps://gitlab.torproject.org/legacy/trac/-/issues/25269Set codegen-units to 1 in src/rust/Cargo.toml to eke out every last drop of p...2020-06-13T15:22:06ZcypherpunksSet codegen-units to 1 in src/rust/Cargo.toml to eke out every last drop of performanceRust 1.24 now sets codegen-units to 16 by default to speed up compilation time but it makes the final binary slower https://blog.rust-lang.org/2018/02/15/Rust-1.24
> For maximum speed, setting `codegen-units` to `1` in your `Cargo.toml`...Rust 1.24 now sets codegen-units to 16 by default to speed up compilation time but it makes the final binary slower https://blog.rust-lang.org/2018/02/15/Rust-1.24
> For maximum speed, setting `codegen-units` to `1` in your `Cargo.toml` is needed to eke out every last drop of performance.
So [src/rust/Cargo.toml](https://gitweb.torproject.org/tor.git/tree/src/rust/Cargo.toml) should be changed with that to squeeze the most perf.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25237spec: Document our circuit close reasons2020-06-13T15:21:58ZDavid Gouletdgoulet@torproject.orgspec: Document our circuit close reasonsIn `or.h`, we define the reason to close a circuit:
```
/* Reasons why we (or a remote OR) might close a circuit. See tor-spec.txt for
* documentation of these. */
#define END_CIRC_REASON_MIN_ 0
#define END_CIRC_REASON_NONE ...In `or.h`, we define the reason to close a circuit:
```
/* Reasons why we (or a remote OR) might close a circuit. See tor-spec.txt for
* documentation of these. */
#define END_CIRC_REASON_MIN_ 0
#define END_CIRC_REASON_NONE 0
#define END_CIRC_REASON_TORPROTOCOL 1
#define END_CIRC_REASON_INTERNAL 2
#define END_CIRC_REASON_REQUESTED 3
...
```
Even though it says "See tor-spec.txt", those values aren't defined at all in tor-spec.txt, only the stream reasons are.
This is a bit annoying because these values don't have any documentation on why and when they should be used.Tor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/25227Avoid storing all Tor nodes in RAM2020-06-13T15:21:57ZteorAvoid storing all Tor nodes in RAM```
<teor4> ahf: I've been thinking about reducing Tor's RAM usage by sampling from each consensus, rather than keeping it all in RAM
<teor4> there are ways to stream the consensus, pick a weighted sample, and just keep those nodes
<teor...```
<teor4> ahf: I've been thinking about reducing Tor's RAM usage by sampling from each consensus, rather than keeping it all in RAM
<teor4> there are ways to stream the consensus, pick a weighted sample, and just keep those nodes
<teor4> https://en.wikipedia.org/wiki/Reservoir_sampling
<teor4> it would really help the iOS VPN, and other embedded impls
<teor4> The catch is that if you run out of sampled nodes, you need to re-parse the consensus
<+ahf> teor4: i had been thinking a bit in the back of my head if we could refactor the code that is used for accessing the consensus to be a bit more pluggable to experiment with different ways of backing them
<+ahf> teor4: on ios i think we can mmap() files without them adding to the memory limit of the application too
<teor4> that would be helpful, because we could only keep the selected node queues in RAM
<teor4> if we got the queue size right, we could regenerate them once per consensus
<+ahf> do you want to create a ticket with this? maybe add sponsor8-can to the keywords
```
We could be smart about node selection, and just store some weights for each node. And then when we use too much RAM for nodes, we could evict older nodes.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25224Create a new consensus method that ignores guardfraction votes2020-06-13T15:21:55ZteorCreate a new consensus method that ignores guardfraction votesAnd here is how we remove code that depends on consensus method 20 (the guardfraction method):
1. Create a new consensus method that ignores guardfraction votes. This new method can go in 034.
2. Change all the code that says ">= MIN M...And here is how we remove code that depends on consensus method 20 (the guardfraction method):
1. Create a new consensus method that ignores guardfraction votes. This new method can go in 034.
2. Change all the code that says ">= MIN METHOD FOR GUARDFRACTION" to say ">= MIN METHOD FOR GUARDFRACTION and < MIN METHOD TO IGNORE GUARDFRACTION" (the new method). This disables guardfraction when the new method or any later method is used. See consensus method 28 for an example of the code and spec that we need to remove a consensus feature.
3. When we will never revert to a lower consensus method (two releases later, 036), stop authorities voting for the buggy methods 20-28, and remove a whole bunch of old code, including all the guardfraction code.
4. At that time, we might want to remove all the methods lower than 20, too. See #24378.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25203document max. value of SigningKeyLifetime2020-06-13T15:21:51Zcypherpunksdocument max. value of SigningKeyLifetimetor's manpage says:
> SigningKeyLifetime N days|weeks|months
> For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept
> offline, and periodically generates new "signing" keys tha...tor's manpage says:
> SigningKeyLifetime N days|weeks|months
> For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept
> offline, and periodically generates new "signing" keys that it uses online. This option configures their lifetime.
> (Default: 30 days)
It does not include information about what is the biggest acceptable value. Tor simply fails to start if the given value is to big:
```
[warn] Interval 'XX months' is too long
[warn] Failed to parse/validate config: Interval 'SigningKeyLifetime XX months' is malformed or out of bounds.
```
Please also mention if there is a value for SigningKeyLifetime where it is actually less safe than running in non-OfflineMasterKey mode (maybe it is less safe to set it to 10y in OfflineMasterKey mode than to run in non-OfflineMasterKey mode?) and if it makes any sense to modify this value in non-OfflineMasterKey mode (because that is apparently possible).Tor: unspecified