<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>It seems like we are trying to solve two distinct problems with some large sub-problems, but we haven't adequately unraveled them:<br></div><div><br></div><div>1.  How to distribute bridges from a database to minimize bridge enumeration by adversaries</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_quote"><div>a. How to identify users</div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_quote"><div>b. How to distribute bridges to identified users</div></div></blockquote><div class="gmail_quote"><div>2. How to add more bridges and/or refresh burnt bridges to the database.</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_quote"><div>a. Adding more bridges</div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_quote"><div>b. Refreshing burnt bridges</div></div></blockquote><hr style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><div><b>1a.</b> Seems to be a topic of discussion. Before addressing a problem I prefer to understand what I want out of a solution to a problem. In the case of 1a for this project, I'd like:<div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Consistent mapping</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Cross platform</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Maximizes user privacy/anonymity</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Understandable to users</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Usable by all users</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>No/minimal maintenance required</div></blockquote><div><br></div>Three solutions have been proposed - browser fingerprinting (via this thread) and social networks (via salmon paper). I'd argue that both fail to be useful in this case. (At least w/r/t the criteria I proposed - I'd be curious to hear other criteria sets)</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><b>Browser fingerprinting</b> fails because if I try to get bridges from my desktop vs my laptop vs my cell vs at a library vs at an internet cafe, I will not be mapped to the same user. Additionally, if I make a change to my setup (switch from Firefox to Chrome, new monitor resolution, etc.) even on the same machine I likely would not be mapped to the same profile (or if I am, it seems that a censor would be able to generate enough profiles that they end up in several "trusted" groups). I'd also argue that collecting the browser fingerprints of some of the most vulnerable Tor users (those that need bridges) is a risk. While I trust the Tor project to maintain good data and security practices at present, am I confident that a new vulnerability won't arise, or a new 0 day that could be used to acquire the information Tor maintains? No - especially not with the value that a DB of fingerprints of those subverting censorship would be to a censor.</div><div><br></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><b>Social networks</b> fail because they are not usable by all users (whether by choice or by censorship). This approach will also require maintenance.</div><div><br></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><b>SMS </b>- Tom states "Chinese +86 phone numbers must be real name verification to using (due to against like telephone crimes). Using these number received the SMS will break the anonymity." Philipp also states that this would likely be resource intensive.</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br></div></blockquote>I'll propose one more potential - PGP signing, which I think works better than the above three, but is far from perfect.<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><b>PGP signing</b> requests for bridges would enable a consistent, cross-platform mapping. There are plenty of resources available to understand how pgp works, and minimal maintenance and implementation would be needed. There are lots of open source implementations too. We also get the added bonus of years of people looking at trust and PGP keys, so we don't need to start from scratch when approaching this difficult problem. Additionally, users must deliberately sign their request with their preferred key.</div></blockquote><div><div class="gmail_quote"><div><hr style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><b>1b.</b> Seems well solved by salmon, at least on my first read.</div><div><hr style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"></div><div><b>2a.</b> I do not have any thoughts on this</div><div><hr style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><b>2b.</b> I have been thinking about this a lot lately - it seems that there are two parts to solve this problem too, but either could be useful on their own:</div></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div class="gmail_quote"><div>1. Reach-ability probing from adversarial regions (aka identifying burnt bridges)</div></div></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div class="gmail_quote"><div>2. Ability for bridges to easily and quickly change IP address (refreshing a bridge)</div><div><br></div></div></div></div></div></blockquote>1. Is a really interesting problem which could help inform our approaches to these other problems - it would provide more accurate data as to when bridges get blocked (which seems useful w/ salmon). Of course, this would require either having a vantage point in an adversarial region, or taking advantage of existing protocols to cause something in the adversarial region to ping a server. We also wouldn't want an adversary to be able to simply follow our "pings" to enumerate our server as well. I do not think this is an easy problem, but I think a successful solution would be immensely useful.<br><div><div><div><div class="gmail_quote"><div><br></div><div>2. Is dependent on the bridge hosting solution, however, we may be able to provide a few scripts for a few environments which would do the job. For example, you could implement 2 in gcloud pretty simply:</div><div><div>- Setup <a href="https://cloud.google.com/compute/docs/gcloud-compute" target="_blank">gcloud compute</a> on your Google cloud OBFS server. Then, setup a script which does the following when triggered:</div></div></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div class="gmail_quote"><div><div>- <a href="https://cloud.google.com/compute/docs/gcloud-compute#creating" target="_blank">Initialized a new instance</a></div></div></div></div></div></div><div><div><div><div class="gmail_quote"><div><div>- <a href="https://cloud.google.com/compute/docs/gcloud-compute#connecting-other" target="_blank">Give the old instance ssh access to the new instance</a></div></div></div></div></div></div><div><div><div><div class="gmail_quote"><div><div>- SCP over the existing torrc, bridge state files, etc.</div></div></div></div></div></div><div><div><div><div class="gmail_quote"><div><div>- Once complete, uses ssh to tell the new bridge all files have been copied over and it can finish initialization and start up</div></div></div></div></div></div><div><div><div><div class="gmail_quote"><div><div>- <a href="https://cloud.google.com/compute/docs/gcloud-compute#deleting" target="_blank">New bridge deletes old bridge</a> after ensuring it is fully functional</div></div></div></div></div></div></blockquote><div><div><div><div class="gmail_quote"><div><div>There may be a step or two missing above, but this should give the bridge a new ip address, and this script could be manually triggered by a bridge operator, or if we figure out a bridge reach-ability solution then the bridge could use the solution and automatically restart based upon failed reach-ability tests. And regarding the scripts, my understanding is that AWS also provides enough power in their CLI to be able to do the same, and this should add minimal (if any) expenses on top of what any bridge operators are incurring in the cloud.<br></div><div><br></div><div>Best,</div><div>Sam</div></div></div></div></div></div></div><div class="gmail-yj6qo gmail-ajU" style="outline:none;padding:10px 0px;width:22px;margin:2px 0px 0px"><br class="gmail-Apple-interchange-newline"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 9:57 PM soncyq47 <<a href="mailto:soncyq47@protonmail.com">soncyq47@protonmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p style="margin-bottom:0cm;line-height:100%">There are 4 parts.<br></p><p style="margin-bottom:0cm;line-height:100%">-- /1./ --<br></p><p style="margin-bottom:0cm;line-height:100%">For those that are
new let me explain my discussion with Philipp Winter.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">I suggest a browser
fingerprinting based bridge distribution.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">Each fingerprint
only gets one bridge, so if you keep automatically asking you just
keep getting the same address over and over.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">I can tell you that
it is almost impossible to exhaustively spoof a fingerprint, and we
can use that to our advantage. We can group similar fingerprints
together so that it doesn't matter if someone spoofs a few things.
And we should ignore the user-agent.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">>>I think I'm
missing something here.  Doesn't it suffice for an adversary<br></p><p style="margin-bottom:0cm;line-height:100%">to tamper with a
single feature to create a new browser fingerprint, and<br></p><p style="margin-bottom:0cm;line-height:100%">thus obtain
different bridges?  I suppose it would depend on how the<br></p><p style="margin-bottom:0cm;line-height:100%">server derives its
fingerprints.<<<br></p><p style="margin-bottom:0cm;line-height:100%">Like I said: Once
we've given out all the bridges to each unique fingerprint then we
start grouping new fingerprints to the nearest match.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">In other words we
assume the first users are more legitimate, and the GFW comes along
later. So in the beginning we give out a new bridge to a fingerprint
that is anyhow different from one we’ve seen before, and once we’ve
given them all out (that we are willing to give out through
fingerprinting), then if a new fingerprint comes along, he gets the
same bridge as the fingerprint that had the highest quantity of same
aspects to it. This defeats partial spoofing. Like I said, full
spoofing is near impossible.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">-- /2./ --<br></p><p style="margin-bottom:0cm;line-height:100%">>>I know lots
of people in China using Linode and Google Cloud which also<br></p><p style="margin-bottom:0cm;line-height:100%">a credit card. They
only support the credit card like VISA or MasterCard<br></p><p style="margin-bottom:0cm;line-height:100%">instead of China
UnionPay card. So it isn't too hard if someone wants to<br></p><p style="margin-bottom:0cm;line-height:100%">get the card,
especially is GFW who be described as "unlimited fund" by<br></p><p style="margin-bottom:0cm;line-height:100%">GFW technology
review blog.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">They don't block the
IP just because a few people use it. Yes, the<br></p><p style="margin-bottom:0cm;line-height:100%">credit card it did
block a lot of people:(<<<br></p><p style="margin-bottom:0cm;line-height:100%">Thanks Tom for
clearing up my misunderstanding.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">-- /3./ –<br></p><p style="margin-bottom:0cm;line-height:100%">Why not switch Obfs4
bridges to dynamic IPs and remove UpdateBridgesFromAuthority. This
would make it like WAY more blocking resistant.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">-- /4./ –<br></p><p style="margin-bottom:0cm;line-height:100%">I take back what I
said, I recon the Salmon algorithm is currently the best proxy
distribution we have. I’m planning to read the paper, but just from
what I’ve seen from the talk... <a href="https://www.invidio.us/watch?v=RO3wXRn8BfY" target="_blank">https://www.invidio.us/watch?v=RO3wXRn8BfY</a><br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">… I see one major
vulnerability: what if the GFW gets just one bridge, then creates
thousands of accounts (which there is no barrier for), then sends an
invite across all of those accounts, then waits for trust level to
get high, and all of those accounts gets a new bridge, repeat until
you know all the bridges, then only block them all in one go once
they have all the addresses.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">The solution is to
put a limit on how many addresses are given out per accounts with
knowledge of a certain bridge. Basically extending the recommendation
grouping that every bridge which accounts know only allows for a
finite quantity of new bridges to be received. So an adversary that
has one address can’t crawl the whole network, but only a fraction
of it.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">Another but minor
weakness, I don’t think social network based distribution would
scale well compared to fingerprinting based distribution.<br></p><p style="margin-bottom:0cm;line-height:100%"><br></p><p style="margin-bottom:0cm;line-height:100%">I’m not claiming
to know it all but hopefully my thoughts are helpful.<br></p><div><br></div>_______________________________________________<br>
anti-censorship-team mailing list<br>
<a href="mailto:anti-censorship-team@lists.torproject.org" target="_blank">anti-censorship-team@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team</a><br>
</blockquote></div>