Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:51:18Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17659BUG : connection_ap_mark_as_pending_circuit()2020-06-13T14:51:18ZcypherpunksBUG : connection_ap_mark_as_pending_circuit()
```
Nov 23 [...] [warn] connection_ap_mark_as_pending_circuit(): Bug: What?? pending_entry_connections already contains 0x81b488f8! (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8...
```
Nov 23 [...] [warn] connection_ap_mark_as_pending_circuit(): Bug: What?? pending_entry_connections already contains 0x81b488f8! (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e10248 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81ab0338 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81a007d8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b45800 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e10170 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b279e8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81d66cb8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e11558 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x816458a8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x815c11a0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81d4ddb8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81563fa0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b45f80 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8129f718 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x814c7350 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8158c3b0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x819f4a48 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17576Add torrc option to disable default fallback directories2020-06-13T14:50:53ZteorAdd torrc option to disable default fallback directoriesThere's no easy way to disable the default fallback directories.
Tails depends on using the authorities for its consensuses as part of its time syncing proof:
https://tails.boum.org/contribute/design/Time_syncing/#index1h2
We should pr...There's no easy way to disable the default fallback directories.
Tails depends on using the authorities for its consensuses as part of its time syncing proof:
https://tails.boum.org/contribute/design/Time_syncing/#index1h2
We should provide an option to disable the default fallback directories entirely. (It should also conflict with any FallbackDir lines.)
Default fallbacks are also disabled when any other fallbacks are added, or when using non-default authorities.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17273Complete a design for isolating Tor modules2020-06-13T14:50:08ZNick MathewsonComplete a design for isolating Tor modulesWe've been kicking this around for a while; we should actually commit to something in a text file so we can argue about it. December is a good target.We've been kicking this around for a while; we should actually commit to something in a text file so we can argue about it. December is a good target.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17270Evaluate non-C tor implementations for hackability2020-06-13T14:50:07ZNick MathewsonEvaluate non-C tor implementations for hackabilityFor testing, we should have badly-behaved clients and servers. But implementing that in C seems like horrible overkill. Let's look at the best-of-breed compatible implementations, and figure out which one would be the best basis for ma...For testing, we should have badly-behaved clients and servers. But implementing that in C seems like horrible overkill. Let's look at the best-of-breed compatible implementations, and figure out which one would be the best basis for making a bunch of stub test client/servers.
(It's okay if the client answer and the server answer aren't the same)Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17269Draft process to ensure tickets and proposals get reviewed2020-06-13T14:50:06ZNick MathewsonDraft process to ensure tickets and proposals get reviewedOur current process doesn't do much to provide a deadline by which people can expect that their patches will be reviewed. It also doesn't push proposals towards an up/down resolution.
We need to make changes in this area, since having ...Our current process doesn't do much to provide a deadline by which people can expect that their patches will be reviewed. It also doesn't push proposals towards an up/down resolution.
We need to make changes in this area, since having a bunch of "needs_review" items sticking around is bad for getting volunteers online and making Tor better.
Target: Nov 2015.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17260Triage all items for 0.2.82020-06-13T14:50:02ZNick MathewsonTriage all items for 0.2.8Target date: 15 October 2015.
Remaining steps are:
* Make sure that every item on the roadmaps has a corresponding ticket.
* Prioritize items, under the assumption we can't possibly do them all so we'll probably need to aim for the ...Target date: 15 October 2015.
Remaining steps are:
* Make sure that every item on the roadmaps has a corresponding ticket.
* Prioritize items, under the assumption we can't possibly do them all so we'll probably need to aim for the really critical ones first.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16861Pad Tor connections to collapse netflow records2020-06-13T14:54:41ZMike PerryPad Tor connections to collapse netflow recordsThe collection of traffic statistics from routers is quite common. Recently, there was a minor scandal when a University network administrator upstream of UtahStateExits (and UtahStateMeekBridge) posted that they had collected over 360G ...The collection of traffic statistics from routers is quite common. Recently, there was a minor scandal when a University network administrator upstream of UtahStateExits (and UtahStateMeekBridge) posted that they had collected over 360G of netflow records to boingboing:
https://lists.torproject.org/pipermail/tor-relays/2015-August/007575.html
Unfortunately, the comment has since disappeared, but the tor-relays archives preserve it.
This interested me, so I asked some questions about the defaults and record resolution, and did some additional searching. It turns out that Cisco IOS routers have an "inactive flow timeout" that by default is 15 seconds, and it can't be set lower than 10 seconds. What this timeout does is cause the router to emit a new netflow "record" for a connection that is idle for that long, even if it stays open. Several other routers have similar settings. The Fortinet default is also 15 seconds for this. For Juniper, it is also 30 seconds (but Juniper routers can set it as low as 4 seconds).
With this information, I decided to write a patch that sends padding on a client's Tor connection bidirectionally at a random interval that we can control from the consensus, with a default of 4s-14s. It only sends padding if the connection is idle. It does not pad connections that are used only for tunneled directory traffic.
It also gives us the ability to control how long we keep said connections open. Since the default netflow settings for Cisco also generate a record for active flows after 30 minutes, it doesn't make a whole lot of sense to pad beyond that point.
This should mean that the total overhead for this defense is very low, especially since we have recently moved to only one guard. Well under 50 bytes/second for at most 30 minutes.
I still have a few questions, though, which is why I put so many people in Cc to this ticket. I will put my questions in the first comment.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/16651Tor fails to build on OpenBSD 5.8 due to libevent config options2020-06-16T01:26:59ZteorTor fails to build on OpenBSD 5.8 due to libevent config optionsCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15233Form a plan for killing off 0.2.2 and 0.2.32020-06-13T14:45:50ZNick MathewsonForm a plan for killing off 0.2.2 and 0.2.3#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15056Support ed25519 identities for circuit extension2020-06-13T15:04:05ZNick MathewsonSupport ed25519 identities for circuit extensionOnce #12498 is merged and #15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Once #12498 is merged and #15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15055Implement ed25519 link handshake2020-06-13T15:05:30ZNick MathewsonImplement ed25519 link handshakeIn #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.In #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12538Make all relays automatically be dir caches2020-06-13T18:13:30ZcypherpunksMake all relays automatically be dir cachesDuring the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to director...During the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to directory servers.
This is easier nowadays than in the past because `BEGIN_DIR` makes it so that directory servers don't need to have a separate DirPort open. (However, maybe relays get the `V2Dir` flag only if they have a DirPort open?)
Also, since all relays have all the directory documents anyway, it doesn't further bloat their disk to become directory servers.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5460Write proposal(s) to implement improved relay/circuit crypto authentication2020-06-13T14:50:11ZMike PerryWrite proposal(s) to implement improved relay/circuit crypto authenticationWe need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it...We need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it, there are two competing possibilities:
1. Self-authenticating crypto (BEAR/LION/LIONESS, others?)
2. Per-hop MAC
The main disadvantage of 1 is that it's likely slow and not very many people use it. The disadvantage of 2 is that it requires us to disclose path length count and position to nodes, as well as have MACs that either grow with increased path length, or become less secure with increased path length.
There are probably other issues. I believe the current plan is to produce both options in one or more proposals and compare and contrast them.Tor: 0.2.8.x-finalNick MathewsonNick Mathewson