Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-07-29T15:04:49Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29296Look into alternatives for distributing bridge info to clients2021-07-29T15:04:49ZCecylia BocovichLook into alternatives for distributing bridge info to clientsThe traditional way of distributing bridge information is to give bridge IP/connection information through BridgeDB and add that information to the Tor Browser configuration.
Snowflake and meek handle "bridge" information differently at...The traditional way of distributing bridge information is to give bridge IP/connection information through BridgeDB and add that information to the Tor Browser configuration.
Snowflake and meek handle "bridge" information differently at the client side, and we might like to consider a broader application of the Snowflake/broker style of distributing bridges. To do so, we should look into what changes we need to make at the client side to make this distribution easier.https://gitlab.torproject.org/legacy/trac/-/issues/29207New design for broker -- proxy protocol for snowflakes2020-06-13T18:19:33ZCecylia BocovichNew design for broker -- proxy protocol for snowflakes This is related to the Snowflake protocol design tickets #29206 and #29293.
We want to write these protocols in a way that is not Snowflake-specific but allows any type of bridge to connect to or poll our broker/BridgeDB bridge distrib... This is related to the Snowflake protocol design tickets #29206 and #29293.
We want to write these protocols in a way that is not Snowflake-specific but allows any type of bridge to connect to or poll our broker/BridgeDB bridge distribution service.
The idea is that in the beginning we will start with very reliable "bridge" (which could be snowflakes) that perhaps rotate IP addresses every month or so. After that we can collect measurements and move towards more ephemeral "bridges".
Some things to keep in mind are the types of information that the snowflakes give to the broker (such as proxy version/type) to allow for metrics. This information might change so we'll want a flexible and extensible protocol.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/21816Add support for Pluggable Transports 2.02020-06-13T15:07:29ZChelsea KomloAdd support for Pluggable Transports 2.0In the Pluggable Transport 2.0 specification, the IPC specification changes the way per-connection params are sent from Tor to the managed proxy. In order to support this new change, we need to change which Socks Auth method is used to c...In the Pluggable Transport 2.0 specification, the IPC specification changes the way per-connection params are sent from Tor to the managed proxy. In order to support this new change, we need to change which Socks Auth method is used to convey parameters (this allows backwards compatibility).
The current issue is that per connection parameters are overriding the authentication parameters, and we want to allow for longer auth params.
Ian took a look at the code, and identified some places where we need changes:
- connection.c, lines 2225
- connection.c, case statement at 2402
The IPC framework will need to declare which version it is, and Tor will need to parse this information.
We will also need to upgrade the managed proxy which is bundled with Tor in order to support the PT 2.0 IPC method. We will open a separate ticket for this.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13887Pick a reporting format for Chutney2020-06-13T13:29:06ZNick MathewsonPick a reporting format for ChutneyWe need some way for Chutney to tell another process about the events it's seeing.
Options include CTF, json, protocolbufs, line-based text.
See https://lists.torproject.org/pipermail/tor-dev/2014-December/007898.html for a synopsis of...We need some way for Chutney to tell another process about the events it's seeing.
Options include CTF, json, protocolbufs, line-based text.
See https://lists.torproject.org/pipermail/tor-dev/2014-December/007898.html for a synopsis of goals.
I'm especially interested in dgoulet's opinion on CTF in particular.
I'm especially interested in atagar's opinion about what would be friendliest to a stem-based chutney.https://gitlab.torproject.org/legacy/trac/-/issues/9273Brainstorm tradeoffs from moving to 2 (or even 1) guards2020-06-13T14:30:32ZRoger DingledineBrainstorm tradeoffs from moving to 2 (or even 1) guardsThere are now many conflicting issues to consider when changing the default number of guards. I'd like to write a proposal suggesting we move to 2 (or even 1), but I don't think I'm ready to write the analysis section yet.
Here's a star...There are now many conflicting issues to consider when changing the default number of guards. I'd like to write a proposal suggesting we move to 2 (or even 1), but I don't think I'm ready to write the analysis section yet.
Here's a start:
Pro 1: Reduces chance of using an adversary's guard. This argues for 1, but 2 would still be a lot better. See Tariq's WPES 2012 paper for details.
Pro 2: Reduces impact from guard fingerprinting: if the adversary learns that you have the following n guards, and later sees an anonymous user with the same guards, how likely is it to be you? Said another way, a trio of guards produces a cubic, whereas a duo of guards produces a quadratic. Somebody should do the math to sort out the chance of having all possible trios of guards, followed by the expected uniqueness of a trio. I expect moving to 2 gives the majority of the benefit here.
Con 1: Increases the variance of performance. The more guards you have, the closer to average performance you'll be. Whereas if you have just one guard, your performance will be impacted a lot by that choice. It would seem that we need to raise the bar on getting the Guard flag if we move people to having just one guard.
Con 2: Moving to 1 guard will rule out a Conflux-style design. But 2 guards would still work fine.
What did I miss?Tor: 0.2.6.x-final