April 2018 - tor-commits - lists.torproject.org

[tor/release-0.3.3] Merge branch 'maint-0.3.2' into maint-0.3.3
by nickm＠torproject.org 16 Apr '18

16 Apr '18

commit 9ef4c05df8323850b5894782f435da15810d6189 Merge: 22845df2a c5899d5cf Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 16 13:48:23 2018 -0400 Merge branch 'maint-0.3.2' into maint-0.3.3 src/common/address.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[tor/release-0.3.3] Merge branch 'maint-0.3.1' into maint-0.3.2
by nickm＠torproject.org 16 Apr '18

16 Apr '18

commit c5899d5cf3a761f4049c1d6f05232731edcfeb57 Merge: d3ac47b41 5e0fbd700 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 16 13:48:23 2018 -0400 Merge branch 'maint-0.3.1' into maint-0.3.2 src/common/address.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[tor/release-0.3.3] Merge branch 'maint-0.2.9' into maint-0.3.1
by nickm＠torproject.org 16 Apr '18

16 Apr '18

commit 5e0fbd7006993a4e402f2eee49f6f86074923197 Merge: db6902c23 0e13ff481 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 16 13:48:23 2018 -0400 Merge branch 'maint-0.2.9' into maint-0.3.1 src/common/address.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[snowflake/master] Link to wiki page rather than github source code.
by dcf＠torproject.org 16 Apr '18

16 Apr '18

commit a762becbaa4b3e75b1e42e782f4cd426b4e345e9 Author: David Fifield <david(a)bamsoftware.com> Date: Mon Apr 16 10:22:39 2018 -0700 Link to wiki page rather than github source code. I'm intuiting that the purpose of linking to github was to show the README, not to link to the source code per se, so I changed the link to point to the wiki page rather than gitweb.torproject.org/.... https://bugs.torproject.org/23947#comment:15 --- proxy/static/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proxy/static/index.html b/proxy/static/index.html index c78004f..8f0563d 100644 --- a/proxy/static/index.html +++ b/proxy/static/index.html @@ -25,7 +25,7 @@ textarea { <h1>Snowflake</h1> <p> -<a href="https://github.com/keroserene/snowflake" target="_blank">Snowflake</a> +<a href="https://trac.torproject.org/projects/tor/wiki/doc/Snowflake" target="_blank">Snowflake</a> is a WebRTC pluggable transport for Tor. </p>

1 0

[snowflake/master] keroserene.net/snowflake → snowflake.torproject.org
by dcf＠torproject.org 16 Apr '18

16 Apr '18

commit a9630a82343f13b101dc4fc8ac7be3b94eb69cf3 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Apr 15 16:43:08 2018 -0700 keroserene.net/snowflake → snowflake.torproject.org --- proxy/README.md | 4 ++-- proxy/static/index.html | 4 ++-- proxy/static/options.html | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/proxy/README.md b/proxy/README.md index 5f63cce..0657331 100644 --- a/proxy/README.md +++ b/proxy/README.md @@ -2,9 +2,9 @@ This is the browser proxy component of Snowflake. ### Embedding -See [keroserene.net/snowflake](https://keroserene.net/snowflake) for more info: +See https://snowflake.torproject.org/ for more info: ``` -<iframe src="https://keroserene.net/snowflake/embed.html" width="88" height="16" frameborder="0" scrolling="no"></iframe> +<iframe src="https://snowflake.torproject.org/embed.html" width="88" height="16" frameborder="0" scrolling="no"></iframe> ``` ### Building diff --git a/proxy/static/index.html b/proxy/static/index.html index 8f0563d..395410c 100644 --- a/proxy/static/index.html +++ b/proxy/static/index.html @@ -54,13 +54,13 @@ It is now possible to embed the Snowflake badge on any website: </p> <textarea readonly> -<iframe src="https://keroserene.net/snowflake/embed.html" width="88" height="16" frameborder="0" scrolling="no"></iframe> +<iframe src="https://snowflake.torproject.org/embed.html" width="88" height="16" frameborder="0" scrolling="no"></iframe> </textarea> <p> Which looks like this: </p> -<iframe src="https://keroserene.net/snowflake/embed.html" width="88" height="16" frameborder="0" scrolling="no"></iframe> +<iframe src="https://snowflake.torproject.org/embed.html" width="88" height="16" frameborder="0" scrolling="no"></iframe> <p> If it animates, then congratulations -- you are currently acting as a Tor bridge. diff --git a/proxy/static/options.html b/proxy/static/options.html index 91a8ea1..bdffd51 100644 --- a/proxy/static/options.html +++ b/proxy/static/options.html @@ -51,7 +51,7 @@ <p> For more information on this system click - <a href="https://keroserene.net/snowflake">here</a>. + <a href="https://snowflake.torproject.org/">here</a>. </p> <noscript>

1 0

[snowflake/master] Change to standalone broker.
by dcf＠torproject.org 16 Apr '18

16 Apr '18

commit 947636ae817fdb393b4fcb2901bf52bca36cef65 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Apr 15 16:59:43 2018 -0700 Change to standalone broker. https://snowflake-reg-test.appspot.com/ for the client (needs domain fronting) https://snowflake-broker.bamsoftware.com/ for the proxies (no fronting) Note that fronting to App Engine doesn't currently actually work because of https://bugs.torproject.org/25804; this commit doesn't change that. --- README.md | 2 +- client/README.md | 2 +- client/torrc | 2 +- proxy-go/snowflake.go | 2 +- proxy/README.md | 2 +- proxy/snowflake.coffee | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 6bc37e9..9b0827f 100644 --- a/README.md +++ b/README.md @@ -56,7 +56,7 @@ For example: ``` ClientTransportPlugin snowflake exec ./client \ --url https://snowflake-reg.appspot.com/ \ +-url https://snowflake-reg-test.appspot.com/ \ -front www.google.com \ -ice stun:stun.l.google.com:19302 -max 3 diff --git a/client/README.md b/client/README.md index 294d9ee..1989209 100644 --- a/client/README.md +++ b/client/README.md @@ -7,7 +7,7 @@ It is based on goptlib. The client uses these following `torrc` options by default: ``` ClientTransportPlugin snowflake exec ./client \ --url https://snowflake-reg.appspot.com/ \ +-url https://snowflake-reg-test.appspot.com/ \ -front www.google.com \ -ice stun:stun.l.google.com:19302 ``` diff --git a/client/torrc b/client/torrc index 6912760..0de2d36 100644 --- a/client/torrc +++ b/client/torrc @@ -2,7 +2,7 @@ UseBridges 1 DataDirectory datadir ClientTransportPlugin snowflake exec ./client \ --url https://snowflake-reg.appspot.com/ \ +-url https://snowflake-reg-test.appspot.com/ \ -front www.google.com \ -ice stun:stun.l.google.com:19302 \ -max 3 diff --git a/proxy-go/snowflake.go b/proxy-go/snowflake.go index 7bb435c..2e8fe20 100644 --- a/proxy-go/snowflake.go +++ b/proxy-go/snowflake.go @@ -22,7 +22,7 @@ import ( "golang.org/x/net/websocket" ) -const defaultBrokerURL = "https://snowflake-reg.appspot.com/" +const defaultBrokerURL = "https://snowflake-broker.bamsoftware.com/" const defaultRelayURL = "wss://snowflake.bamsoftware.com/" const defaultSTUNURL = "stun:stun.l.google.com:19302" const pollInterval = 5 * time.Second diff --git a/proxy/README.md b/proxy/README.md index 0657331..91edbbd 100644 --- a/proxy/README.md +++ b/proxy/README.md @@ -32,7 +32,7 @@ To run locally, either: With no parameters, snowflake uses the default relay `snowflake.bamsoftware.com:443` and uses automatic signaling with the default broker at -`https://snowflake-reg.appspot.com/`. +`https://snowflake-broker.bamsoftware.com/`. Here are optional parameters to include in the query string. ``` diff --git a/proxy/snowflake.coffee b/proxy/snowflake.coffee index 1f5674b..e0d6921 100644 --- a/proxy/snowflake.coffee +++ b/proxy/snowflake.coffee @@ -11,7 +11,7 @@ TODO: More documentation # General snowflake proxy constants. # For websocket-specific constants, see websocket.coffee. -DEFAULT_BROKER = 'snowflake-reg.appspot.com' +DEFAULT_BROKER = 'snowflake-broker.bamsoftware.com' DEFAULT_RELAY = host: 'snowflake.bamsoftware.com' port: '443'

1 0

[webwml/master] Add Parinishtha to the people page
by atagar＠torproject.org 16 Apr '18

16 Apr '18

commit fa4dad61b2ead45aed49199c3d81348462d34bde Author: Damian Johnson <atagar(a)torproject.org> Date: Mon Apr 16 10:12:47 2018 -0700 Add Parinishtha to the people page --- about/en/corepeople.wml | 58 ++++++++++++++++++++++++++------------------ images/people/orig/pari.jpg | Bin 0 -> 215061 bytes images/people/pari.png | Bin 0 -> 39097 bytes keys/pari.txt | 52 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 86 insertions(+), 24 deletions(-) diff --git a/about/en/corepeople.wml b/about/en/corepeople.wml index 7911b0e0..1f0273a1 100644 --- a/about/en/corepeople.wml +++ b/about/en/corepeople.wml @@ -579,15 +579,25 @@ </td> <td> + <a id="pari"></a> + <div class="photo"><img src="$(IMGROOT)/people/pari.png" alt="pari" /></div> + <div class="icon"><a href="https://twitter.com/ParinishthaY"><img src="$(IMGROOT)/twitter-small.png" alt="twitter" /></a></div> + <div class="icon"><a href="../keys/pari.txt"><img src="$(IMGROOT)/pgp-key.png" alt="pgp key" /></a></div> + <div class="name"><a href="#pari">Parinishtha</a></div> + <div class="field"><b>IRC:</b> pari</div> + <div class="description">Works with UX and Community teams, and on Tor India initiatives. Started as an Outreachy intern.</div> + </td> + </tr> + + <tr> + <td> <a id="syverson"></a> <div class="photo"><img src="$(IMGROOT)/people/syverson.png" alt="syverson" /></div> <div class="name"><a href="#syverson">Paul Syverson</a></div> <div class="field"><b>IRC:</b> syverson</div> <div class="description"><a href="https://www.nrl.navy.mil">NRL</a> researcher on most things Tor. Inventor of <a href="https://www.onion-router.net/">onion routing</a>, and one of the three original designers of Tor.</div> </td> - </tr> - <tr> <td> <a id="pepijn"></a> <div class="photo"><img src="$(IMGROOT)/people/pepijn.png" alt="pepijn" /></div> @@ -596,16 +606,16 @@ <div class="name"><a href="#pepijn">Pepijn Le Heux</a></div> <div class="description">Lawyer based in The Netherlands and co-founder of Hart voor Internetvrijheid.</div> </td> + </tr> + <tr> <td> <a id="peter"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> <div class="name"><a href="#peter">Peter Palfrader</a></div> <div class="description">Manages the Debian packages, runs one of the directory authorities, and generally helps out a lot.</div> </td> - </tr> - <tr> <td> <a id="phw"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> @@ -615,7 +625,9 @@ <div class="field"><b>IRC:</b> phw</div> <div class="description">Maintains <a href="https://gitweb.torproject.org/user/phw/exitmap.git/">exitmap</a> and <a href="https://gitweb.torproject.org/user/phw/sybilhunter.git/">sybilhunter</a>, works on <a href="https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays">bad relay detection</a>, and does <a href="https://nymity.ch/papers.html">security and privacy research</a>.</div> </td> + </tr> + <tr> <td> <a id="robt"></a> <div class="photo"><img src="$(IMGROOT)/people/robt.png" alt="robt" /></div> @@ -623,9 +635,7 @@ <div class="name"><a href="#robt">Rabbi Rob Thomas</a></div> <div class="description">CEO of Team Cymru, which supports Tor through hosting, research, and infosec assistance.</div> </td> - </tr> - <tr> <td> <a id="ramy"></a> <div class="photo"><img src="$(IMGROOT)/people/ramy.png" alt="ramy" /></div> @@ -634,7 +644,9 @@ <div class="name"><a href="#ramy">Ramy Raoof</a></div> <div class="description">Tor Board member, technologist, and privacy and security researcher.</div> </td> + </tr> + <tr> <td> <a id="pospeselr"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> @@ -644,9 +656,7 @@ <div class="field"><b>IRC:</b> pospeselr</div> <div class="description">Tor Browser developer.</div> </td> - </tr> - <tr> <td> <a id="robgjansen"></a> <div class="photo"><img src="$(IMGROOT)/people/robgjansen.png" alt="robgjansen" /></div> @@ -656,7 +666,9 @@ <div class="field"><b>IRC:</b> robgjansen</div> <div class="description"><a href="https://www.nrl.navy.mil">NRL</a> research scientist, <a href="http://www.robgjansen.com/">leading expert in Tor network performance</a>, and author of <a href="https://shadow.github.io/">Shadow</a>.</div> </td> + </tr> + <tr> <td> <a id="arma"></a> <div class="photo"><img src="$(IMGROOT)/people/arma.png" alt="arma" /></div> @@ -666,9 +678,7 @@ <div class="field"><b>IRC:</b> arma</div> <div class="description">Original developer of Tor along with Nick and Paul. Leading privacy researcher, coordinating developers and researchers.</div> </td> - </tr> - <tr> <td> <a id="sajolida"></a> <div class="photo"><img src="$(IMGROOT)/people/sajolida.png" alt="sajolida" /></div> @@ -676,7 +686,9 @@ <div class="name"><a href="#sajolida">sajolida</a></div> <div class="description">Technical writing, UX, and fundraising for Tails.</div> </td> + </tr> + <tr> <td> <a id="sebastian"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> @@ -684,9 +696,7 @@ <div class="name"><a href="#sebastian">Sebastian Hahn</a></div> <div class="description">Helps people around the world use and understand Tor better. Generally helps everything run smoothly. Runs one of the directory authorities.</div> </td> - </tr> - <tr> <td> <a id="serene"></a> <div class="photo"><img src="$(IMGROOT)/people/serene.png" alt="serene" /></div> @@ -695,7 +705,9 @@ <div class="name"><a href="#serene">Serene</a></div> <div class="description">Snowflake and Pluggable Transports developer.</div> </td> + </tr> + <tr> <td> <a id="ssteele"></a> <div class="photo"><img src="$(IMGROOT)/people/ssteele.png" alt="ssteele" /></div> @@ -705,9 +717,7 @@ <div class="field"><b>IRC:</b> ssteele</div> <div class="description">Executive Director of the Tor Project, Inc.</div> </td> - </tr> - <tr> <td> <a id="hiro"></a> <div class="photo"><img src="$(IMGROOT)/people/hiro.png" alt="hiro" /></div> @@ -717,7 +727,9 @@ <div class="field"><b>IRC:</b> hiro</div> <div class="description">Hiro builds and runs Tor Project's web applications and services.</div> </td> + </tr> + <tr> <td> <a id="inf0"></a> <div class="photo"><img src="$(IMGROOT)/people/inf0.png" alt="inf0" /></div> @@ -727,9 +739,7 @@ <div class="field"><b>IRC:</b> inf0</div> <div class="description">Directory authority operator, outreach and trains human rights activists. System's Engineer at Team Cymru and co-Founder of accessnow.org.</div> </td> - </tr> - <tr> <td> <a id="stephw"></a> <div class="photo"><img src="$(IMGROOT)/people/stephw.png" alt="stephw" /></div> @@ -739,7 +749,9 @@ <div class="field"><b>IRC:</b> stephw</div> <div class="description">Directs communications.</div> </td> + </tr> + <tr> <td> <a id="sjmurdoch"></a> <div class="photo"><img src="$(IMGROOT)/people/sjmurdoch.png" alt="sjmurdoch" /></div> @@ -749,9 +761,7 @@ <div class="field"><b>IRC:</b> sjmurdoch</div> <div class="description"><a href="http://www.cs.ucl.ac.uk/staff/s.murdoch/">Principal Research Fellow</a> at University College London and original creator of the <a href="https://www.torproject.org/projects/torbrowser.html.en">Tor Browser</a>.</div> </td> - </tr> - <tr> <td> <a id="sukhe"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> @@ -760,7 +770,9 @@ <div class="field"><b>IRC:</b> sukhe</div> <div class="description"><a href="https://trac.torproject.org/projects/tor/wiki/torbirdy">TorBirdy</a> and <a href="https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger">Tor Messenger</a> developer. Member of the <a href="https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam">Community Team</a>.</div> </td> + </tr> + <tr> <td> <a id="catalyst"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> @@ -770,9 +782,7 @@ <div class="field"><b>IRC:</b> catalyst</div> <div class="description">Software archaeologist and keeper of C language arcana. Works with applied cryptography, protocol design, software security, and technical debt restructuring.</div> </td> - </tr> - <tr> <td> <a id="teor"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> @@ -781,7 +791,9 @@ <div class="field"><b>IRC:</b> teor</div> <div class="description">Onion services developer, and core member of Tor dev team. Researches Tor network measurement and onion service scalability.</div> </td> + </tr> + <tr> <td> <a id="tjr"></a> <div class="photo"><img src="$(IMGROOT)/people/tjr.png" alt="tjr" /></div> @@ -791,9 +803,7 @@ <div class="field"><b>IRC:</b> tjr</div> <div class="description">Maintains <a href="https://consensus-health.torproject.org/">Consensus Health </a>, runs one of the bandwidth authorities, and contributes to Tor Browser.</div> </td> - </tr> - <tr> <td> <a id="t0mmy"></a> <div class="photo"><img src="$(IMGROOT)/people/t0mmy.png" alt="t0mmy" /></div> @@ -803,7 +813,9 @@ <div class="field"><b>IRC:</b> t0mmy</div> <div class="description">Writes and edits grant proposals, one-pagers, blogposts, etc.</div> </td> + </tr> + <tr> <td> <a id="wseltzer"></a> <div class="photo"><img src="$(IMGROOT)/people/wseltzer.png" alt="wseltzer" /></div> @@ -813,9 +825,7 @@ <div class="field"><b>IRC:</b> wseltzer</div> <div class="description"><a href="https://wendy.seltzer.org/">Techie lawyer</a> and former Tor board member. She works on legal and policy support for private and secure communications.</div> </td> - </tr> - <tr> <td> <a id="yawning"></a> <div class="photo"><img src="$(IMGROOT)/people/no_photo.png" alt="no photo" /></div> diff --git a/images/people/orig/pari.jpg b/images/people/orig/pari.jpg new file mode 100644 index 00000000..74391228 Binary files /dev/null and b/images/people/orig/pari.jpg differ diff --git a/images/people/pari.png b/images/people/pari.png new file mode 100644 index 00000000..491fa7a5 Binary files /dev/null and b/images/people/pari.png differ diff --git a/keys/pari.txt b/keys/pari.txt new file mode 100644 index 00000000..69de06b0 --- /dev/null +++ b/keys/pari.txt @@ -0,0 +1,52 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- + +mQINBFoV3twBEADW000PgO8Bf7MTqzjvYRBMKYsPehkr3cT25kW0NdBZZH/6FTD4 +COo6C0cP9+Hl+ebIYfwb1yxZOyHAL5Z5uf9aTJmq+MQ7zV/UK+T/zDkqr+ywkHn3 +q2AktIhWUIhETalXsCGSBRFJUjHuwZW84F62viOb7DjjXmxbbaFjbkDwH60dM3pV +XlwReJ0WV49ohX84Un5qaBQvtX7QsCvVMzH27bfOTqu6TwPlHEy6Cma/4WO1jemh +j2FE1j/Oej7DFy9PpWDZe8Mex9+yRv8i7ey0jIW3jKVECXzod4oqqzzQX/3+qPvx +EZeKEAVg+a6xYztDQBjTa+XJXbpNCV4bY/7zuBcXLusc5rRFJueDipdgc3yEl3yz +pVTaLQVPYs9XT6i2ho8Lxt/7HMAK7MInJuSp5jutaFWPDy+mWe5gE0U+UWVXZ2jf +VhghCqlvbNmPjk9ObjCHtHfiJMvyK4u7vNy+zyULTJPe3UNxy6XxL6qwf9j4xEXR +ItVeLYdeaQekmawWDX9x8lIidiKGETjMRyFsQTgMidT91kxF+K0fuVHFdT3G3+eq +OWrSmrIDmF2Hw38NbKdFxwRsonFbPUXRlNQHb2BuZ2uwWeLL3oKTcqdn1q0cLwD9 +i+N5Y4Fp2ol3ftyF1Y5rkWYUy7i5GBOyfhwLBDWwDY10UFm76rj/r3/vSwARAQAB +tCtQYXJpbmlzaHRoYSBZYWRhdiA8cGFyaW5pc2h0aGEwN0BnbWFpbC5jb20+iQJU +BBMBCAA+FiEE6xYpwTAICeZWYWOTw8+gcbLu05QFAloV3twCGyMFCQlmAYAFCwkI +BwIGFQgJCgsCBBYCAwECHgECF4AACgkQw8+gcbLu05SSxxAAzLyNU46ywz5MBqu5 +Uo2NtO370AcLuUqBnhtVUri4/YKz83vvSAH/tH41yiHL47dLzVIbScVuwmMtKbYR +MaoozYiDXebId1sAAcTxZTUsxvtjV77TsNTFOK7j+7x68NCUug1QpZVtRFIEsQxK +ByqpRBOe5BqvrWKY+XOnuAme5a5ZxUe0Izf9DbG1ddyNU3FsStACqrUv8taAccNZ +lWkQsliPLv8ADW+FdlHVvXqXldsJnUsk0OTLISjCof+hRDxbVbFBmPXAtglz5bKj +aEEJrwNfvDQZC36DqCch5uQ5Uq/gSPuKI6tNScIU0MBRn3OggxtkjV7EhRgKBAuO +DlSitAYxIKMKjBaqZqpYaV5DKTBJmuWK+esfh+1rRKlSHw/sjcaoQSqeBY0bR+Mh +zsti4grtcYfKAOsv9nA3ar4G8LZM2uSuzYvdF+QWPEwBEEHKSK2RK7Hpdu867aYf +D+y4BEkLmtFmk9x33lChebtZKYvOuFzh8goDlDSH+0dCdGkKnBbBampQ+JC18356 +XFC9Qmen7dqnqyAf6i/S3kSj5Yv46DsbOceycZe0/wYN6dq6JrRLY/qrZDQ8dJC7 +0VTqkGMeZMlTszw6GV+544jkqcI1tO1j6l4iiyRMakkUPuJCkhJrCxOie0gfd2OU +PUMoF0Vj24zQAtpkdVe5WI3YhR+5Ag0EWhXe3AEQAMDhRgGVBhZhdRppO2mQEksZ +vg2bS/1v+BbLBfG0xoilhN7CP4vo83yKV92FfCE2CZmUt/m//2SABE8hlYnN48Tj +HqD7/3WbaJF3XwGmBJ9vOoTrk1+lELYAtdaT4mHipynyxBZxigPEEUk54reea/Rc +ZT46B40nodyKfGUGKtRIhjZ0wqIk9Pji5kZifpGOFQI2hQFdCBlILdAmf9qaAHJa +AZ9PcWRgQU8P8l0F97pCK3X7oi3NtpRJiFSkAEI5fgG6W/mZsaHMsNy9LabWlXps +FCwXMWX4xVh0ZWEVjWdQ+xbRJHH1SjTrjHaZZlnVYFQat+irbr2lNk0/O+mU7cdF +P1us0fiNT5l8DHlo8kGjyj0QdGwLkx3GbDSoWBcXkjWlzwLOeqB+6wXEjEw13H1y +vw52uP6rAcgOfYq0gjPIhcwV0ELpFpGYt2YYl+OTXkICGSN2FyvEiegWezGvYhND +uZxR+TZLMZBr1hH92znARC16iioEMJWTpkVmNDLk7ab+kCqdZvkxdh0yOQfvOF// +63XVe1mgA2h0IlsuHSio0B4jAI4w11GEyBVgiNXhDmcfmmpRLLrgDL0lQ0m3b9GY +vXZDj6qH2pYqdcSpGggEvX4h+Y5SGeOuA0amGJ5PwJHp7WAxzLxZQKDIMbxtwtPo +NZLYrYDx39td/r8XUhRLABEBAAGJAjwEGAEIACYWIQTrFinBMAgJ5lZhY5PDz6Bx +su7TlAUCWhXe3AIbDAUJCWYBgAAKCRDDz6Bxsu7TlIS+D/sFrV684yLn21495l2U +JA/FRcq63IsjqudUkj5nTvfYQa1RiHdvRDJN+jGR2gZplCHvauagRhRPoB4QrMY9 +3qpM+OHX3FsUIpA0JwkGWyheI5+6x1iYA1bS5xWFAjKYYb9+L7oweN9oNHeEnBd1 +k/sstZ/H2QV9vhcykA8Xx9j3b9OHR8XB7DIG2GJFOrC2Mkz+N/i9G/fmUPofPCA0 +19ohOpPVOkkkjsx0wAzsq5KBd+O6UYMV8PGNKmxFBwbI1n+tmB9KZ9KvUS59AMgs +GoCLFS2Rod+VRkuMpBL85NzP7QMgCc24unoLGMHR2TzK/eSiJ/lf7YrR90Vp1Nl5 +lTXe/4KxV0LPJ6nkDmPqE9oIaYq0Zj3lKpOpirQ1nJj/DzNhKj4TjyZ2PZZjwUns +exG8wv0BgwmNgT3vpua8Z7iZtpEshk52AfzBGfUGxfnlBdlG+z9lTCHS+0/uSDpU +R7L6D21/fqL1APEuku67gZHPCWgI4BNoLiGZQVLi314etFPsX9rhIo9oyiTqEbSC +vT063kVxfoEjemXRcGk7YAzGuU1QRnMIHkl2LnY1jaBjzKza3S6KaR5JkEGSIIhd +69lO+42mSpH/X5QzvgLkNDQgWpkLew8TegZzN2k/hA9Fwr79CBNXsi3+1SLl9QQ3 +9i55tJFkxf3pZ2gdcxair+btHA== +=WzJz +-----END PGP PUBLIC KEY BLOCK-----

1 0

[stem/master] Add circ_max_cell_queue_size consensus parameter
by atagar＠torproject.org 16 Apr '18

16 Apr '18

commit 82b22046f40f49579ff37c4247db50050334998a Author: Damian Johnson <atagar(a)torproject.org> Date: Mon Apr 16 09:35:17 2018 -0700 Add circ_max_cell_queue_size consensus parameter Noting a new parameter... https://gitweb.torproject.org/torspec.git/commit/?id=7a25d14 --- stem/descriptor/networkstatus.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/stem/descriptor/networkstatus.py b/stem/descriptor/networkstatus.py index 2c1817cb..1be802f5 100644 --- a/stem/descriptor/networkstatus.py +++ b/stem/descriptor/networkstatus.py @@ -170,6 +170,7 @@ DEFAULT_PARAMS = { 'onion-key-rotation-days': 28, 'onion-key-grace-period-days': 7, 'hs_service_max_rdv_failures': 2, + 'circ_max_cell_queue_size': 50000, } # KeyCertificate fields, tuple is of the form... @@ -224,6 +225,7 @@ PARAM_RANGE = { 'onion-key-rotation-days': (1, 90), 'onion-key-grace-period-days': (1, 90), # max is the highest onion-key-rotation-days 'hs_service_max_rdv_failures': (1, 10), + 'circ_max_cell_queue_size': (1000, 4294967295), }

1 0

[translation/tor-messenger-fingerdtd] Update translations for tor-messenger-fingerdtd
by translation＠torproject.org 16 Apr '18

16 Apr '18

commit 2f5fad7478094b5391d5fc19f67dbede7baab1b7 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Apr 16 15:49:19 2018 +0000 Update translations for tor-messenger-fingerdtd --- hi/finger.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hi/finger.dtd b/hi/finger.dtd index 94e477a15..3bcffd22c 100644 --- a/hi/finger.dtd +++ b/hi/finger.dtd @@ -11,5 +11,5 @@ <!ENTITY addFingerDialog.title "Add Fingerprint"> <!ENTITY addFingerDialog.finger "Fingerprint"> <!ENTITY addFingerDialog.accept "ठीक"> -<!ENTITY addFingerDialog.cancel "Skip"> +<!ENTITY addFingerDialog.cancel "छोड़ें"> <!ENTITY addFingerDialog.tooltip "If you know the 40 hex char fingerprint of your contact's OTR private key, enter it now."> \ No newline at end of file

1 0

[torspec/master] prop291: dos2unix the file so we get a Unix format
by dgoulet＠torproject.org 16 Apr '18

16 Apr '18

commit 5e2e04eb9791bb9f92384bcd541de3c1f26dbca8 Author: David Goulet <dgoulet(a)torproject.org> Date: Mon Apr 16 11:12:06 2018 -0400 prop291: dos2unix the file so we get a Unix format No change, just removes the annoying ^M at the end of each line. Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- proposals/291-two-guard-nodes.txt | 502 +++++++++++++++++++------------------- 1 file changed, 251 insertions(+), 251 deletions(-) diff --git a/proposals/291-two-guard-nodes.txt b/proposals/291-two-guard-nodes.txt index a900ee9..dc0aa74 100644 --- a/proposals/291-two-guard-nodes.txt +++ b/proposals/291-two-guard-nodes.txt @@ -1,251 +1,251 @@ -Filename: 291-two-guard-nodes.txt -Title: The move to two guard nodes -Author: Mike Perry -Created: 2018-03-22 -Supersedes: Proposal 236 -Status: Open - -0. Background - - Back in 2014, Tor moved from three guard nodes to one guard node[1,2,3]. - - We made this change primarily to limit points of observability of entry - into the Tor network for clients and onion services, as well as to - reduce the ability of an adversary to track clients as they move from - one internet connection to another by their choice of guards. - - -1. Proposed changes - -1.1. Switch to two guards per client - - When this proposal becomes effective, clients will switch to using - two guard nodes. The guard node selection algorithms of Proposal 271 - will remain unchanged. Instead of having one primary guard "in use", - Tor clients will always use two. - - This will be accomplished by setting the guard-n-primary-guards-to-use - consensus parameter to 2, as well as guard-n-primary-guards to 2. - (Section 3.1 covers the reason for both parameters). This is equivalent - to using the torrc option NumEntryGuards=3D2, which can be used for - testing behavior prior to the consensus update. - -1.2. Enforce Tor's path restrictions across this guard layer - - In order to ensure that Tor can always build circuits using two guards - without resorting to a third, they must be chosen such that Tor's path - restrictions could still build a path with at least one of them, - regardless of the other nodes in the path. - - In other words, we must ensure that both guards are not chosen from the - same /16 or the same node family. In this way, Tor will always be able to - build a path using these guards, preventing the use of a third guard. - - -2. Discussion - -2.1. Why two guards? - - The main argument for switching to two guards is that because of Tor's - path restrictions, we're already using two guards, but we're using them - in a suboptimal and potentially dangerous way. - - Tor's path restrictions enforce the condition that the same node cannot - appear twice in the same circuit, nor can nodes from the same /16 subnet - or node family be used in the same circuit. - - Tor's paths are also built such that the exit node is chosen first and - held fixed during guard node choice, as are the IP, HSDIR, and RPs for - onion services. This means that whenever one of these nodes happens to - be the guard[4], or be in the same /16 or node family as the guard, Tor - will build that circuit using a second "primary" guard, as per proposal - 271[7]. - - Worse still, the choice of RP, IP, and exit can all be controlled by an - adversary (to varying degrees), enabling them to force the use of a - second guard at will. - - Because this happens somewhat infrequently in normal operation, a fresh - TLS connection will typically be created to the second "primary" guard, - and that TLS connection will be used only for the circuit for that - particular request. This property makes all sorts of traffic analysis - attacks easier, because this TLS connection will not benefit from any - multiplexing. - - This is more serious than traffic injection via an already in-use - guard because the lack of multiplexing means that the data retention - level required to gain information from this activity is very low, and - may exist for other reasons. To gain information from this behavior, an - adversary needs only connection 5-tuples + timestamps, as opposed to - detailed timeseries data that is polluted by other concurrent activity - and padding. - - In the most severe form of this attack, the adversary can take a suspect - list of Tor client IP addresses (or the list of all Guard node IP addresses) - and observe when secondary Tor connections are made to them at the time when - they cycle through all guards as RPs for connections to an onion - service. This adversary does not require collusion on the part of observers - beyond the ability to provide 5-tuple connection logs (which ISPs may retain - for reasons such as netflow accounting, IDS, or DoS protection systems). - - A fully passive adversary can also make use of this behavior. Clients - unlucky enough to pick guard nodes in heavily used /16s or in large node - families will tend to make use of a second guard more frequently even - without effort from the adversary. In these cases, the lack of - multiplexing also means that observers along the path to this secondary - guard gain more information per observation. - -2.2. Why not MOAR guards? - - We do not want to increase the number of observation points for client - activity into the Tor network[1]. We merely want better multiplexing for - the cases where this already happens. - -2.3. Can you put some numbers on that? - - The Changing of the Guards[13] paper studies this from a few different - angles, but one of the crucially missing graphs is how long a client - can expect to run with N guards before it chooses a malicious guard. - - However, we do have tables in section 3.2.1 of proposal 247 that cover - this[14]. There are three tables there: one for a 1% adversary, one for - a 5% adversary, and one for a 10% adversary. You can see the probability - of adversary success for one and two guards in terms of the number of - rotations needed before the adversary's node is chosen. Not surprisingly, - the two guard adversary gets to compromise clients roughly twice as - quickly, but the timescales are still rather large even for the 10% - adversary: they only have 50% chance of success after 4 rotations, which - will take about 14 months with Tor's 3.5 month guard rotation. - -2.4. What about guard fingerprinting? - - More guards also means more fingerprinting[8]. However, even one guard - may be enough to fingerprint a user who moves around in the same area, - if that guard is low bandwidth or there are not many Tor users in that - area. - - Furthermore, our use of separate directory guards (and three of them) - means that we're not really changing the situation much with the - addition of another regular guard. Right now, directory guard use alone - is enough to track all Tor users across the entire world. - - While the directory guard problem could be fixed[12] (and should be - fixed), it is still the case that another mechanism should be used for - the general problem of guard-vs-location management[9]. - - -3. Alternatives - - There are two other solutions that also avoid the use of secondary guard - in the path restriction case. - -3.1. Eliminate path restrictions entirely - - If Tor decided to stop enforcing /16, node family, and also allowed the - guard node to be chosen twice in the path, then under normal conditions, - it should retain the use of its primary guard. - - This approach is not as extreme as it seems on face. In fact, it is hard - to come up with arguments against removing these restrictions. Tor's - /16 restriction is of questionable utility against monitoring, and it can - be argued that since only good actors use node family, it gives influence - over path selection to bad actors in ways that are worse than the benefit - it provides to paths through good actors[10,11]. - - However, while removing path restrictions will solve the immediate - problem, it will not address other instances where Tor temporarily opts - use a second guard due to congestion, OOM, or failure of its primary - guard, and we're still running into bugs where this can be adversarially - controlled or just happen randomly[5]. - - While using two guards means twice the surface area for these types of - bugs, it also means that instances where they happen simultaneously on - both guards (thus forcing a third guard) are much less likely than with - just one guard. (In the passive adversary model, consider that one guard - fails at any point with probability P1. If we assume that such passive - failures are independent events, both guards would fail concurrently - with probability P1*P2. Even if the events are correlated, the maximum - chance of concurrent failure is still MIN(P1,P2)). - - Note that for this analysis to hold, we have to ensure that nodes that - are at RESOURCELIMIT or otherwise temporarily unresponsive do not cause - us to consider other primary guards beyond than the two we have chosen. - This is accomplished by setting guard-n-primary-guards to 2 (in addition - to setting guard-n-primary-guards-to-use to 2). With this parameter - set, the proposal 271 algorithm will avoid considering more than our two - guards, unless *both* are down at once. - -3.2. No Guard-flagged nodes as exit, RP, IP, or HSDIRs - - Similar to 3.1, we could instead forbid the use of Guard-flagged nodes - for the exit, IP, RP, and HSDIR positions. - - This solution has two problems: First, like 3.1, it also does not handle - the case where resource exhaustion could force the use of a second - guard. Second, it requires clients to upgrade to the new behavior and - stop using Guard flagged nodes before it can be deployed. - - -4. The future is confluxed - - An additional benefit of using a second guard is that it enables us to - eventually use conflux[6]. - - Conflux works by giving circuits a 256bit cookie that is sent to the - exit/RP, and circuits that are then built to the same exit/RP with the - same cookie can then be fused together. Throughput estimates are used to - balance traffic between these circuits, depending on their performance. - - We have unfortunately signaled to the research community that conflux is - not worth pursuing, because of our insistence on a single guard. While - not relevant to this proposal (indeed, conflux requires its own proposal - and also concurrent research), it is worth noting that whichever way we - go here, the door remains open to conflux because of its utility against - similar issues. - - If our conflux implementation includes packet acking, then circuits can - still survive the loss of one guard node due to DoS, OOM, or other - failures because the second half of the path will remain open and - usable (see the probability of concurrent failure arguments in Section - 3.1). - - If exits remember this cookie for a short period of time after the last - circuit is closed, the technique can be used to protect against - DoS/OOM/guard downtime conditions that take down both guard nodes or - destroy many circuits to confirm both guard node choices. In these - cases, circuits could be rebuilt along an alternate path and resumed - without end-to-end circuit connectivity loss. This same technique will - also make things like ephemeral bridges (ie Snowflake/Flashproxy) more - usable, because bridge uptime will no longer be so crucial to usability. - It will also improve mobile usability by allowing us to resume - connections after mobile Tor apps are briefly suspended, or if the user - switches between cell and wifi networks. - - Furthermore, it is likely that conflux will also be useful against traffic - analysis and congestion attacks. Since the load balancing is dynamic and - hard to predict by an external observer and also increases overall - traffic multiplexing, traffic correlation and website traffic - fingerprinting attacks will become harder, because the adversary can no - longer be sure what percentage of the traffic they have seen (depending - on their position and other potential concurrent activity). Similarly, - it should also help dampen congestion attacks, since traffic will - automatically shift away from a congested guard. - - - -References: - -1. https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramet… -2. https://trac.torproject.org/projects/tor/ticket/12206 -3. https://gitweb.torproject.org/torspec.git/tree/proposals/236-single-guard-n… -4. https://trac.torproject.org/projects/tor/ticket/14917 -5. https://trac.torproject.org/projects/tor/ticket/25347#comment:14 -6. https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf -7. https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-… -8. https://trac.torproject.org/projects/tor/ticket/9273#comment:3 -9. https://tails.boum.org/blueprint/persistent_Tor_state/ -10. https://trac.torproject.org/projects/tor/ticket/6676#comment:3 -11. https://bugs.torproject.org/15060 -12. https://trac.torproject.org/projects/tor/ticket/10969 -13. https://www.freehaven.net/anonbib/cache/wpes12-cogs.pdf -14. https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-disco… +Filename: 291-two-guard-nodes.txt +Title: The move to two guard nodes +Author: Mike Perry +Created: 2018-03-22 +Supersedes: Proposal 236 +Status: Open + +0. Background + + Back in 2014, Tor moved from three guard nodes to one guard node[1,2,3]. + + We made this change primarily to limit points of observability of entry + into the Tor network for clients and onion services, as well as to + reduce the ability of an adversary to track clients as they move from + one internet connection to another by their choice of guards. + + +1. Proposed changes + +1.1. Switch to two guards per client + + When this proposal becomes effective, clients will switch to using + two guard nodes. The guard node selection algorithms of Proposal 271 + will remain unchanged. Instead of having one primary guard "in use", + Tor clients will always use two. + + This will be accomplished by setting the guard-n-primary-guards-to-use + consensus parameter to 2, as well as guard-n-primary-guards to 2. + (Section 3.1 covers the reason for both parameters). This is equivalent + to using the torrc option NumEntryGuards=3D2, which can be used for + testing behavior prior to the consensus update. + +1.2. Enforce Tor's path restrictions across this guard layer + + In order to ensure that Tor can always build circuits using two guards + without resorting to a third, they must be chosen such that Tor's path + restrictions could still build a path with at least one of them, + regardless of the other nodes in the path. + + In other words, we must ensure that both guards are not chosen from the + same /16 or the same node family. In this way, Tor will always be able to + build a path using these guards, preventing the use of a third guard. + + +2. Discussion + +2.1. Why two guards? + + The main argument for switching to two guards is that because of Tor's + path restrictions, we're already using two guards, but we're using them + in a suboptimal and potentially dangerous way. + + Tor's path restrictions enforce the condition that the same node cannot + appear twice in the same circuit, nor can nodes from the same /16 subnet + or node family be used in the same circuit. + + Tor's paths are also built such that the exit node is chosen first and + held fixed during guard node choice, as are the IP, HSDIR, and RPs for + onion services. This means that whenever one of these nodes happens to + be the guard[4], or be in the same /16 or node family as the guard, Tor + will build that circuit using a second "primary" guard, as per proposal + 271[7]. + + Worse still, the choice of RP, IP, and exit can all be controlled by an + adversary (to varying degrees), enabling them to force the use of a + second guard at will. + + Because this happens somewhat infrequently in normal operation, a fresh + TLS connection will typically be created to the second "primary" guard, + and that TLS connection will be used only for the circuit for that + particular request. This property makes all sorts of traffic analysis + attacks easier, because this TLS connection will not benefit from any + multiplexing. + + This is more serious than traffic injection via an already in-use + guard because the lack of multiplexing means that the data retention + level required to gain information from this activity is very low, and + may exist for other reasons. To gain information from this behavior, an + adversary needs only connection 5-tuples + timestamps, as opposed to + detailed timeseries data that is polluted by other concurrent activity + and padding. + + In the most severe form of this attack, the adversary can take a suspect + list of Tor client IP addresses (or the list of all Guard node IP addresses) + and observe when secondary Tor connections are made to them at the time when + they cycle through all guards as RPs for connections to an onion + service. This adversary does not require collusion on the part of observers + beyond the ability to provide 5-tuple connection logs (which ISPs may retain + for reasons such as netflow accounting, IDS, or DoS protection systems). + + A fully passive adversary can also make use of this behavior. Clients + unlucky enough to pick guard nodes in heavily used /16s or in large node + families will tend to make use of a second guard more frequently even + without effort from the adversary. In these cases, the lack of + multiplexing also means that observers along the path to this secondary + guard gain more information per observation. + +2.2. Why not MOAR guards? + + We do not want to increase the number of observation points for client + activity into the Tor network[1]. We merely want better multiplexing for + the cases where this already happens. + +2.3. Can you put some numbers on that? + + The Changing of the Guards[13] paper studies this from a few different + angles, but one of the crucially missing graphs is how long a client + can expect to run with N guards before it chooses a malicious guard. + + However, we do have tables in section 3.2.1 of proposal 247 that cover + this[14]. There are three tables there: one for a 1% adversary, one for + a 5% adversary, and one for a 10% adversary. You can see the probability + of adversary success for one and two guards in terms of the number of + rotations needed before the adversary's node is chosen. Not surprisingly, + the two guard adversary gets to compromise clients roughly twice as + quickly, but the timescales are still rather large even for the 10% + adversary: they only have 50% chance of success after 4 rotations, which + will take about 14 months with Tor's 3.5 month guard rotation. + +2.4. What about guard fingerprinting? + + More guards also means more fingerprinting[8]. However, even one guard + may be enough to fingerprint a user who moves around in the same area, + if that guard is low bandwidth or there are not many Tor users in that + area. + + Furthermore, our use of separate directory guards (and three of them) + means that we're not really changing the situation much with the + addition of another regular guard. Right now, directory guard use alone + is enough to track all Tor users across the entire world. + + While the directory guard problem could be fixed[12] (and should be + fixed), it is still the case that another mechanism should be used for + the general problem of guard-vs-location management[9]. + + +3. Alternatives + + There are two other solutions that also avoid the use of secondary guard + in the path restriction case. + +3.1. Eliminate path restrictions entirely + + If Tor decided to stop enforcing /16, node family, and also allowed the + guard node to be chosen twice in the path, then under normal conditions, + it should retain the use of its primary guard. + + This approach is not as extreme as it seems on face. In fact, it is hard + to come up with arguments against removing these restrictions. Tor's + /16 restriction is of questionable utility against monitoring, and it can + be argued that since only good actors use node family, it gives influence + over path selection to bad actors in ways that are worse than the benefit + it provides to paths through good actors[10,11]. + + However, while removing path restrictions will solve the immediate + problem, it will not address other instances where Tor temporarily opts + use a second guard due to congestion, OOM, or failure of its primary + guard, and we're still running into bugs where this can be adversarially + controlled or just happen randomly[5]. + + While using two guards means twice the surface area for these types of + bugs, it also means that instances where they happen simultaneously on + both guards (thus forcing a third guard) are much less likely than with + just one guard. (In the passive adversary model, consider that one guard + fails at any point with probability P1. If we assume that such passive + failures are independent events, both guards would fail concurrently + with probability P1*P2. Even if the events are correlated, the maximum + chance of concurrent failure is still MIN(P1,P2)). + + Note that for this analysis to hold, we have to ensure that nodes that + are at RESOURCELIMIT or otherwise temporarily unresponsive do not cause + us to consider other primary guards beyond than the two we have chosen. + This is accomplished by setting guard-n-primary-guards to 2 (in addition + to setting guard-n-primary-guards-to-use to 2). With this parameter + set, the proposal 271 algorithm will avoid considering more than our two + guards, unless *both* are down at once. + +3.2. No Guard-flagged nodes as exit, RP, IP, or HSDIRs + + Similar to 3.1, we could instead forbid the use of Guard-flagged nodes + for the exit, IP, RP, and HSDIR positions. + + This solution has two problems: First, like 3.1, it also does not handle + the case where resource exhaustion could force the use of a second + guard. Second, it requires clients to upgrade to the new behavior and + stop using Guard flagged nodes before it can be deployed. + + +4. The future is confluxed + + An additional benefit of using a second guard is that it enables us to + eventually use conflux[6]. + + Conflux works by giving circuits a 256bit cookie that is sent to the + exit/RP, and circuits that are then built to the same exit/RP with the + same cookie can then be fused together. Throughput estimates are used to + balance traffic between these circuits, depending on their performance. + + We have unfortunately signaled to the research community that conflux is + not worth pursuing, because of our insistence on a single guard. While + not relevant to this proposal (indeed, conflux requires its own proposal + and also concurrent research), it is worth noting that whichever way we + go here, the door remains open to conflux because of its utility against + similar issues. + + If our conflux implementation includes packet acking, then circuits can + still survive the loss of one guard node due to DoS, OOM, or other + failures because the second half of the path will remain open and + usable (see the probability of concurrent failure arguments in Section + 3.1). + + If exits remember this cookie for a short period of time after the last + circuit is closed, the technique can be used to protect against + DoS/OOM/guard downtime conditions that take down both guard nodes or + destroy many circuits to confirm both guard node choices. In these + cases, circuits could be rebuilt along an alternate path and resumed + without end-to-end circuit connectivity loss. This same technique will + also make things like ephemeral bridges (ie Snowflake/Flashproxy) more + usable, because bridge uptime will no longer be so crucial to usability. + It will also improve mobile usability by allowing us to resume + connections after mobile Tor apps are briefly suspended, or if the user + switches between cell and wifi networks. + + Furthermore, it is likely that conflux will also be useful against traffic + analysis and congestion attacks. Since the load balancing is dynamic and + hard to predict by an external observer and also increases overall + traffic multiplexing, traffic correlation and website traffic + fingerprinting attacks will become harder, because the adversary can no + longer be sure what percentage of the traffic they have seen (depending + on their position and other potential concurrent activity). Similarly, + it should also help dampen congestion attacks, since traffic will + automatically shift away from a congested guard. + + + +References: + +1. https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramet… +2. https://trac.torproject.org/projects/tor/ticket/12206 +3. https://gitweb.torproject.org/torspec.git/tree/proposals/236-single-guard-n… +4. https://trac.torproject.org/projects/tor/ticket/14917 +5. https://trac.torproject.org/projects/tor/ticket/25347#comment:14 +6. https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf +7. https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-… +8. https://trac.torproject.org/projects/tor/ticket/9273#comment:3 +9. https://tails.boum.org/blueprint/persistent_Tor_state/ +10. https://trac.torproject.org/projects/tor/ticket/6676#comment:3 +11. https://bugs.torproject.org/15060 +12. https://trac.torproject.org/projects/tor/ticket/10969 +13. https://www.freehaven.net/anonbib/cache/wpes12-cogs.pdf +14. https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-disco…

1 0