Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-10-19T13:34:55Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3948"fooport auto" should be able to get a hint2021-10-19T13:34:55ZRoger Dingledine"fooport auto" should be able to get a hintIn legacy/trac#3945 we learned that "socksport auto" (as implemented in legacy/trac#3076) on Windows is confusing users who use external applications that expect Tor to be listening on port 9050. The "fix" was to disable using auto ports...In legacy/trac#3945 we learned that "socksport auto" (as implemented in legacy/trac#3076) on Windows is confusing users who use external applications that expect Tor to be listening on port 9050. The "fix" was to disable using auto ports in the TBB 0.2.2 Windows bundles.
A better answer to this issue is to
A) teach Tor how to remember which port it used last time, and try that one first (legacy/trac#3511)
B) seed it with our favorite port, e.g. by setting another config option like "SocksPortPreferred 9050". Maybe it would try both the preferred port and the one it picked last time, in some order. My first thought is that it should try the previous one first, and fall back to the configured preference before falling back to a random high-numbered port.
If we want to get fancier, we could make the prefered list be a 'schedule' of ports to try, e.g. for ORPortPreferred it could be "443,80".
Picking a more normal port should also help the Comodo firewall users in legacy/trac#3941 who are being blocked from reaching their high-numbered port.https://gitlab.torproject.org/tpo/core/tor/-/issues/13386"opening new log file" line goes to err-logfile despite being at loglevel notice2020-07-24T16:14:13Ztoralf"opening new log file" line goes to err-logfile despite being at loglevel noticeAlthough I might image the rationale behind it, it is still confusing, that lines like
[notice] Tor 0.2.5.8-rc (git-a64f3ab3ee5c433c) opening log file.
are in the err log file for a torrc config like this :
# logging
#
Log notic...Although I might image the rationale behind it, it is still confusing, that lines like
[notice] Tor 0.2.5.8-rc (git-a64f3ab3ee5c433c) opening log file.
are in the err log file for a torrc config like this :
# logging
#
Log notice file /var/log/tor/notice.log
Log warn file /var/log/tor/warn.log
Log err file /var/log/tor/err.log
Either the prefix "[notice]" should be changed to "[err]" or probably scrubbed away completely.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15660[feature suggestion] Need signal to totally switch to the new set of circuits2022-06-16T15:24:48Zyurivict271[feature suggestion] Need signal to totally switch to the new set of circuitsCurrently there is the control command
```
SIGNAL NEWNYM
```
which according to specification "switches to clean circuits, so new application requests don't share any circuits with old ones." It however doesn't affect the old connections...Currently there is the control command
```
SIGNAL NEWNYM
```
which according to specification "switches to clean circuits, so new application requests don't share any circuits with old ones." It however doesn't affect the old connections, which still go through the old set of circuits.
There is the legitimate need to completely switch to the new set of circuits, with termination of all old connections.
I am suggesting to add the parameter to NEWNYM signal. It can be a string parameter, to keep it general and explicit. Syntax that will work like NEWNYM but will also terminate old connection could look like this:
```
SIGNAL NEWNYM TERMINATE
```
The old syntax will assume this parameter to be empty, and will work like before.
On the user level, wherever they see the button "New Identity", they will either have another button next to it "New Identity (force-close old connections)", or the yes/no choice "force-close old connections" next to the original button.
My motivation: I had this question before myself, and now I saw somebody else asking it on tor-talk@: "Why my exit node doesn't change when I press 'New Identity' button?"https://gitlab.torproject.org/tpo/core/tor/-/issues/4391`GETINFO ns/all` doesn't return 'p' lines -- make something that does!2021-06-18T18:25:22ZTrac`GETINFO ns/all` doesn't return 'p' lines -- make something that does!The ns/all GETINFO controller command doesn't send any p lines. The spec doesn't actually require them, but they'd be helpful to have.
**Trac**:
**Username**: katmagicThe ns/all GETINFO controller command doesn't send any p lines. The spec doesn't actually require them, but they'd be helpful to have.
**Trac**:
**Username**: katmagichttps://gitlab.torproject.org/tpo/core/tor/-/issues/3587Accounting should work with pluggable transports2022-06-16T15:56:58ZGeorge KadianakisAccounting should work with pluggable transportsA bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to legacy/trac#3586)A bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to legacy/trac#3586)https://gitlab.torproject.org/tpo/core/tor/-/issues/16636Add AccountingSetBytesRead/Written2021-06-18T18:15:52ZteorAdd 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 legacy/trac#15989 for `AccountingRule` `in` and `out`, as well as the `AccountingEnableDirPort` override.https://gitlab.torproject.org/tpo/core/tor/-/issues/8786Add extra-info line that tracks the number of consensus downloads over each p...2022-05-23T20:34:06ZGeorge KadianakisAdd extra-info line that tracks the number of consensus downloads over each pluggable transportIn legacy/trac#5040, Karsten suggested to add yet another line for measuring obfsbridge stats.
He wants a `dirreq-v3-transport` line with the exact same format as `bridge-ip-transports`, that counts consensus fetches instead of direct c...In legacy/trac#5040, Karsten suggested to add yet another line for measuring obfsbridge stats.
He wants a `dirreq-v3-transport` line with the exact same format as `bridge-ip-transports`, that counts consensus fetches instead of direct connections. This will improve the granularity of bridge statistics, and it will help us count users accurately in scenarios like flashproxy (where each client is actually a flashproxy bridge).
This means that we should be considering the `GEOIP_CLIENT_NETWORKSTATUS_V2` and `GEOIP_CLIENT_NETWORKSTATUS` events in this case, instead of `GEOIP_CLIENT_CONNECT`.https://gitlab.torproject.org/tpo/core/tor/-/issues/10451Allow me to have a short HeartBeatPeriod2020-06-27T14:03:35ZcypherpunksAllow me to have a short HeartBeatPeriod```
Dec 20 20:07:47.000 [warn] HeartbeatPeriod option is too short; raising to 1800 seconds.
```
```
HeartbeatPeriod 5 minutes
```
```
Tor version 0.2.4.19 (git-9a83ee5e4d3cece4).
```
Please let me have a short HeartbeatPeriod! It'd be ...```
Dec 20 20:07:47.000 [warn] HeartbeatPeriod option is too short; raising to 1800 seconds.
```
```
HeartbeatPeriod 5 minutes
```
```
Tor version 0.2.4.19 (git-9a83ee5e4d3cece4).
```
Please let me have a short HeartbeatPeriod! It'd be appreciated. Sometimes, I can't run tor-arm but I want frequent status updates.https://gitlab.torproject.org/tpo/core/tor/-/issues/10307Allow Tor relays to configure bandwidth limits around peak usage2020-07-24T15:20:56ZTracAllow Tor relays to configure bandwidth limits around peak usageThe bandwidth limits specific by a Tor config and available via control port are very limited and coarse.
It would be useful to support dynamic limits, additional consensus flags, and control port capabilities to support dynamic bandwid...The bandwidth limits specific by a Tor config and available via control port are very limited and coarse.
It would be useful to support dynamic limits, additional consensus flags, and control port capabilities to support dynamic bandwidth limits that adjust to peak load patterns to maximize off peak use of idle bandwith while be able to efficiently handle changing router capacities at a finer than consensus level granularity.
Preliminary or stop-gap efforts have included control port scripting to alter HSdir, Dir, Exit policy, egress shaping, and other techniques to achieve poor or moderate control over bandwidth usage beyond config max rates.
**Trac**:
**Username**: anonTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31851Allow Tor to be compiled without support for relay mode2020-07-29T13:50:39ZteorAllow Tor to be compiled without support for relay modeLet's make some more optional modules.
Our target set of modules might include:
* dirauth - the code only used by directory authorities (including bridge authorities)
* dircache - the code only used by directory caches and directory aut...Let's make some more optional modules.
Our target set of modules might include:
* dirauth - the code only used by directory authorities (including bridge authorities)
* dircache - the code only used by directory caches and directory authorities
* relay - the code only used by relays and directory authorities
* common - the code used by all roles
I'll do a design, and a proposed CI build strategy, and then get it reviewed.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4855Allowing TOR to use LAN and other connections, not only internet2020-07-29T15:49:55ZTracAllowing TOR to use LAN and other connections, not only internetSince the threat of internet censorship, I've been looking for a system that allows connected computers to share data anonymously, and even create 'alternate internets' via mesh networking. I believe this would be a great feature for TOR...Since the threat of internet censorship, I've been looking for a system that allows connected computers to share data anonymously, and even create 'alternate internets' via mesh networking. I believe this would be a great feature for TOR, and wanted to suggest it for a while. This is what I had in mind:
Currently, TOR locates nodes on the internet and sends data between them. My request is making internet no longer be a requirement for TOR, but just one way of connecting. By giving TOR the ability to reach nodes on other computers using any means of communication... including a Local Area Network, WIFI, and maybe even Bluetooth.
There are two reasons why I suggest this. The first is to allow computers without an internet connection (but part of a LAN) to connect using TOR. For instance, let's say an user has been banned by his ISP from using the internet at all (happens in some countries). However, he can still be part of the LAN in his area. One of his neighbors runs a TOR node, which either exits to an internet connection or leads to another TOR node that does. The disconnected user could travel to the exit node from computer to computer, TOR acting as usual from there on.
The second reason is to make TOR usable for 'alternative internets'. This is an idea of the future, but with the fear of censorship I see it coming. Basically, an area of computers which can contact each other could establish its own private network to share data, host websites, etc. without touching the actual internet. But despite not finding any software that can do this (let alone anonymously), users creating an alternate internet could still be persecuted for sharing "illegal data" if they are caught. Using TOR's system, it would be impossible to tell who in the network is hosting what.
How TOR could do mesh networking and private internet: There is a LAN network running multiple computers, none of them connected to the actual internet. One of them wants to host a website accessible to the cloud. He would create a TOR node for that, exiting to the folder where he's hosting his files or website. The user wanting to reach his page would write the IP or URL in his web browser, then TOR would go from node to node inside the cloud, looking for the computer hosting that page. Once it finds it, it establishes a permanent connection, encrypting it using any available nodes it can relay the connection through in that cloud.
In my opinion, TOR would be a great candidate for this, and would allow even more users to connect, share data and evade censorship. It could even combine both ideas... by connecting to a LAN node, then an internet node, then going through another group of LAN computers, etc. TOR could automatically choose the best path to a resource, such as determining if it's located on the internet or a direct device, if to use an internet or a LAN node, etc. So all the user must do is type the URL and have TOR figure where and how to find it. I believe this would extend possibilities greatly, and really hope the idea can be considered.
**Trac**:
**Username**: MirceaKitsunehttps://gitlab.torproject.org/tpo/core/tor/-/issues/18142Anti-Automated-Scanning: Support "marking" with iptables TCP connections diff...2022-06-16T18:13:01ZnaifAnti-Automated-Scanning: Support "marking" with iptables TCP connections differently "for each circuits"This ticket is to support "marking" with iptables TCP connections differently "for each circuits".
The basic idea is that a Tor Exit operator, in order to reduce automated scanning, may wish to apply specific rate limiters available fro...This ticket is to support "marking" with iptables TCP connections differently "for each circuits".
The basic idea is that a Tor Exit operator, in order to reduce automated scanning, may wish to apply specific rate limiters available from the iptables stack of his linux machine.
The usual Tor connection pattern of an automated scan, from a Tor Exit relay point of view, is that from a single circuit there are a lot of TCP connections going out to the same host within a relatively short amount of time.
The usual HTTP(S) connection pattern of normal Browser, from a Tor Exit relay point of view, is to open a bunch of connection to the same IP and keep those open with keep-alive.
So, if Tor software would made available to Iptables stack the "individual marking" of all TCP connections coming out of a specfic circuit, it would be possible for the Tor Exit operator to apply rate limiting finely tuned in a way not to break normal end-user browsing but to break automated scanner efficiency.
Obviously, that works against automated scanners that does not apply a specific technique to bypass this specific prevention technique, that shall be considered most of the automated scanners.https://gitlab.torproject.org/tpo/core/tor/-/issues/13987Apply laplace noise to other statistics2022-09-01T21:32:18ZNick MathewsonApply laplace noise to other statisticsIn legacy/trac#13192, we included a facility to obscure hidden service stats by adding laplace noise. What do think about applying laplace noise to the other statistics we report?In legacy/trac#13192, we included a facility to obscure hidden service stats by adding laplace noise. What do think about applying laplace noise to the other statistics we report?https://gitlab.torproject.org/tpo/core/tor/-/issues/27047Authorities should keep recent consensuses, votes, and bandwidth files2022-09-01T21:29:26ZteorAuthorities should keep recent consensuses, votes, and bandwidth filesMoving https://trac.torproject.org/projects/tor/ticket/21378#comment:12 into a separate ticket:
Quoting teor:
> Replying to teor:
> > Replying to irl:
> > > Using the fixed URL http://<hostname>/tor/status-vote/next/bandwidth.z sounds ...Moving https://trac.torproject.org/projects/tor/ticket/21378#comment:12 into a separate ticket:
Quoting teor:
> Replying to teor:
> > Replying to irl:
> > > Using the fixed URL http://<hostname>/tor/status-vote/next/bandwidth.z sounds like it would be very easy to add this to CollecTor.
> >
> > Thanks for the feedback!
> >
> > > We have discussed in the Metrics team extending `dir-spec.txt` to allow to fetch "recent" files as well as just next/current. In the case that there is a wide CollecTor outage, and we miss a file, it would be good to have those files cached (on a best-effort basis, not necessarily persisted to disk) and available via some URL.
> >
> > How is this any different to losing descriptors or consensuses?
> > (Please answer this question on a separate ticket.)
> >
> > > I don't know if karsten already had some ideas about what these URLs would look like, but we should perhaps consider this before implementing changes to `dir-spec.txt`.
> >
> > Please open a separate ticket for this feature. It's potentially a large feature. And it's not essential for the initial release of this feature.
>
> If you open a separate ticket for historical directory documents, please make legacy/trac#26698 a child of that ticket. We'll need bandwidth file hashes to work out the exact file used in each vote.https://gitlab.torproject.org/tpo/core/tor/-/issues/10968Authorities should use past consensuses to decide how to vote on relay flags2022-06-16T18:23:34ZGeorge KadianakisAuthorities should use past consensuses to decide how to vote on relay flagsAt the moment, each authority decides what flags to assign to each node based on its own memory. This means that authorities that have been started recently have a different impression -- compared to more long-lived authorities -- about ...At the moment, each authority decides what flags to assign to each node based on its own memory. This means that authorities that have been started recently have a different impression -- compared to more long-lived authorities -- about some relays .
Something that might make more sense is if authorities used past consensuses to get a better idea about the stability and speed of relays.
Since authorities don't keep past consensuses around, a way to do the above might be to create a script that each authority runs, downloads the past consensuses, calculates statistics about all nodes, and then it creates a file with those statistics. Then the authority loads that file, and uses it to update its knowledge base.
There might be better approaches.https://gitlab.torproject.org/tpo/core/tor/-/issues/23512Bandwidth stats info leak upon close of circuits with queued cells2020-06-27T13:55:38ZGeorge KadianakisBandwidth stats info leak upon close of circuits with queued cellsWe received a tor bug bounty report from `jaym` about a congestion attack variant that can cause bandwidth stats watermark.
The bug uses the fact that Tor increments the _read bytes counter_ before adding the cell to the output buffer:...We received a tor bug bounty report from `jaym` about a congestion attack variant that can cause bandwidth stats watermark.
The bug uses the fact that Tor increments the _read bytes counter_ before adding the cell to the output buffer: If the circuit gets killed before the cell gets relayed to the next hop, then the _write bytes counter_ will never be updated, making the _read bytes counter_ having a higher value than the _write bytes counter_. The attacker could exploit this assymetry to find relays using their bandwidth graph.
The attacker can kill the circuit using the OOM killer by saturating its output queue with cells until `circuits_handle_oom()` gets called and kills the circuit.
We should figure out whether this attack is practical (the paper claims it is) and whether it's worthwhile fixing it. Just fixing this issue won't solve the general issue of congestion attacks, and it might even allow other kinds of attacks.
The most practical fix right now seem to be to hack circuit_handle_oom()` to actually decrement the read counters before killing a circuit. However, that's a very specific fix that might solve this very specific bug, but leave the rest of the bug class open.
Another approach would be removing the bandwidth graphs, or aggregating them over a greater period of time, or adding noise. We should consider these approaches carefully since bandwidth graphs see great use by academic papers and also by relay operators (to gauge their contribution).Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10957Be more aggressive about enabling Extended ORPort2020-07-24T15:32:03ZGeorge KadianakisBe more aggressive about enabling Extended ORPortBridges without Extended ORPort do not publish statistics about usage. Some people really care about statistics.
In legacy/trac#9651 (merged in 0.2.5.1) we decided to add a warning if the user has PTs but no Extended ORPort.
Maybe we s...Bridges without Extended ORPort do not publish statistics about usage. Some people really care about statistics.
In legacy/trac#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/tpo/core/tor/-/issues/16966Better solution for an HS client descriptor cache entry to expire2020-07-24T18:05:45ZDavid Gouletdgoulet@torproject.orgBetter solution for an HS client descriptor cache entry to expireWith legacy/trac#16389, we've added a 5 minutes timeout for an entry in the client descriptor cache to expire which is not ideal (details here https://trac.torproject.org/projects/tor/ticket/16389#comment:16).
One solution would be to a...With legacy/trac#16389, we've added a 5 minutes timeout for an entry in the client descriptor cache to expire which is not ideal (details here https://trac.torproject.org/projects/tor/ticket/16389#comment:16).
One solution would be to add a counter in the hidden service descriptor that changes at with a new descriptor. To quote arma's in comment above:
```
Maybe this argues for hidden services putting the nonce into their HS descs
anyway, and publishing an updated HS desc every time they lose contact with
their intro points, to give clients a way to recognize when the HS has
acknowledged that things changed? Yuck.
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4850Build multiple circuits and use the fastest?2020-06-27T14:07:01ZArturo FilastòBuild multiple circuits and use the fastest?This mostly applies to a usecase such as tor2web where you have a lot of requests in a certain time frame. It might be a good idea to have more than one active circuit towards a certain hidden service (the top 10).
By building more than...This mostly applies to a usecase such as tor2web where you have a lot of requests in a certain time frame. It might be a good idea to have more than one active circuit towards a certain hidden service (the top 10).
By building more than one circuit towards a hidden service you are then able to collect some benchmark data with all your active circuits and determine which are the fastest ones and which are the slowest.
The benchmark collection and optimization of circuits by speed could be useful also for the normal user of Tor HS, however it might have some bad anonymity consequences.
Q: Is it a bad idea to discard slow circuits towards Tor HS and keep only fast ones?
notes: Keep in mind that you have no control over the circuit on the Hidden Service side and that building a new circuit takes quite a lot of time.
Q: What privacy implications does such a feature have?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16646Cannibalized intro point circuits are now 4 hops, instead of 3 (HS-side)2020-08-03T13:08:19ZGeorge KadianakisCannibalized intro point circuits are now 4 hops, instead of 3 (HS-side)The fix of legacy/trac#16260 makes hidden services establish a 4-hop introduction circuit, if they cannibalized during introduction circuit construction.
This was done mainly to prevent circuit fingerprinting according to the latest USE...The fix of legacy/trac#16260 makes hidden services establish a 4-hop introduction circuit, if they cannibalized during introduction circuit construction.
This was done mainly to prevent circuit fingerprinting according to the latest USENIX paper, but it's unclear whether making only this change helps with anything.
Hence, the performance penalty of 4-hops might be more important here.
Another question, is how often do introduction circuits get cannibalized? It might be that it often happens, since this step is done in the very beginning when there are a few internal circuits lying around. But I might be very wrong.Tor: unspecified