Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:43:50Zhttps://gitlab.torproject.org/legacy/trac/-/issues/6676Nuke ‘MyFamily’2020-06-13T14:43:50ZRobert RansomNuke ‘MyFamily’For reasons discussed in #5565, the ‘MyFamily’ option should go away:
* It is probably harmful for clients to refuse to use two relays operated by the same honest entity, and malicious relay operators will not use MyFamily honestly.
*...For reasons discussed in #5565, the ‘MyFamily’ option should go away:
* It is probably harmful for clients to refuse to use two relays operated by the same honest entity, and malicious relay operators will not use MyFamily honestly.
* Honest relay operators have a hard time setting MyFamily correctly on all of their relays.
* Relay family information bloats up microdescriptors, likely for no benefit.
* Groups of relays operated by the same entity can be recognized tolerably well (e.g. for metrics purposes) using their ContactInfo string instead (modulo the possible need for fuzzy matching of some sort).
This change requires (assuming I didn't forget anything):
* a proposal, spec change, and consensus method to remove relay family information from microdescriptors;
* a corresponding code change for Tor dirauths;
* a code change to clients to make them ignore relay family information (if they receive it, e.g. by turning off UseMicrodescriptors) by default, and warn if the user tries to re-enable use of relay family information without disabling UseMicrodescriptors.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6504Support Windows environment variables in HiddenServiceDir2020-06-13T14:21:35ZTracSupport Windows environment variables in HiddenServiceDirExpansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win3...Expansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win32 will take care of any necessary.
One direct benefit to you devs is that you could then use '%UserProfile%' in the HiddenServiceDir examples for Windows in your documentation, such as the one discussed in !#4798, yielding the appropriate location in every version that Tor supports.
This behavior could/should eventually broadened to all options for which a path can be specified (e.g. DataDirectory, GeoIPFile, PidFile), so if the fix would affect the opening of other paths (I haven't looked through the source code), all the better. If the fix isn't in a core function, I'd be happy to add a new, broader, ticket.
P.S. The version I'm using is actually 0.2.2.37, but I don't see it in the list.
**Trac**:
**Username**: criticoderTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6311Migrate TOR_SEARCH_LIBRARY to use pkg-config2020-06-13T14:20:55ZNick MathewsonMigrate TOR_SEARCH_LIBRARY to use pkg-configTOR_SEARCH_LIBRARY is a hard-to-maintain fragile garden of venomous snakes, all waiting to bite you at the same time.
I'm working on a patch to migrate to pkg-config. pkg-config is everywhere these days, and where it isn't, we can fal...TOR_SEARCH_LIBRARY is a hard-to-maintain fragile garden of venomous snakes, all waiting to bite you at the same time.
I'm working on a patch to migrate to pkg-config. pkg-config is everywhere these days, and where it isn't, we can fall back to the old thing for a while.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5968Improve onion key and TLS management2022-03-22T12:59:29ZMike PerryImprove onion key and TLS managementAs a best practice behavior, a relay should check that the onion key it tried to publish is actually the one it sees in the consensus in which it appears.
The onion key should also be what authenticates the TLS key (rather than the iden...As a best practice behavior, a relay should check that the onion key it tried to publish is actually the one it sees in the consensus in which it appears.
The onion key should also be what authenticates the TLS key (rather than the identity key, as it is now).
This would prevent some utility vectors of identity key theft, where a non-targeted upstream MITM attempts to use a relays identity to impersonate it in order to execute a tagging attack (#5456).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5965Flag important sections of Torbutton code for preservation2012-07-10T18:50:14ZMike PerryFlag important sections of Torbutton code for preservationI should do a pass over the Torbutton code and mark the sections that we want to keep (or toss) somehow, to make #5709+#1506 easier.I should do a pass over the Torbutton code and mark the sections that we want to keep (or toss) somehow, to make #5709+#1506 easier.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5565MyFamily should provide an alternate non-idhex subscription mechanism2020-06-13T14:43:50ZMike PerryMyFamily should provide an alternate non-idhex subscription mechanismEverybody hates MyFamily. It's cumbersome, hard to update, hard to spot check that it's correct, and it gets in the way of vastly improving the practical security of the network through ephemeral identity keys (#5563).
So first off, wha...Everybody hates MyFamily. It's cumbersome, hard to update, hard to spot check that it's correct, and it gets in the way of vastly improving the practical security of the network through ephemeral identity keys (#5563).
So first off, what is wrong with making this PoS an arbitrary token ("OurFamily" anyone?) If weirdos start joining families that people don't want them to, can't we just de-list those nodes?
If we really can't handle the risk of people joining arbitrary families for any period of time, we could deploy a signature scheme where a node has to sign its IP+OrPort, current idhex, and/or nickname using a family key and place that signature into its MyFamily field.
We could even make this an incrementally deployable solution. We could first make the new field free-form, and then later update it to require authentication with a family key.
But my guess is this is not worth significant engineering, and we should just make it a free-form token and de-list nodes who try to adopt themselves into random families without consent.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5553prevent protocol leaks; Tor client connection API or protocol review howto2020-06-13T17:35:52Zproperprevent protocol leaks; Tor client connection API or protocol review howtoI am unhappy with the current [Torify instructions](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO).
The [big bittorrent leak](https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea) may happen to any applica...I am unhappy with the current [Torify instructions](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO).
The [big bittorrent leak](https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea) may happen to any application, which has not been explicitly designed for Tor or reviewed by someone. That's why safe use of Tor is at the moment somewhat limited to the few applications designed over Tor (Tor Browser) or reviewed for use over Tor.
Two ideas will follow how to solve this problem. One or another may work as solution. Feel free to propose other/better/easier/faster solutions.
Proposal 1:
Write a howto, how to review an application and protocol for leak free use over Tor. "The protocol/application has to be reviewed." - That is much to vague, even for the application's developer.
For example, would the xchat developers answer "xchat over Tor: do not use dcc/ctcp... it leaks your IP/timezone..."?
What we easily could do for many applications, would be asking the application's developers. But even them could be confused by the question. The paper should define, what a protocol leak is, how to look out for them, how to prevent them.
This would hopefully enable the application developers to answer to the question regarding the protocol leak status. And if they don't want to review their own application, third party contributors could review the protocol.
Proposal 2:
Provide an alternate interface for applications. An alternative to socks. Either an API or libery for developers. i2p does also provide one and loads of applications are build on top of i2p. Why there are not so many applications designed for Tor? Because there is neither an API nor an libery.Tor: unspecifiedColin ChildsColin Childshttps://gitlab.torproject.org/legacy/trac/-/issues/5081autoreload ServerTransportPlugin process when the underlying binary changes o...2020-06-13T14:17:18Zweasel (Peter Palfrader)autoreload ServerTransportPlugin process when the underlying binary changes or requests it?<weasel> does tor restart obfsproxy when it notices it has changed?
<armadev> very unlikely
<armadev> define 'changed'?
<weasel> inode or mtime changed.
<armadev> ah. definitely no.
<armadev> please file a ticket?
<weasel> I think it sho...<weasel> does tor restart obfsproxy when it notices it has changed?
<armadev> very unlikely
<armadev> define 'changed'?
<weasel> inode or mtime changed.
<armadev> ah. definitely no.
<armadev> please file a ticket?
<weasel> I think it should.
<weasel> wilco
<armadev> how often should it check inode or mtime?
<weasel> the other options is that obfsproxy should check if it has changed
<weasel> ideally no matter how it's done it wouldn't affect existing connections
<armadev> the connections go through obfsproxy
<armadev> so you want the old one to stay alive, even though the new one is in use
<weasel> yesTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4826Write proposal for improved consensus voting schedules2020-06-13T14:16:30ZRoger DingledineWrite proposal for improved consensus voting schedulesSebastian suggests that we revise the schedule for consensus voting such that there's a cutoff after which we discard votes from the original authority. So phase 1a is to publish your vote to every authority, phase 1b is to ask every aut...Sebastian suggests that we revise the schedule for consensus voting such that there's a cutoff after which we discard votes from the original authority. So phase 1a is to publish your vote to every authority, phase 1b is to ask every authority for votes you're missing, and during phase 1b we won't accept phase 1a votes.
The goal here is to avoid consensus failures that occur when an authority uploads a vote during phase 1b, and some authorities end up thinking everybody knows it, yet some don't know it.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4712Review and update any existing patches for proposal 182 ("credit buckets")2020-06-13T17:47:22ZKarsten LoesingReview and update any existing patches for proposal 182 ("credit buckets")We should review any existing patches for proposal 182 and update them for merging them into master. This is part of #4682.We should review any existing patches for proposal 182 and update them for merging them into master. This is part of #4682.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4696add OutboundBindInterface option to torrc2020-06-13T14:15:56ZTracadd OutboundBindInterface option to torrcFirst, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
...First, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
There are quite a few instances where OutboundBindAddress option is not suitable, particularly where the IP address changes frequently (vpn as well as most dhcp-dependant interfaces).
Whether I use OutboundBindAddress or just leave tor to make a decision which address to bind to is not suitable (at least) in the following two cases:
1. When I temporarily loose my IP address which tor has used up until now due to dhcp client renewing its lease (and receive a new IP address) and that doesn't happen - for whatever reason - instantly.
This results in one of two possible - wrong - outcomes: a) in case of absence of OutboundBindAddress option, Tor decides that my IP address "has changed" and tries to bind to the default interface, which may not be the one I have used previously; or b) when OutboundBindAddress is specified, tor just sits there trying to use the "old" address specified, resulting in a stall.
2. When I temporarily loose my current IP address due to vpn connection becoming (temporarily) unstable and it takes a bit of time for my machine to renew its IP address (this may take from a minute to up to 20+ minutes depending on the status of the vpn server at the other end) the outcome is exactly the same as I listed above - tor either tries to use the default interface (wrong!) or tries to bind to the IP address I specified with OutboundBindAddress (wrong again).
With the introduction of this new (OutboundBindInterface) option, tor can follow the IP address on the specified *interface* (regardless of what that might be) and the above - erroneous - outcome could be avoided.
**Trac**:
**Username**: mr-4Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4565Enable relays to talk to other relays via IPv62020-06-13T14:21:11ZKarsten LoesingEnable relays to talk to other relays via IPv6We need to extend Tor for relays to talk to other relays via IPv6. This task depends on #4564. The exact steps will be described in the roadmap that comes out of #4556.
This ticket is an _optional_ deliverable for June 30, 2012 for sp...We need to extend Tor for relays to talk to other relays via IPv6. This task depends on #4564. The exact steps will be described in the roadmap that comes out of #4556.
This ticket is an _optional_ deliverable for June 30, 2012 for sponsor G.Tor: unspecifiedLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/4113Clean up and post Tor Browser Design Doc2011-10-07T23:53:09ZMike PerryClean up and post Tor Browser Design DocThe design doc needs to be merged and cleaned up a little before posting. More will still need to be done to get it out of draft status, but let's just post it first.The design doc needs to be merged and cleaned up a little before posting. More will still need to be done to get it out of draft status, but let's just post it first.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3846Recruit build test/signoff volunteers2020-06-13T01:07:49ZMike PerryRecruit build test/signoff volunteersI still think it is a good idea to get tor-talk volunteers to commit to testing builds for us. We created this table for them to fill in but then forgot about it: https://trac.torproject.org/projects/tor/wiki/doc/build/BuildSignoff
Ther...I still think it is a good idea to get tor-talk volunteers to commit to testing builds for us. We created this table for them to fill in but then forgot about it: https://trac.torproject.org/projects/tor/wiki/doc/build/BuildSignoff
There also used to be a pastebin or google doc with a testing checklist + instructions in it? Is that lost forever?Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3733Tor should abandon rendezvous circuits that cause a client request to time out2020-06-13T14:12:26ZRobert RansomTor should abandon rendezvous circuits that cause a client request to time out```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice...```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:10.634 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:30.680 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
```
All of these streams had been attached to the same rendezvous circuit.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3666SafeCache key is only 32bit2020-06-13T00:26:54ZMike PerrySafeCache key is only 32bitWe need to extend the key that safecache uses either to a 64bit int, or just add an additional string key. 32bits is too small: the birthday paradox says that 1 in every 64k domains will collide to the same id, allowing identifier sharing.We need to extend the key that safecache uses either to a 64bit int, or just add an additional string key. 32bits is too small: the birthday paradox says that 1 in every 64k domains will collide to the same id, allowing identifier sharing.TorBrowserBundle 2.2.x-stableMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/3587Accounting should work with pluggable transports2020-06-13T14:11:55ZGeorge KadianakisAccounting should work with pluggable transportsA bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to #3586)A bridge operator supporting pluggable transports should still be able to enforce accounting policies.
(This is also related to #3586)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3566Should controller events respect SafeLogging 1 torrc option?2020-06-13T14:11:51ZTracShould controller events respect SafeLogging 1 torrc option?Vidalia seems not to scrub addresses ignoring SafeLogging directive set in the torrc config file : the first one is the event logged by Vidalia , the second one is the same event logged by Tor while pulling tor git tree with tsocks ( 'us...Vidalia seems not to scrub addresses ignoring SafeLogging directive set in the torrc config file : the first one is the event logged by Vidalia , the second one is the same event logged by Tor while pulling tor git tree with tsocks ( 'usewithtor git pull' on the command line )
[...same time...] Potentially Dangerous Connection! - One of your applications established a connection through Tor to "38.229.70.11:9418" using a protocol that may leak information about your destination. Please ensure you configure your applications to use only SOCKS4a or SOCKS5 with remote hostname resolution.
...same time... [warn] Your application (using socks5 to port 9418) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see https://wiki.torproject.org/TheOnionRouter/TorFAQ#SOCKSAndDNS.
**Trac**:
**Username**: tornewbieTor: unspecifiedTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/3501Teach Tor to run the Control Port over TLS2020-06-13T14:11:33ZJacob AppelbaumTeach Tor to run the Control Port over TLSI've been discussing how we can use Vidalia with chiiph as a Tor controller over a network - this would be useful for the Torouter for example.
I think that a TOFU (Trust On First Use) model is probably best and that would mean we'd sim...I've been discussing how we can use Vidalia with chiiph as a Tor controller over a network - this would be useful for the Torouter for example.
I think that a TOFU (Trust On First Use) model is probably best and that would mean we'd simply need a Tor Control Port that uses a static TLS cert/key combo. I guess we could do a bare key or we could do the full x509 nightmare. I don't really have a preference.
This would allow us to control Tor safely as the control port data exported by Vidalia doesn't seem safe to expose to an attacker.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3330Evangelize private browsing improvements2011-06-16T02:10:21ZMike PerryEvangelize private browsing improvementsWe should write a blog post describing our ideal private browsing mode. Along the way, I should add my thoughts about the ThirdParty cookie policy to the Mozilla bugzilla, and also review and comment on their Privacy Roadmap.We should write a blog post describing our ideal private browsing mode. Along the way, I should add my thoughts about the ThirdParty cookie policy to the Mozilla bugzilla, and also review and comment on their Privacy Roadmap.Mike PerryMike Perry