August 2012 - tor-commits - lists.torproject.org

[tech-reports/master] Add five-ways-test-bridge-reachability blog post.
by karsten＠torproject.org 30 Aug '12

30 Aug '12

commit fb31be566ba61aa076bed0f22c6f5228f8a67513 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 8 20:13:17 2012 +0200 Add five-ways-test-bridge-reachability blog post. --- 2011/five-ways-test-bridge-reachability/.gitignore | 3 + .../five-ways-test-bridge-reachability.bib | 70 ++++ .../five-ways-test-bridge-reachability.tex | 349 ++++++++++++++++++++ .../tortechrep.cls | 1 + 4 files changed, 423 insertions(+), 0 deletions(-) diff --git a/2011/five-ways-test-bridge-reachability/.gitignore b/2011/five-ways-test-bridge-reachability/.gitignore new file mode 100644 index 0000000..05419b2 --- /dev/null +++ b/2011/five-ways-test-bridge-reachability/.gitignore @@ -0,0 +1,3 @@ +five-ways-test-bridge-reachability.pdf +five-ways-test-bridge-reachability-2011-12-01.pdf + diff --git a/2011/five-ways-test-bridge-reachability/five-ways-test-bridge-reachability.bib b/2011/five-ways-test-bridge-reachability/five-ways-test-bridge-reachability.bib new file mode 100644 index 0000000..85d135f --- /dev/null +++ b/2011/five-ways-test-bridge-reachability/five-ways-test-bridge-reachability.bib @@ -0,0 +1,70 @@ +@techreport{dingledine2011strategies, + title = {Strategies for getting more bridge addresses}, + author = {Roger Dingledine}, + institution = {The Tor Project}, + year = {2011}, + month = {May}, + number = {2011-05-001}, + note = {\url{https://research.torproject.org/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf}}, +} + +@inproceedings{loesing2010case, + title = {A Case Study on Measuring Statistical Data in the {Tor} Anonymity Network}, + author = {Karsten Loesing and Steven J. Murdoch and Roger Dingledine}, + booktitle = {Proc.\ Workshop on Ethics in Computer Security Research}, + year = {2010}, + month = Jan, + address = {Tenerife, Canary Islands, Spain}, + note = {\url{https://metrics.torproject.org/papers/wecsr10.pdf}}, +} + +@techreport{danezis2011anomaly, + title = {An anomaly-based censorship-detection system for {Tor}}, + author = {George Danezis}, + institution = {The Tor Project}, + year = {2011}, + month = {September}, + number = {2011-09-001}, + note = {\url{https://research.torproject.org/techreports/detector-2011-09-09.pdf}}, +} + +@techreport{loesing2011case, + title = {Case study: Learning whether a {Tor} bridge is blocked by + looking at its aggregate usage statistics, Part One}, + author = {Karsten Loesing}, + institution = {The Tor Project}, + year = {2011}, + month = {September}, + number = {2011-09-002}, + note = {\url{https://research.torproject.org/techreports/blocking-2011-09-15.pdf}}, +} + +@techreport{dingledine2011ten, + title = {Ten ways to discover {Tor} bridges}, + author = {Roger Dingledine}, + institution = {The Tor Project}, + year = {2011}, + month = {October}, + number = {2011-10-002}, + note = {\url{https://research.torproject.org/techreports/ten-ways-discover-tor-bridges-2011-10-31.pdf}}, +} + +@inproceedings{proximax11, + title = {Proximax: Fighting Censorship With an Adaptive System for Distribution of Open + Proxies}, + author = {Kirill Levchenko and Damon McCoy}, + booktitle = {Proceedings of Financial Cryptography and Data Security (FC'11)}, + year = {2011}, + month = {February}, + note = {\url{http://freehaven.net/anonbib/#proximax11}}, +} + +@inproceedings{oakland11-formalizing, + title = {Formalizing Anonymous Blacklisting Systems}, + author = {Ryan Henry and Ian Goldberg}, + booktitle = {Proceedings of the 2011 IEEE Symposium on Security and Privacy}, + year = {2011}, + month = {May}, + note = {\url{http://freehaven.net/anonbib/#oakland11-formalizing}}, +} + diff --git a/2011/five-ways-test-bridge-reachability/five-ways-test-bridge-reachability.tex b/2011/five-ways-test-bridge-reachability/five-ways-test-bridge-reachability.tex new file mode 100644 index 0000000..84c95ee --- /dev/null +++ b/2011/five-ways-test-bridge-reachability/five-ways-test-bridge-reachability.tex @@ -0,0 +1,349 @@ +\documentclass{tortechrep} +\begin{document} + +\author{Roger Dingledine} +\contact{arma(a)torproject.org} +\reportid{2011-12-001} +\date{December 1, 2011} +\title{Five ways to test bridge reachability} +\maketitle + +\section{Introduction} + +Once we get more (and more diverse) bridge addresses +\cite{dingledine2011strategies}, +the next research step is that we'll need to get better at telling which +bridges are blocked in which jurisdictions. +For example, most of the bridges we give out via https and gmail are +blocked in China. +But which ones exactly? +How quickly do they get blocked? +Do some last longer than others? +Do they ever get unblocked? +Is there some pattern to the blocking, either by time, by IP address or +network, by user load on the bridge, or by distribution strategy? +We can't evaluate new bridge distribution strategies% +\footnote{\url{https://blog.torproject.org/blog/bridge-distribution-strategies}} +if we can't track whether the bridges in each strategy are being blocked. + +Generally speaking, bridge reachability tests break down into two +approaches: passive and active. +Passive tests don't involve any new connections on the part of Tor clients +or bridges, whereas active tests follow the more traditional ``scanning'' +idea. +None of the reachability tests we've thought of are perfect. +Instead, here we discuss how to combine imperfect tests and use feedback +from the tests to balance their strengths and weaknesses. + +\section{Passive approaches} + +We should explore two types of passive testing approaches: reporting from +bridges and reporting from clients. + +\subsection{Reporting from bridges} + +Right now Tor relays and bridges publish aggregate user counts +\cite{loesing2010case}---rough number of users per country per day. +In theory we can look at the user counts over time to detect statistical +drops in usage for a given country. +That approach has produced useful results in practice for overall +connections to the public Tor relays from each country: +see George Danezis's initial work \cite{danezis2011anomaly} on a Tor +censorship detector. + +But there are two stumbling blocks when trying to apply the censorship +detector model to individual bridges. +First, we don't have ground truth about which bridges were \emph{actually} +blocked or not at a given time, so we have no way to validate our models. +Second, while overall usage of bridges in a given country might be high, +the load \emph{on a given bridge} tends to be quite low, which in turns +makes it difficult to achieve statistical significance +\cite{loesing2011case} when looking at usage drops. + +Ground truth needs to be learned through active tests: we train the models +with usage patterns for bridges that get blocked and bridges that don't +get blocked, and the model predictions should improve. +The question of statistical significance can be overcome by treating the +prediction as a hint: even if our models don't give us enough confidence +to answer ``blocked for sure'' or ``not blocked for sure'' about a given +bridge, they should be able to give us a number reflecting likelihood that +the bridge is now blocked. +That number should feed back into the active tests, for example so we pay +more attention to bridges that are more likely to be newly blocked. + +\subsection{Reporting from clients} + +In addition to the usage reporting by bridges, we should also consider +reachability reporting by clients. +Imagine a Tor client that has ten bridges configured. +It tries to connect to each of them, and finds that two work and eight +don't. +This client is doing our scanning for us, if only we could safely learn +about its results. +The first issue that comes up is that it could mistakenly report that a +bridge is blocked if that bridge is instead simply down. +So we would want to compare the reports to concurrent active scans from a +``more free'' jurisdiction, to pick out the bridges that are up in one +place yet down in another. + +From there, the questions get trickier: +1) does the set of bridges that a +given user reports about create a fingerprint that lets us recognize that +user later? +Even if the user reports about each bridge through a separate Tor circuit, +we'd like to know the time of the scan, and nearby times can be used to +build a statistical profile. +2) What if users submit intentionally misleading reports? +It seems there's a tension between wanting to build a profile for the user +(to increase our confidence in the validity of her reports) versus wanting +to make sure the user doesn't develop any recognizable profile. +Perhaps the Nymble \cite{oakland11-formalizing} design family can +contribute an ``unlinkable reputation'' trick to resolve the conflict, but +as we find ourselves saying so often at Tor, more research remains. + +\section{Active approaches} + +The goal of active scanning is to get ground truth on whether each bridge +is really blocked. +There's a tradeoff here: frequent scans give us better resolution and +increased confidence, but too many scan attempts draw attention to the +scanners and thus to the addresses being scanned. + +We should use the results of the passive and indirect scans to give hints +about what addresses to do active scans on. +In the steady-state, we should aim to limit our active scans to bridges +that we think just went from unblocked to blocked or vice versa, and to a +sample of others for spot checks to keep our models trained. + +There are three pieces to active scanning: direct scans, reverse scans, +and indirect scans. + +\subsection{Direct scans} + +Direct scans are what we traditionally think of when we think of scanning: +get access to a computer in the target country, give it a list of bridges, +and have it connect directly to each bridge on the list. + +Before I continue though, I should take an aside to discuss types of +blocking. +In September 2009 when China first blocked some bridges, I spent a while +probing the blocked bridges from a computer in Beijing. +From what I could tell, China blocked the bridges in two ways. +If the bridge had no other interesting services running (like a +webserver), they just blackholed the IP address, meaning no packets to or +from the IP address made it through the firewall. +But if there \emph{was} an interesting service, they blocked the bridge by +IP and port. +(I could imagine this more fine-grained blocking was done by dropping SYN +packets, or by sending TCP RST packets; but I didn't get that far in my +investigation.) + +So there are two lessons to be learned here. +First, the degree to which our active scans match real Tor client behavior +could influence the accuracy of the scans. +Second, some real-world adversaries are putting considerable +effort---probably manual effort---into examining the bridges they find and +choosing how best to filter them. +After all, if they just blindly filtered IP addresses we list as bridges, +we could add Baidu's address as a bridge and make them look foolish. +(We tried that; it didn't work.) + +These lessons leave us with two design choices to consider. + +First, how much of the Tor protocol should we use when doing the scans? +The spectrum ranges from a simple TCP scan (or even just a SYN scan), to a +vanilla SSL handshake, to driving a real Tor client that does a genuine +Tor handshake. +The less realistic the handshake, the more risk that we conclude the +bridge is reachable when in fact it isn't; but the more realistic the +handshake, the more we stand out to an adversary watching for Tor-like +traffic. + +The mechanism by which the adversary is discovering bridges +\cite{dingledine2011ten} also impacts which reachability tests are a smart +idea. +For example, it appears that China may have recently started doing deep +packet inspection (DPI) for Tor-like connections over the Great Firewall +and then doing active-followup SSL handshakes to confirm which addresses +are Tor bridges. +If that report turns out to be true, testing bridge reachability via +active scans that include handshaking would be counterproductive: the act +of doing the test would influence the answer. +We can solve their attack by changing our handshake% +\footnote{\url{https://blog.torproject.org/blog/iran-blocks-tor-tor-releases-same-day-fix}} +so they don't recognize it anymore, or by introducing scanning-resistance% +\footnote{\url{https://svn.torproject.org/svn/projects/design-paper/blocking.html\#tth\_sEc9.3}} +measures like bridge passwords. +In the shorter-term, we should confirm that simple connection scanning +(without a handshake) doesn't trigger any blocks, and then restrict +ourselves to that type of scanning in China until we've deployed a better +answer. + +Second, should we scan ``decoy'' addresses as well, to fool an observer +into thinking that we're not scanning for Tor bridges in particular, +and/or to drive up the work the observer needs to do to distinguish the +``real'' bridges? +Whether this trick is useful depends on the level of sophistication and +dedication of the adversary. +For example, China has already demonstrated that they check IP addresses +before blocking them, and in general I worry that the more connections you +make to \emph{anything}, the more likely you are to attract attention for +further scrutiny. +How would we generate the list of decoy addresses? +If we choose it randomly from the space of IP addresses, a) most of them +will not respond, and b) we'll invite abuse complaints from security +people looking for worms. +Driving up the work factor sounds like a great feature, but it could have +the side effect that it encourages the adversary to invest in an automated +``is this a Tor bridge'' checker, which would be an unfortunate step for +them to take if they otherwise wouldn't. + +Active direct scans come with a fundamental dilemma: the more we think a +bridge has been blocked, the more we want to scan it; but the more likely +it is to be blocked, the more the adversary might already be watching for +connections to it, for example to do a ``zig-zag'' bridge enumeration +attack \cite{dingledine2011ten}. +So we need to avoid scanning bridges that we think are not blocked. +But we also need to explore more subtle scanning techniques such as the +ones below. + +\subsection{Reverse scans} + +A bridge that gets duplex% +\footnote{\url{http://en.wikipedia.org/wiki/Duplex\_\%28telecommunications\%29}} +blackholed by a government firewall can learn that it has been filtered by +trying to make a connection \emph{into} the filtered country. + +For example, each bridge might automatically connect to baidu.com +periodically, and publish the results of its reachability test in its +extrainfo descriptor. +We could either feed this information into the models and follow up with +other active probes if the bridge thinks it's been blocked; or we could +use it the other way by instructing bridges that we think have been +blocked to launch a reverse scan. + +We can actually take advantage of the flexibility of the Tor protocol to +do scanning from each bridge to Baidu without changing the bridge code at +all: we simply try to extend an ordinary circuit from the bridge to the +target destination, and learn at what stage the 'extend' request failed. +(We should extend the Tor control protocol% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/2576}} to +expose the type of failure to the Tor controller, but that's a simple +matter of programming.) + +Note that these reverse scans can tell us that a bridge has been blocked, +but it can't tell us that a bridge \emph{hasn't} been blocked, since it +could just be blocked in a more fine-grained way. + +Finally, how noticeable would these reverse scans be? +That is, could the government firewall enumerate bridges by keeping an eye +out for Tor-like connection attempts to Baidu? +While teaching the bridges to do the scanning themselves would require +more work, it would give us more control over how much the scans stick +out. + +\subsection{Indirect scans} + +Indirect scans use other services as reflectors. +For example, you can connect to an FTP server inside the target country, +tell it that your address is the address of the bridge you want to scan, +and then try to fetch a file. +How it fails should tell you whether that FTP server could reach the +bridge or not. + +There are many other potential reflector protocols out there, each with +their own tradeoffs. +For example, can we instruct a DNS request in-country to recurse to the +target bridge address, and distinguish between ``I couldn't reach that DNS +server'' and ``that wasn't a DNS server''? +(DNS is probably not the right protocol to use inside China, given the +amount of DNS mucking they are already known to do.) + +Another avenue is a variant on idle scanning,% +\footnote{\url{http://nmap.org/book/idlescan.html}} which takes advantage +of predictable TCP IPID patterns: send a packet directly to the bridge to +learn its current IPID, then instruct some computer in-country to send a +packet, and then send another packet directly to find the new IPID and +learn whether or not the in-country packet arrived. + +What other services can be bent to our will? +Can we advertise the bridge address on a bittorrent tracker that's popular +in China and see whether anybody connects? +Much creative research remains here. + +\section{Putting it all together} + +One of the puzzle pieces holding us back from rolling out the ``tens of +thousands of bridge addresses offered by volunteers with spare net +blocks'' plan is that we need better ways to get feedback on when +addresses get blocked. +The ideas in this blog post hopefully provide a good framework for +thinking about the problem. + +For the short term, we should deploy a basic TCP connection scanner from +inside several censoring countries (China, Iran, and Syria come to mind). +Since the ``clients report'' passive strategy still has some open research +questions, we should get all our hints from the ``bridges report'' passive +strategy. +As we're ramping up, and especially since our current bridges are either +not blocked at all (outside China), or mostly blocked (inside China), we +should feel free to do more thorough active scans to get a better +intuition about what scanning can teach us. + +In the long term, I want to use these various building blocks in a +feedback loop to identify and reward successful bridge distribution +strategies, as outlined in Levchenko and McCoy's FC 2011 paper +\cite{proximax11}. + +Specifically, we need these four building blocks: + +\begin{enumerate} + +\item A way to discover how much use a bridge is seeing from a given +country. Done: see the WECSR10 paper \cite{loesing2010case} +and usage graphs% +\footnote{\url{https://metrics.torproject.org/users.html\#bridge-users}}. + +\item A way to get fresh bridge addresses over time. +The more addresses we can churn through, the more aggressive we can be in +experimenting with novel distribution approaches. +See the ``more bridge addresses'' report \cite{dingledine2011strategies} +for directions here. + +\item A way to discover when a bridge is blocked in a given country. +That's what this report is about. + +\item Distribution strategies that rely on different mechanisms to make +enumeration difficult. +Beyond our ``https'' and ``gmail'' distribution strategies, we know a +variety of people in censored countries, and we can think of each of these +people as a distribution channel. + +\end{enumerate} + +We can define the \emph{efficiency} of a bridge address in terms of how +many people use it and how long before it gets blocked. +So a bridge that gets blocked very quickly scores a low efficiency, a +bridge that doesn't get blocked but doesn't see much use scores a medium +efficiency, and a popular bridge that doesn't get blocked scores high. +We can characterize the efficiency of a distribution channel as a function +of the efficiency of the bridges it distributes. +The key insight is that we then adapt how many new bridges we give to each +distribution channel based on its efficiency. +So channels that are working well automatically get more addresses to give +out, and channels that aren't working well automatically end up with fewer +addresses. + +Of course, there's more to it than that. +For example, we need to consider how to handle the presence of bridge +enumeration attacks that work independently of which distribution channel +a given bridge address was given to. +We also need to consider attacks that artificially inflate the efficiency +of bridges (and thus make us overreward distribution channels), or that +learn about a bridge but choose not to block it. +But that, as they say, is a story for another time. + +\bibliography{five-ways-test-bridge-reachability} + +\end{document} + diff --git a/2011/five-ways-test-bridge-reachability/tortechrep.cls b/2011/five-ways-test-bridge-reachability/tortechrep.cls new file mode 120000 index 0000000..4c24db2 --- /dev/null +++ b/2011/five-ways-test-bridge-reachability/tortechrep.cls @@ -0,0 +1 @@ +../../tortechrep.cls \ No newline at end of file

1 0

[tech-reports/master] Add better-guard-rotation-parameters blog post.
by karsten＠torproject.org 30 Aug '12

30 Aug '12

commit 9205dc2be399befed4a0dbebdf0da850e9d8dbbd Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 8 20:15:39 2012 +0200 Add better-guard-rotation-parameters blog post. --- 2011/better-guard-rotation-parameters/.gitignore | 3 + .../better-guard-rotation-parameters.bib | 33 +++++ .../better-guard-rotation-parameters.tex | 128 ++++++++++++++++++++ .../tortechrep.cls | 1 + 4 files changed, 165 insertions(+), 0 deletions(-) diff --git a/2011/better-guard-rotation-parameters/.gitignore b/2011/better-guard-rotation-parameters/.gitignore new file mode 100644 index 0000000..d688c86 --- /dev/null +++ b/2011/better-guard-rotation-parameters/.gitignore @@ -0,0 +1,3 @@ +better-guard-rotation-parameters.pdf +better-guard-rotation-parameters-2011-08-20.pdf + diff --git a/2011/better-guard-rotation-parameters/better-guard-rotation-parameters.bib b/2011/better-guard-rotation-parameters/better-guard-rotation-parameters.bib new file mode 100644 index 0000000..307e804 --- /dev/null +++ b/2011/better-guard-rotation-parameters/better-guard-rotation-parameters.bib @@ -0,0 +1,33 @@ +@article{Wright:2004, + title = {{The Predecessor Attack: An Analysis of a Threat to Anonymous Communications + Systems}}, + author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields}, + journal = {ACM Transactions on Information and System Security (TISSEC)}, + volume = {4}, + number = {7}, + year = {2004}, + month = {November}, + pages = {489--522}, + note = {\url{http://freehaven.net/anonbib/#Wright:2004}}, +} + +@inproceedings{ccs07-doa, + title = {Denial of Service or Denial of Security? {H}ow Attacks on Reliability can + Compromise Anonymity}, + author = {Nikita Borisov and George Danezis and Prateek Mittal and Parisa Tabriz}, + booktitle = {Proceedings of CCS 2007}, + year = {2007}, + month = {October}, + note = {\url{http://freehaven.net/anonbib/#ccs07-doa}}, +} + +@techreport{dingledine2011measuring, + title = {Measuring the safety of the {Tor} network}, + author = {Roger Dingledine}, + institution = {The Tor Project}, + year = {2011}, + month = {February}, + number = {2011-02-001}, + note = {\url{https://research.torproject.org/techreports/measuring-safety-tor-network.pdf}}, +} + diff --git a/2011/better-guard-rotation-parameters/better-guard-rotation-parameters.tex b/2011/better-guard-rotation-parameters/better-guard-rotation-parameters.tex new file mode 100644 index 0000000..9e5b453 --- /dev/null +++ b/2011/better-guard-rotation-parameters/better-guard-rotation-parameters.tex @@ -0,0 +1,128 @@ +\documentclass{tortechrep} +\begin{document} + +\author{Roger Dingledine} +\contact{arma(a)torproject.org} +\reportid{2011-08-001} +\date{August 20, 2011} +\title{Better guard rotation parameters} +\maketitle + +Tor's entry guard design% +\footnote{\url{https://www.torproject.org/docs/faq\#EntryGuards}} +protects users in a variety of ways. + +First, they protect against the ``predecessor attack'' \cite{Wright:2004}: +if you choose new relays for each circuit, eventually an attacker who runs +a few relays will be your first and last hop. +With entry guards, the risk of end-to-end correlation for any given +circuit is the same, but the cumulative risk for all your circuits over +time is capped. + +Second, they help to protect against the ``denial of service as denial of +anonymity'' attack \cite{ccs07-doa}, where an attacker who runs quite a +few relays fails any circuit that he's a part of and that he can't win +against, forcing Alice (the user) to generate more circuits and thus +increasing the overall chance that the attacker wins. +Entry guards greatly reduce the risk, since Alice will never choose +outside of a few nodes for her first hop. + +Third, entry guards raise the startup cost to an adversary who runs relays +in order to trace users. +Without entry guards, the attacker can sign up some relays and immediately +start having chances to observe Alice's circuits. +With them, new adversarial relays won't have the Guard flag so won't be +chosen as the first hop of any circuit; and even once they earn the Guard +flag, users who have already chosen guards won't switch away from their +current guards for quite a while. + +But how long exactly? +The first research question here examines vulnerability due to natural +churn of entry guards. +Consider an adversary who runs one entry guard with advertised capacity +$C$. +Alice maintains an ordered list of guards (chosen at random, weighted by +advertised speed, from the whole list of possible guards). +For each circuit, she chooses her first hop (uniformly at random) from the +first $G$ guards from her list that are currently running (appending a new +guard to the list as needed, but going back to earlier guards if they +reappear). +How long until Alice adds the adversary's node to her guard list? +You can use the uptime data from the directory archives% +\footnote{\url{https://metrics.torproject.org/data.html}}, +either to build a model for guard churn or just to use the churn data +directly. +Assuming $G=3$, how do the results vary by $C$? +What's the variance? + +Research question two: consider intentional churn due to load balancing +too. +Alice actually discards each guard between 30 and 60 days (uniformly +chosen) after she first picks it. +This intentional turnover prevents long-running guards from accumulating +more and more users and getting overloaded. +Another way of looking at it is that it shifts load to new guards so we +can make better use of them. +How much does this additional churn factor impact your answer from step +one above? +Or asked a different way, what fraction of Alice's vulnerability to the +adversary's entry guard comes from natural churn, and what fraction from +the proactive expiration? +How does the answer change for different expiry intervals (e.g.\ between 10 +and 30 days, or between 60 and 90)? + +Research question three: how do these answers change as we vary $G$? +Right now we choose from among the first three guards, to reduce the +variance of expected user performance---if we always picked the first +guard on the list, and some users picked a low-capacity or +highly-congested relay, none of that user's circuits would perform well. +That said, if choosing $G=1$ is a huge win for security, we should work on +other ways to reduce variance. + +Research question four: how would these answers change if we make the +cutoffs for getting the Guard flag more liberal, and/or change how we +choose what nodes become guards? +After all, Tor's anonymity is based on the diversity of entry and exit +points \cite{dingledine2011measuring}, and while it may be tough to get +around exit relay scarcity, my theory is that our artificial entry point +scarcity (because our requirements are overly strict) is needlessly +hurting the anonymity Tor can offer. + +Our current algorithm for guard selection has three requirements: + +\begin{enumerate} +\item The relay needs to have first appeared longer ago than 12.5\% of the +relays, or 8 days ago, whichever is shorter. +\item The relay needs to advertise at least the median bandwidth in the +network, or 250KB/s, whichever is smaller. +\item The relay needs to have at least the median +weighted-fractional-uptime of relays in the network, or 98\% WFU, +whichever is smaller. +(For WFU, the clock starts ticking when we first hear about the relay; we +track the percentage of that time the relay has been up, discounting +values by 95\% every 12 hours. +\end{enumerate} + +Today's guard cutoffs in practice are ``was first sighted at least 8 days +ago, advertises 100KB/s of bandwidth, and has 98\% WFU.'' + +Consider two relays, A and B. +Relay A first appeared 30 days ago, disappeared for a week, and has been +consistently up since then. +It has a WFU (after decay, give or take a fencepost) of 786460 seconds / +824195 = 95.4\%, so it's not a guard. +Relay B appeared two weeks ago and has been up since then. +Its WFU is 658517 / 658517 = 100\%, so it gets the Guard flag---even +though it has less uptime, and even less weighted uptime. +Based on the answers to the first three research questions, which relay +would serve Alice best as a guard? + +The big-picture tradeoff to explore is: what algorithm should we use to +assign Guard flags such that a) we assign the flag to as many relays as +possible, yet b) we minimize the chance that Alice will use the +adversary's node as a guard? + +\bibliography{better-guard-rotation-parameters} + +\end{document} + diff --git a/2011/better-guard-rotation-parameters/tortechrep.cls b/2011/better-guard-rotation-parameters/tortechrep.cls new file mode 120000 index 0000000..4c24db2 --- /dev/null +++ b/2011/better-guard-rotation-parameters/tortechrep.cls @@ -0,0 +1 @@ +../../tortechrep.cls \ No newline at end of file

1 0

[tech-reports/master] Add strategies-getting-more-bridge-addresses blog post.
by karsten＠torproject.org 30 Aug '12

30 Aug '12

commit b11131537ab6cf12d41fd3905f1a7ea87b587f57 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 8 20:18:32 2012 +0200 Add strategies-getting-more-bridge-addresses blog post. --- .../.gitignore | 3 + .../strategies-getting-more-bridge-addresses.tex | 174 ++++++++++++++++++++ .../tortechrep.cls | 1 + 3 files changed, 178 insertions(+), 0 deletions(-) diff --git a/2011/strategies-getting-more-bridge-addresses/.gitignore b/2011/strategies-getting-more-bridge-addresses/.gitignore new file mode 100644 index 0000000..4b83c05 --- /dev/null +++ b/2011/strategies-getting-more-bridge-addresses/.gitignore @@ -0,0 +1,3 @@ +strategies-getting-more-bridge-addresses.pdf +strategies-getting-more-bridge-addresses-2011-05-13.pdf + diff --git a/2011/strategies-getting-more-bridge-addresses/strategies-getting-more-bridge-addresses.tex b/2011/strategies-getting-more-bridge-addresses/strategies-getting-more-bridge-addresses.tex new file mode 100644 index 0000000..cd2b8e4 --- /dev/null +++ b/2011/strategies-getting-more-bridge-addresses/strategies-getting-more-bridge-addresses.tex @@ -0,0 +1,174 @@ +\documentclass{tortechrep} +\begin{document} + +\author{Roger Dingledine} +\contact{arma(a)torproject.org} +\reportid{2011-05-001} +\date{May 13, 2011} +\title{Strategies for getting more bridge addresses} +\maketitle + +\section{Introduction} + +We need more bridges. +When I first envisioned the bridge address arms race, I said ``We need to +get lots of bridges, so the adversary can't learn them all.'' +That was the wrong statement to make. +In retrospect, the correct statement was: ``We need the rate of new bridge +addresses to exceed the rate that the adversary can block them.'' + +For background, bridge relays% +\footnote{\url{https://www.torproject.org/bridges}} +(aka bridges) are Tor relays that aren't listed in the main Tor directory. +So even if an attacker blocks all the public relays, they still need to +block all these ``private'' or ``dark'' relays too. +We deployed them several years ago% +\footnote{\url{https://svn.torproject.org/svn/projects/design-paper/blocking.html}} +in anticipation of the upcoming arms race, and they worked great in their +first showing in 2009% +\footnote{\url{https://blog.torproject.org/blog/picturing-tor-censorship-china}}. +But since then, China has learned and blocked% +\footnote{\url{https://metrics.torproject.org/users.html?graph=bridge-users&start=2010-01-01&end=2011-04-09&country=cn\#bridge-users}} +most of the bridges we give out through public (https and gmail) +distribution channels. + +One piece of the puzzle is smarter bridge distribution mechanisms% +\footnote{\url{https://blog.torproject.org/blog/bridge-distribution-strategies}} +(plus see this post% +\footnote{\url{https://lists.torproject.org/pipermail/tor-dev/2009-December/000666.html}} +for more thoughts)---right now we're getting 8000 mails a day from gmail +asking for bridges from a pool of less than a thousand% +\footnote{\url{https://metrics.torproject.org/network.html\#networksize}}. +The distribution strategy that works best right now is ad hoc distribution +via social connections. +But even if we come up with brilliant new distribution mechanisms, we +simply need more addresses to work with. +How can we get them? +Here are five strategies. + +\paragraph{Approach one:} + +Make it easy to become a bridge using the Vidalia interface. +This approach was our first try at getting more bridges: click on +``Sharing'', then ``Help censored users reach the Tor network''. +Easy to do, and lots of people have done it. +But lots here is thousands, not hundreds of thousands. +Nobody knows that they should click it or why. + +\paragraph{Approach two:} + +Bridge-by-default bundles. +People who want to help out can now simply download and run our +bridge-by-default% +\footnote{\url{https://blog.torproject.org/blog/windows-bridge-default-bundle}} +bundle, and poof they're a bridge. +There's a lot of flexibility here. +For example, we could provide a customized bridge-by-default bundle for a +Chinese human rights NGO that publishes your bridge address directly to +them; then they give out the bridge addresses from their volunteers +through their own social network. +I think this strategy will be most effective when combined with targeted +advocacy, that is, after a given community is convinced that they want to +help and want to know how they can best help. + +\paragraph{Approach three:} + +Fast, stable, reachable Tor clients auto-promote themselves. +Tor clients can monitor their own stability, performance, and +reachability, and the best clients can opt to become bridges +automatically. +We can tune the thresholds (``how fast, how stable'') in the directory +consensus, to tailor how many clients promote themselves in response to +demand. +Read the proposal% +\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/175-automatic-node-promotion.txt}} +for more details. +In theory this approach could provide us with many tens of thousands of +bridges in a wide array of locations---and we're drawing from a pool of +people who already have other reasons to download Tor. +Downsides include a) there's quite a bit of coding work remaining before +we can launch it, b) there are certainly situations where we shouldn't +turn a Tor user into a bridge, which means we need to sort out some smart +way to interact with the user and get permission, and c) these users don't +actually change addresses as often as we might want, so we're still in the +``gets lots of bridges'' mindset rather than the ``increase the rate of +new bridge addresses'' mindset. + +\paragraph{Approach four:} + +Redirect entire address blocks into the Tor network. +There's no reason the bridge and its address need to run in the same +location, and it's really addresses that are the critical resource here. +If we get our friends at various ISPs to redirect some spare /16 networks +our way, we'd have a lot more addresses to play with, and more +importantly, we can control the churn of these addresses. +Past experience with some censors shows that they work hard to unblock +addresses that are no longer acting as proxies. +If we light up only a tiny fraction of the IP space at a time, how long +until they block all of it? +How much does the presence of other services on the address block make +them hesitate? +I want to find out. +The end game here is for Comcast to give us a few random IP addresses from +each of their /24 networks. +All the code on the Tor bridge side already works here, so the next steps +are a) figure out how to teach an ISP's router to redirect some of its +address space to us, and then b) sign up some people who have a good +social network of users who need bridges, and get them to play that arms +race more actively. + +\paragraph{Approach five:} + +More generic proxies. +Originally I had thought that the extra layer of encryption and +authentication from a bridge was a crucial piece of keeping the user (call +her Alice) safe. +But I'm increasingly thinking that the security properties she gets from a +Tor circuit (anonymity/privacy) can be separated from the security +properties she gets from the bridge (reachability, and optionally +obfuscation). +That is, as long as Alice can fetch the signed Tor network consensus% +\footnote{\url{https://torproject.org/docs/faq\#KeyManagement}} +and verify the keys of each of the public relays in her path, it doesn't +matter so much that the bridge gets to see her traffic. +Attacks by the bridge are no more effective than attacks by a local +network adversary, which by design is not much. +Now, this conclusion is premature---adding a bridge into the picture means +there's a new observation point in addition to the local network +adversary, and observation points are exactly what the attacker needs to +correlate traffic flows and break Tor's anonymity. +But on the flip side, right now bridges already get to act as these +observational points, and the extra layer of encryption they add doesn't +seem to help Alice any. +So it's too early to say% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/2764}} +that a socks or https proxy is just as safe as a bridge (assuming you use +a full Tor circuit in either case), but I'm optimistic that these more +generic proxies have a role to play. + +If we go this route, then rather than needing volunteers to run a whole +Tor (which is especially cumbersome because it needs libraries like +OpenSSL), people could run socks proxies on a much broader set of +platforms. +For example, they should be easy to add into Orbot% +\footnote{\url{https://www.torproject.org/docs/android}} +(our Tor package for Android) or into Seattle% +\footnote{\url{https://seattle.cs.washington.edu/html/}} +(an overlay network by UW researchers that restricts applications to a +safe subset of Python). +We could even imagine setting up a website where volunteers visit a given +page and it runs a Flash or Java applet socks proxy, lending their address +to the bridge pool while their browser is open. +There are some gotchas to work through, such as a) needing to sign the +applets so they have the required network permissions, b) figuring out how +to get around the fact that it seems hard to allow connections from the +Internet to a flash plugin, and c) needing to program the socks proxy with +a Tor bridge or relay address so the user doesn't have to ask for it +(after all, socks handshakes are unencrypted and it wouldn't do to let the +adversary watch Alice ask for an IP address that's known to be associated +with Tor). +This 'flash proxy' idea was developed in collaboration with Dan Boneh at +Stanford, and they are currently designing and building it---stay tuned. + +\end{document} + diff --git a/2011/strategies-getting-more-bridge-addresses/tortechrep.cls b/2011/strategies-getting-more-bridge-addresses/tortechrep.cls new file mode 120000 index 0000000..4c24db2 --- /dev/null +++ b/2011/strategies-getting-more-bridge-addresses/tortechrep.cls @@ -0,0 +1 @@ +../../tortechrep.cls \ No newline at end of file

1 0

[tech-reports/master] Add measuring-safety-tor-network blog post.
by karsten＠torproject.org 30 Aug '12

30 Aug '12

commit e9ac86277a7f14a324fcd1fd0c44cc98d74c8c75 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 8 20:17:09 2012 +0200 Add measuring-safety-tor-network blog post. --- 2011/measuring-safety-tor-network/.gitignore | 3 + .../measuring-safety-tor-network.bib | 39 +++ .../measuring-safety-tor-network.tex | 261 ++++++++++++++++++++ 2011/measuring-safety-tor-network/tortechrep.cls | 1 + 4 files changed, 304 insertions(+), 0 deletions(-) diff --git a/2011/measuring-safety-tor-network/.gitignore b/2011/measuring-safety-tor-network/.gitignore new file mode 100644 index 0000000..d319e47 --- /dev/null +++ b/2011/measuring-safety-tor-network/.gitignore @@ -0,0 +1,3 @@ +measuring-safety-tor-network.pdf +measuring-safety-tor-network-2011-02-06.pdf + diff --git a/2011/measuring-safety-tor-network/measuring-safety-tor-network.bib b/2011/measuring-safety-tor-network/measuring-safety-tor-network.bib new file mode 100644 index 0000000..85e375b --- /dev/null +++ b/2011/measuring-safety-tor-network/measuring-safety-tor-network.bib @@ -0,0 +1,39 @@ +@inproceedings{feamster:wpes2004, + title = {Location Diversity in Anonymity Networks}, + author = {Nick Feamster and Roger Dingledine}, + booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES + 2004)}}, + year = {2004}, + month = {October}, + address = {Washington, DC, USA}, + note = {\url{http://freehaven.net/anonbib/#feamster:wpes2004}}, +} + +@inproceedings{EdmanS09, + title = {{AS}-awareness in {Tor} path selection}, + author = {Matthew Edman and Paul F. Syverson}, + booktitle = {Proceedings of the 2009 ACM Conference on Computer and Communications + Security, CCS 2009, Chicago, Illinois, USA, November 9-13, 2009}, + year = {2009}, + pages = {380--389}, + editor = {Ehab Al-Shaer and Somesh Jha and Angelos D. Keromytis}, + publisher = {ACM}, + isbn = {978-1-60558-894-0}, + note = {\url{http://freehaven.net/anonbib/#DBLP:conf:ccs:EdmanS09}}, +} + +@inproceedings{SherrBL09, + title = {Scalable Link-Based Relay Selection for Anonymous Routing}, + author = {Micah Sherr and Matt Blaze and Boon Thau Loo}, + booktitle = {Proceedings of Privacy Enhancing Technologies, 9th International Symposium, + PETS 2009, Seattle, WA, USA, August 5-7, 2009}, + volume = {5672}, + year = {2009}, + pages = {73--93}, + editor = {Ian Goldberg and Mikhail J. Atallah}, + publisher = {Springer}, + series = {Lecture Notes in Computer Science}, + isbn = {978-3-642-03167-0}, + note = {\url{http://freehaven.net/anonbib/#DBLP:conf:pet:SherrBL09}}, +} + diff --git a/2011/measuring-safety-tor-network/measuring-safety-tor-network.tex b/2011/measuring-safety-tor-network/measuring-safety-tor-network.tex new file mode 100644 index 0000000..e053636 --- /dev/null +++ b/2011/measuring-safety-tor-network/measuring-safety-tor-network.tex @@ -0,0 +1,261 @@ +\documentclass{tortechrep} +\usepackage{enumerate} +\begin{document} + +\author{Roger Dingledine} +\contact{arma(a)torproject.org} +\reportid{2011-02-001} +\date{February 6, 2011} +\title{Measuring the safety of the Tor network} +\maketitle + +\setcounter{section}{-1} +\section{Introduction} + +We need a better understanding of how much anonymity the Tor network +provides against a partial network adversary who observes and/or operates +some of the network. +Specifically, we want to understand the chances that this class of +adversary can observe a user's traffic coming into the network and also +the corresponding traffic exiting the network. + +Most of our graphs historically have looked at the total number of relays +over time. +But this simple scalar doesn't take into account relay capacity, exit +policies, geographic or network location, etc. + +One concrete problem from this bad metric is that when many new relays +show up (e.g.\ due to a political event% +\footnote{\url{https://blog.torproject.org/files/relays-diff-2011-01-28.png}}), +we really don't have any insight about how the diversity of the new relays +compares to the rest of the network. +The simplistic metric also gets misused in academic research papers to +produce misleading results like ``I can sign up 2\% of the Tor relays and +capture 50\% of the paths,'' when what they mean is ``I can provide half +the capacity in the Tor network and capture half the paths.'' + +There are four parts to this research problem. +First, we need a broad array of metrics that reflect various instances of +our partial network adversary. +Second, we need to understand for each metric how stable it is +(sensitivity analysis) and what changes in the Tor network would +efficiently improve (or harm) it. +Third, we should make the calculations as realistic as possible based on +actual Tor client behavior. +Last, we need a better infrastructure for comparing the safety impact from +alternate design scenarios, for example different path selection or route +balancing algorithms. + +We'd love to work with you% +\footnote{\url{https://www.torproject.org/research}} +to help answer these questions. + +\section{Part one: new metrics} + +The network graphs% +\footnote{\url{https://metrics.torproject.org/network.html}} +on our metrics site show the number of relays and advertised capacity over +time. +More importantly, we've archived all the relay descriptors and network +consensus documents% +\footnote{\url{https://metrics.torproject.org/data.html\#relaydesc}} +going back to 2004. +So now we can ask some questions to better capture the safety of the +network over time. + +What is the entropy of path selection over time? +When we add really fast relays, the capacity of the network goes up but +the safety of the network can go down because it gets less balanced. +We can start with a simple approximation of a Tor client's path selection +behavior---e.g., choose the first hop randomly weighted by bandwidth, and +choose the final hop randomly weighted by bandwidth from among the nodes +that can exit to port 80. +I'm particularly interested in the entropy of the first hop and the third +hop, since those are the key points for the anonymity Tor provides against +a partial network adversary. +Calculating entropy on the probability distribution of possible first hops +is easy (as is last hops), and it's worth looking at these individual +components so we have better intuition about where our anonymity comes +from. +Then we'd also want to look at the unified metric (probability +distribution of first cross last), which in the simple approximation is +the sum of the two entropies. + +Then we should do the same entropy calculations, but lumping relays +together based on various shared characteristics. +For example, country diversity: what's the entropy of path selection over +time when you treat all relays in Germany as one big relay, all relays in +France as one big relay, etc? +How about autonomous system (AS)% +\footnote{\url{http://en.wikipedia.org/wiki/Autonomous\_system\_\%28Internet\%29}} +based diversity, where all the relays in AT\&T's network are lumped +together? + +Another angle to evaluate is what expected fraction of paths have the +first and last hop in the same country, or the same AS, or the same city, +or the same continent. +What expected fraction of paths cross at least one ocean? +How about looking at the AS-level paths \emph{between} relays, like the +research from Feamster \cite{feamster:wpes2004} or Edman \cite{EdmanS09}? +What user locations are more safe or less safe in the above metrics? + +It's plausible to imagine we can also gain some intuition when looking at +the \emph{possible diversity} rather than the entropy. +How many ASes or countries total are represented in the network at a given +time? + +The goal here isn't to come up with the one true metric for summarizing +Tor's safety. +Rather, we need to recognize that there are many threat models to consider +at once, so we need many different views into what types of safety the +network can offer. + +\section{Part two: how robust are these metrics?} + +For each of the above metrics, how stable are they when you add or remove +a few relays? +Are certain relays critical to the safety of the Tor network? +One way to look at this question is to graph the fall-off of safety as you +remove relays from the network, in one case choosing victims randomly and +in another choosing them to optimally harm the network. +In the latter case, I expect it will look pretty dire. +Then look at the same scenario, but now look at the safety of the network +as you remove \emph{capacity} from the network. +For example, consider that the adversary's cost of removing a relay is +equal to its capacity. +Then explore these attacks again, but rather than looking at attacking +individual relays look at attacks on ASes, countries, or continents. + +Then look at the robustness over time: is an adversary that can knock out +X\% of the capacity in the network (for various values of X) getting more +or less influential as the network grows? +How about an adversary who can knock out an absolute capacity of K bytes +for various values of K? + +From the other direction, are there certain geographic or network +locations where adding relays with a given capacity will most influence +your safety metrics? +This influence could be positive (``where should I put my relay to best +help the Tor network?'') or negative (``where should I put my relay to +best attack users?''). + +Is there any relationship between the rate of new relay arrival +(e.g.\ during political events or after popular conferences) and the level +of diversity of these relays? + +\section{Part three: how good was the simple approximation?} + +While the above calculations assume a simplified path selection model, the +reality% +\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/path-spec.txt}} +is more complex. +Clients avoid using more than one relay from a given ``/16'' network or +family% +\footnote{\url{https://www.torproject.org/docs/faq\#ManyRelays}} +in their paths. +They only use relays with the Guard flag% +\footnote{\url{https://www.torproject.org/docs/faq\#EntryGuards}}% +$^{,}$% +\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt}} +for their first hop. +They read weighting parameters from the consensus and use them to avoid +Guard-flagged nodes for positions other than the first hop and avoid +Exit-flagged nodes for positions other than the last hop, in proportion to +how much capacity is available in each category. +They track how long it takes them to build circuits, and preemptively +discard the slowest 20\% of their paths. + +Accounting for all of these behaviors (especially the last one) will be +hard, and you'll want to work closely with the Tor developers to make sure +you're moving in the right direction. +But even if you don't handle all of them, having a more realistic sense of +how clients behave should allow you to better capture the safety in the +live Tor network. +If you want extra feedback, you can compare your path selection +predictions with paths that Tor chooses in practice% +\footnote{\url{https://metrics.torproject.org/data/moria-50kb.extradata}} +(full data here% +\footnote{\url{https://metrics.torproject.org/data.html\#performance}}). + +We should rerun the above experiments with the more accurate client +behavior, and see if any of the results change substantially, and if so, +why. +These changes are great places to recognize and reconsider tradeoffs +between what we should do for maximum safety according to these metrics vs +what we should do to optimize other metrics like performance and +vulnerability to other attacks. +Some of these differences are intentional; for example, we don't give the +Guard flag to every relay because we want to reduce the churn of entry +guards. +But others are due to design mistakes; for example, we are probably not +giving the Guard flag out as broadly as we should, and I imagine that +really hurts the network's safety. + +How far away is the ``optimal'' approximation curve you produced in part +one from the ``in practice'' curve here? +How does the divergence from the optimal look over time? +That is, were we at 50\% of optimal back in 2007, but now we're only at +20\%? + +\section{Part four: consider alternate designs} + +Once we've looked at how safe the Tor network has been over time for our +broad array of metrics, we should do experiments to evaluate alternate +network designs. + +Examples include: + +\begin{enumerate}[A)] + +\item If we give out Guard flags according to some other algorithm, how much safety can we get back? + +\item In Tor 0.2.1.x we started load balancing based on active bandwidth +measurements,% +\footnote{\url{https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.BwAuthorities}} +so we use the bandwidth weights in the network consensus rather than the +weights in each relay descriptor. +We know that change improved performance,% +\footnote{\url{https://metrics.torproject.org/performance.html?graph=torperf&start=2009-08-01&end=2009-10-01\#torperf}} +but at what cost to safety? + +\item What happens to the network diversity if we put a low cap% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/2286}} +on the bandwidth weighting of any node that hasn't been assigned a +measurement by the bandwidth authorities yet, to protect against relays +that lie about their bandwidth? +If there's no real effect, we should do it; but if there's a large effect, +we should find a better plan. + +\item If we move forward with our plans to discard all relays under a +given bandwidth capacity,% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/1854}} +how will various choices of bandwidth threshold impact the network's +safety? + +\item How about if we discard the X\% of paths with the highest expected +latency, as suggested by Stephen Rollyson?% +\footnote{\url{http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf}} + +\item What if some Tor users choose their paths to optimize a different +network property (like latency or jitter), as suggested by Micah Sherr +\cite{SherrBL09}? +The infrastructure you've built to measure diversity here should apply +there too. + +\item If only a given fraction of exit relays support IPv6, how much does +it reduce your anonymity to be going to an IPv6-only destination? + +\end{enumerate} + +We've put a lot of effort in the past year into understanding how to +improve Tor's performance,% +\footnote{\url{https://blog.torproject.org/blog/why-tor-is-slow}} +but many of these design changes involve trading off safety for +performance, and we still have very little understanding about how much +safety Tor offers in the first place. +Please help! + +\bibliography{measuring-safety-tor-network} + +\end{document} + diff --git a/2011/measuring-safety-tor-network/tortechrep.cls b/2011/measuring-safety-tor-network/tortechrep.cls new file mode 120000 index 0000000..4c24db2 --- /dev/null +++ b/2011/measuring-safety-tor-network/tortechrep.cls @@ -0,0 +1 @@ +../../tortechrep.cls \ No newline at end of file

1 0

[tech-reports/master] Add ten-ways-discover-tor-bridges blog post.
by karsten＠torproject.org 30 Aug '12

30 Aug '12

commit 2ec1866d81fb97628f203777dc0b1f377cec2cf1 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 8 20:20:14 2012 +0200 Add ten-ways-discover-tor-bridges blog post. --- 2011/ten-ways-discover-tor-bridges/.gitignore | 3 + .../ten-ways-discover-tor-bridges.bib | 102 ++++++ .../ten-ways-discover-tor-bridges.tex | 351 ++++++++++++++++++++ 2011/ten-ways-discover-tor-bridges/tortechrep.cls | 1 + 4 files changed, 457 insertions(+), 0 deletions(-) diff --git a/2011/ten-ways-discover-tor-bridges/.gitignore b/2011/ten-ways-discover-tor-bridges/.gitignore new file mode 100644 index 0000000..68511a0 --- /dev/null +++ b/2011/ten-ways-discover-tor-bridges/.gitignore @@ -0,0 +1,3 @@ +ten-ways-discover-tor-bridges.pdf +ten-ways-discover-tor-bridges-2011-10-31.pdf + diff --git a/2011/ten-ways-discover-tor-bridges/ten-ways-discover-tor-bridges.bib b/2011/ten-ways-discover-tor-bridges/ten-ways-discover-tor-bridges.bib new file mode 100644 index 0000000..ca69d6e --- /dev/null +++ b/2011/ten-ways-discover-tor-bridges/ten-ways-discover-tor-bridges.bib @@ -0,0 +1,102 @@ +@techreport{dingledine2011strategies, + title = {Strategies for getting more bridge addresses}, + author = {Roger Dingledine}, + institution = {The Tor Project}, + year = {2011}, + month = {May}, + number = {2011-05-001}, + note = {\url{https://research.torproject.org/techreports/strategies-getting-more-bridge-addresses-2011-05-13.pdf}}, +} + +@inproceedings{babel, + title = {Mixing {E}-mail With {B}abel}, + author = {Ceki G\"ulc\"u and Gene Tsudik}, + booktitle = {Proceedings of the Network and Distributed Security Symposium - {NDSS} '96}, + year = {1996}, + month = {February}, + pages = {2--16}, + publisher = {IEEE}, + note = {\url{http://freehaven.net/anonbib/#babel}}, +} + +@inproceedings{VassermanJTHK09, + title = {Membership-concealing overlay networks}, + author = {Eugene Y. Vasserman and Rob Jansen and James Tyra and Nicholas Hopper and + Yongdae Kim}, + booktitle = {Proceedings of the 2009 ACM Conference on Computer and Communications + Security, CCS 2009, Chicago, Illinois, USA, November 9-13, 2009}, + year = {2009}, + pages = {390--399}, + editor = {Ehab Al-Shaer and Somesh Jha and Angelos D. Keromytis}, + publisher = {ACM}, + isbn = {978-1-60558-894-0}, + note = {\url{http://freehaven.net/anonbib/#DBLP:conf:ccs:VassermanJTHK09}}, +} + +@inproceedings{wpes09-bridge-attack, + title = {{On the risks of serving whenever you surf: Vulnerabilities in Tor's blocking + resistance design}}, + author = {Jon McLachlan and Nicholas Hopper}, + booktitle = {Proceedings of the Workshop on Privacy in the Electronic Society (WPES + 2009)}, + year = {2009}, + month = {November}, + location = {Chicago, IL, USA}, + publisher = {ACM}, + note = {\url{http://freehaven.net/anonbib/#wpes09-bridge-attack}}, +} + +@techreport{tor-blocking, + title = {Design of a blocking-resistant anonymity system}, + author = {Roger Dingledine and Nick Mathewson}, + institution = {The Tor Project}, + number = {2006-1}, + year = {2006}, + month = {November}, + note = {\url{http://freehaven.net/anonbib/#tor-blocking}}, +} + +@inproceedings{wpes11-bridgespa, + title = {BridgeSPA: Improving {Tor} Bridges with Single Packet Authorization}, + author = {Rob Smits and Divam Jain and Sarah Pidcock and Ian Goldberg and Urs + Hengartner}, + booktitle = {Proceedings of the Workshop on Privacy in the Electronic Society (WPES + 2011)}, + year = {2011}, + month = {October}, + location = {Chicago, IL, USA}, + publisher = {ACM}, + note = {\url{http://freehaven.net/anonbib/#wpes11-bridgespa}}, +} + +@inproceedings{usenix11-telex, + title = {Telex: Anticensorship in the Network Infrastructure}, + author = {Eric Wustrow and Scott Wolchok and Ian Goldberg and J. Alex Halderman}, + booktitle = {Proceedings of the 20th USENIX Security Symposium}, + year = {2011}, + month = {August}, + note = {\url{http://freehaven.net/anonbib/#usenix11-telex}}, +} + +@inproceedings{foci11-decoy, + title = {Decoy Routing: Toward Unblockable Internet Communication}, + author = {Josh Karlin and Daniel Ellard and Alden W. Jackson and Christine E. Jones and + Greg Lauer and David P. Mankins and W. Timothy Strayer}, + booktitle = {Proceedings of the USENIX Workshop on Free and Open Communications on the + Internet (FOCI 2011)}, + year = {2011}, + month = {August}, + note = {\url{http://freehaven.net/anonbib/#foci11-decoy}}, +} + +@inproceedings{ccs2011-cirripede, + title = {Cirripede: Circumvention Infrastructure using Router Redirection with Plausible + Deniability}, + author = {Amir Houmansadr and Giang T. K. Nguyen and Matthew Caesar and Nikita Borisov}, + booktitle = {Proceedings of the 18th ACM conference on Computer and Communications + Security (CCS 2011)}, + year = {2011}, + month = {October}, + note = {\url{http://freehaven.net/anonbib/#ccs2011-cirripede}}, +} + diff --git a/2011/ten-ways-discover-tor-bridges/ten-ways-discover-tor-bridges.tex b/2011/ten-ways-discover-tor-bridges/ten-ways-discover-tor-bridges.tex new file mode 100644 index 0000000..dbdc8db --- /dev/null +++ b/2011/ten-ways-discover-tor-bridges/ten-ways-discover-tor-bridges.tex @@ -0,0 +1,351 @@ +\documentclass{tortechrep} +\begin{document} + +\author{Roger Dingledine} +\contact{arma(a)torproject.org} +\reportid{2011-10-002} +\date{October 31, 2011} +\title{Ten ways to discover Tor bridges} +\maketitle + +\setcounter{section}{-1} +\section{Introduction} + +While we're exploring smarter ways of getting more bridge addresses +\cite{dingledine2011strategies}, and while the bridge arms race hasn't +heated up yet in most countries (or has surpassed the number of bridges we +have, in the case of China), it's the perfect time to take stock of bridge +address enumeration attacks and how well we can defend against them. + +For background, bridge relays% +\footnote{\url{https://www.torproject.org/docs/bridges}} +(aka bridges) are Tor relays that aren't listed in the main Tor directory. +So even if an attacker blocks all the public relays, they still need to +block all these ``private'' or ``dark'' relays too. + +Here are ten classes of attacks to discover bridges, examples of them +we've seen or worry about in practice, and some ideas for how to resolve +or mitigate each issue. +If you're looking for a research project, please grab one and start +investigating! + +\section{Overwhelm the public address distribution strategies} + +China broke our https bridge distribution strategy% +\footnote{\url{https://bridges.torproject.org/}} +in September 2009 by just pretending to be enough legitimate users from +enough different subnets on the Internet. +They broke the Gmail bridge distribution strategy% +\footnote{\url{https://www.torproject.org/docs/bridges\#FindingMore}} +in March 2010. +These were easy to break because we don't have enough addresses relative +to the size of the attacker (at this moment we're giving out 176 bridges +by https and 201 bridges by Gmail, leaving us 165 to give out through +other means like social networks), but it's not just a question of scale: +we need better strategies that require attackers to do more or harder work +than legitimate users. + +\section{Run a non-guard non-exit relay and look for connections from +non-relays} +\label{sec:run-non-guard-non-exit-relay} + +Normal clients use guard nodes% +\footnote{\url{https://www.torproject.org/docs/faq\#EntryGuards}} +for the first hop of their circuits to protect them from long-term +profiling attacks; but we chose to have bridge users use their bridge as a +replacement for the guard hop, so we don't force them onto four-hop paths +which would be less fun to use. +As a result, if you run a relay that doesn't have the Guard flag, the only +Tors who end up building circuits through you are relays (which you can +identify from the public consensus) and bridges. + +This attack has been floating around for a while, and is documented for +example in Zhen Ling et al's Extensive Analysis and Large-Scale Empirical +Evaluation of Tor Bridge Discovery% +\footnote{\url{http://www.cs.uml.edu/~xinwenfu/paper/Bridge.pdf}} +paper. + +The defense we plan is to make circuits through bridges use guards too. +The naive way to do it would be for the client to choose a set of guards +as her possible next hops after the bridge; but then each new client using +the bridge increasingly exposures the bridge. +The better approach is to make use of Tor's loose source routing feature +to let the bridge itself choose the guards that all of the circuits it +handles will use: that is, transparently layer an extra one-hop circuit +inside the client's circuit. +Those familiar with Babel's design \cite{babel} will recognize this trick +by the name ``inter-mix detours''. + +Using a layer of guards after the bridge has two features: first, it +completely removes the ``bridges directly touch non-guards'' issue, +turning the attack from a deterministic one to a probabilistic one. +Second, it reduces the exposure of the bridge to the rest of the network, +since only a small set of relays will ever see a direct connection from +it. +The tradeoff, alas, is worse performance for bridge users. See proposal +188% +\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/188-bridge-guards.txt}} +for details.% +\footnote{A friendly researcher pointed out to me that another solution +here is to run the bridge as multi-homed, meaning the address that the +relay sees isn't the address that the censor should block. +That solution also helps resolve issues 3-5!} + +\section{Run a guard relay and look for protocol differences} +\label{sec:run-a-guard} + +Bridges are supposed to behave like relays with respect to the users using +them, but like clients with respect to the relays they make connections +to. +Any slip-ups we introduce where the bridge acts like a relay with respect +to the next hop are ways the next hop can distinguish it. +Recent examples include ``bridges fetched directory information like +relays rather than like clients''% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/4115}}, +``bridges didn't use a CREATE\_FAST cell for the first hop of their own +circuits like clients would have''% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/4124}}, +``bridges didn't reject CREATE and CREATE\_FAST cells on connections they +had initiated like clients would have''% +\footnote{\url{https://lists.torproject.org/pipermail/tor-commits/2011-October/036726.html}}, +and ``bridges distinguish themselves in their NETINFO cell''% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/4348}}. + +There's no way that's the end of them. +We could sure use some help auditing the design and code for similar +issues. + +\section{Run a guard relay and do timing analysis} + +Even if we fix issues \ref{sec:run-non-guard-non-exit-relay} and +\ref{sec:run-a-guard}, it may still be possible for a guard relay to look +at the ``clients'' that are connecting to it, and figure out based on +latency that some of the circuits from those clients look like they're two +hops away rather than one hop away. + +I bet there are active tricks to improve the attack accuracy. +For example, the relay could watch round-trip latency from the circuit +originator (seeing packets go towards Alice, and seeing how long until a +packet shows up in response), and comparing that latency to what he sees +when probing the previous hop with some cell that will get an immediate +response rather than going all the way to Alice. +Removing all the ways of probing round-trip latency to an adjacent Tor +relay (either in-protocol or out-of-protocol) is a battle we're not going +to win. + +The research question remains though: how hard is this attack in practice? +It's going to come down to statistics, which means it will be a game of +driving up the false positives. +It's hard to know how best to solve it until somebody does the engineering +work for the attack. + +If the attack turns out to work well (and I expect it will), the ``bridges +use guards'' design will limit the damage from the attack. + +\section{Run a relay and try connecting back to likely ports on each +client that connects to you} +\label{sec:connect-back} + +Many bridges listen for incoming client connections on port 443 or 9001. +The adversary can run a relay and actively portscan each client that +connects, to see which ones are running services that speak the Tor +protocol. +This attack was published by Eugene Vasserman \cite{VassermanJTHK09} and +by Jon McLachlan \cite{wpes09-bridge-attack}, both in 2009. + +The ``bridges use guards'' design partially resolves this attack as well, +since we limit the exposure of the bridge to a small group of relays that +probably could have done some other above attacks as well. + +But it does not wholly resolve the concern: clients (and therefore also +bridges) don't use their entry guards for directory fetches at present. +So while the bridge won't build circuits through the relay it fetches +directory information from, it will still reveal its existence. +That's another reason to move forward with the ``directory guard''% +\footnote{\url{https://lists.torproject.org/pipermail/tor-relays/2010-April/000112.html}} +design. + +\section{Scan the Internet for services that talk the Tor protocol} +\label{sec:scan-the-internet} + +Even if we successfully hide the bridges behind guards, the adversary can +still blindly scan for them and pretend to be a client. +To make it more practical, he could focus on scanning likely networks, or +near other bridges he's discovered. +We called this topic ``scanning resistance'' in our original bridge design +paper \cite{tor-blocking}. + +There's a particularly insidious combination of \ref{sec:connect-back} and +\ref{sec:scan-the-internet} if you're a government-scale adversary: watch +your government firewall for SSL flows (since Tor tries to blend in with +SSL traffic), and do active followup probing to every destination you see. +Whitelist sites you've already checked if you want to trade efficiency for +precision. +This scale of attack requires some serious engineering work for a large +country, but early indications% +\footnote{\url{https://trac.torproject.org/projects/tor/ticket/4185}} +are that China might be investigating exactly this approach. + +The answer here is to give the bridge user some secret when she learns the +bridge address, and require her to prove knowledge of that secret before +the bridge will admit to knowing the Tor protocol. +For example, we could imagine running an Apache SSL webserver with a +pass-through module% +\footnote{\url{http://dl.dropbox.com/u/37735/index.html}} +that tunnels your traffic to the Tor relay once she's presented the right +password. +Or Tor could handle that authentication itself% +\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/187-allow-client-auth.txt}}. +BridgeSPA: Improving Tor Bridges with Single Packet Authorization +\cite{wpes11-bridgespa} offers an SPA-style approach, with the drawbacks +of requiring root on both sides and being OS-specific. + +Another avenue to explore is putting some of the bridge addresses behind a +service like Telex \cite{usenix11-telex}, Decoy Routing +\cite{foci11-decoy}, or Cirripede \cite{ccs2011-cirripede}. +These designs let users privately tag a flow (e.g.\ an SSL handshake) in +such a way that tagged flows are diverted to a Tor bridge while untagged +flows continue as normal. +So now we could deploy a vanilla Apache in one place and a vanilla Tor +bridge in another, and not have to modify either of them. +The Tor client bundle would need an extra piece of software though, and +there are still some engineering and deployment details to be worked out. + +\section{Break into the Tor Project infrastructure} + +The bridge directory authority% +\footnote{\url{https://svn.torproject.org/svn/projects/design-paper/blocking.html\#tth_sEc5.2}} +aggregates the list of bridges and periodically sends it to the bridgedb +service% +\footnote{\url{https://gitweb.torproject.org/bridgedb.git/tree}} +so it can parcel addresses out by its various distribution strategies. +Breaking into either of these services would give you the list of bridges. + +We can imagine some design changes to make the risk less bad. +For one, people can already run bridges that don't publish to the bridge +directory authority (and then distribute their addresses themselves). +Second, I had a nice chat with a Chinese NGO recently who wants to set up +a bridge directory authority of their own, and distribute custom Vidalia +bridge bundles to their members that are configured to publish their +bridge addresses to this alternate bridge directory authority. +A third option is to decentralize the bridge authority and bridgedb +services, such that each component only learns about a fraction of the +total bridge population---that design quickly gets messy though in terms +of engineering and in terms of analyzing its security against various +attacks. + +\section{Just watch the bridge authority's reachability tests} + +You don't actually need to break in to the bridge authority. +Instead, you can just monitor its network connection: it will periodically +test reachability of each bridge it knows, in order to let the bridgedb +service know which addresses to give out. + +We could do these reachability tests through Tor, so watching the bridge +authority doesn't tell you anything about what it's testing. +But that just shifts the risk onto the rest of the relays, such that an +adversary who runs or monitors a sample of relays gets to learn about a +corresponding sample of bridges. + +One option is to decentralize the testing such that monitoring a single +location doesn't give you the whole bridge list. +But how exactly to distribute it, and onto what, is messy from both the +operational and research angles. +Another option would be for the bridges themselves to ramp up the +frequency of their reachability tests (they currently self-test for +reachability before publishing, to give quick feedback to their operator +if they're misconfigured). +Then the bridges can just anonymously publish an authenticated ``still +here'' message once an hour, so (assuming they all tell the truth) the +bridge authority never has to do any testing. +But this self-testing also allows an enumeration attack, since we build a +circuit to a random relay and then try to extend back to our bridge +address! +Maybe bridges should be asking their guards to do the self-testing---once +they have guards, that is? + +These questions are related to the question of learning whether a bridge +has been blocked in a given country% +\footnote{\url{https://svn.torproject.org/svn/projects/design-paper/blocking.html\#subsec:geoip}}. +More on that in a future report. + +\section{Watch your firewall and DPI for Tor flows} + +While the above attacks have to do with recognizing or inducing +bridge-specific behavior, another class of attacks is just to buy some +fancy Deep Packet Inspection gear and have it look for, say, +characteristics of the SSL certificates or handshakes that make Tor flows +stand out from ``normal'' SSL flows. +Iran has used this strategy% +\footnote{\url{https://blog.torproject.org/blog/iran-blocks-tor-tor-releases-same-day-fix}} +to block Tor twice, and it lets them block bridges for free. +The attack is most effective if you have a large and diverse population of +Tor users behind your firewall, since you'll only be able to learn about +bridges that your users try to use. + +We can fix the issue by making Tor's handshake more like a normal SSL +handshake% +\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/179-TLS-cert-and-parameter-normalization.txt}}, +but I wonder if that's really a battle we can ever win. +The better answer is to encourage a proliferation of modular Tor +transports% +\footnote{\url{https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt}}, +like obfsproxy% +\footnote{\url{https://gitweb.torproject.org/obfsproxy.git/blob/HEAD:/doc/tor-obfs-howto.txt}}, +and get the rest of the research community interested in designing +tool-neutral transports that blend in better. + +\section{Zig-zag between bridges and users} + +Start with a set of known bridge addresses. +Watch your firewall to see who connects to those bridges. +Then watch those users, and see what other addresses they connect to. +Wash, rinse, repeat. + +As above, this attack only works well when you have a large population of +Tor users behind your firewall. +It also requires some more engineering work to be able to trace source +addresses in addition to destination addresses. +But I'd be surprised if some major government firewalls don't have this +capability already. + +The solution here probably involves partitioning bridge addresses into +cells% +\footnote{\url{http://en.wikipedia.org/wiki/Clandestine_cell_system}}, +such that zig-zagging from users to bridges only gives you a bounded set +of bridges (and a bounded set of users, for that matter). +That approach will require some changes in our bridgedb design% +\footnote{\url{https://gitweb.torproject.org/bridgedb.git/blob/HEAD:/bridge-db-spec.txt}} +though. +Currently when a user requests some bridge addresses, bridgedb maps the +user's ``address'' (IP address, gmail account name, or whatever) into a +point in the keyspace (using consistent hashing% +\footnote{\url{http://en.wikipedia.org/wiki/Consistent_hashing}}), +and the answers are the k successors of that point in the ring (using DHT% +\footnote{\url{http://en.wikipedia.org/wiki/Chord_\%28DHT\%29}} +terminology). + +Dan Boneh suggested an alternate approach where we do keyed hashes% +\footnote{\url{http://en.wikipedia.org/wiki/HMAC}} +of the user's address and all the bridge fingerprints, and return all +bridges whose hashed fingerprints match the user's hash in the first b +bits. +The result is that users would tend to get clustered by the bridges they +know. +That feature limits the damage from the zig-zag attack, but does it +increase the risks in some distribution strategies? +I already worry that bridge distribution strategies based on social +networks will result in clusters of socially related users using the same +bridges, meaning the attacker can reconstruct the social network. +If we isolate socially related users in the same partition, do we magnify +that problem? +This approach also needs more research work to make it scale such that we +can always return about k results, even as the address pool grows, and +without reintroducing zig-zag vulnerabilities. + +\section{\dots What did I miss?} + +\bibliography{ten-ways-discover-tor-bridges} + +\end{document} + diff --git a/2011/ten-ways-discover-tor-bridges/tortechrep.cls b/2011/ten-ways-discover-tor-bridges/tortechrep.cls new file mode 120000 index 0000000..4c24db2 --- /dev/null +++ b/2011/ten-ways-discover-tor-bridges/tortechrep.cls @@ -0,0 +1 @@ +../../tortechrep.cls \ No newline at end of file

1 0

[tech-reports/master] Merge branch 'arma-blogposts'
by karsten＠torproject.org 30 Aug '12

30 Aug '12

commit 7dc54ba733261791fb9bdcad43f6f4c0c79e3fbf Merge: 4a3ac51 2ec1866 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Aug 30 09:03:57 2012 +0200 Merge branch 'arma-blogposts' 2011/better-guard-rotation-parameters/.gitignore | 3 + .../better-guard-rotation-parameters.bib | 33 ++ .../better-guard-rotation-parameters.tex | 128 +++++++ .../tortechrep.cls | 1 + 2011/five-ways-test-bridge-reachability/.gitignore | 3 + .../five-ways-test-bridge-reachability.bib | 70 ++++ .../five-ways-test-bridge-reachability.tex | 349 +++++++++++++++++++ .../tortechrep.cls | 1 + 2011/measuring-safety-tor-network/.gitignore | 3 + .../measuring-safety-tor-network.bib | 39 +++ .../measuring-safety-tor-network.tex | 261 +++++++++++++++ 2011/measuring-safety-tor-network/tortechrep.cls | 1 + .../.gitignore | 3 + .../strategies-getting-more-bridge-addresses.tex | 174 ++++++++++ .../tortechrep.cls | 1 + 2011/ten-ways-discover-tor-bridges/.gitignore | 3 + .../ten-ways-discover-tor-bridges.bib | 102 ++++++ .../ten-ways-discover-tor-bridges.tex | 351 ++++++++++++++++++++ 2011/ten-ways-discover-tor-bridges/tortechrep.cls | 1 + 19 files changed, 1527 insertions(+), 0 deletions(-)

1 0

[metrics-web/master] Tiny tweak to relay numbers by flags graph.
by karsten＠torproject.org 30 Aug '12

30 Aug '12

commit 40594c18579e75f1fb700002fa746da88aa3756b Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Aug 30 07:16:55 2012 +0200 Tiny tweak to relay numbers by flags graph. --- rserve/graphs.R | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/rserve/graphs.R b/rserve/graphs.R index 83d380d..4f99eeb 100644 --- a/rserve/graphs.R +++ b/rserve/graphs.R @@ -619,14 +619,14 @@ plot_relayflags <- function(start, end, flags, granularity, path, dpi) { "stable"), sep = ""), value = rep(NA, length(missing) * 5)), networksize) date_breaks <- date_breaks( - as.numeric(max(as.Date(networksize$date, "%Y-%m-%d")) - + as.numeric(max(as.Date(end, "%Y-%m-%d")) - min(as.Date(networksize$date, "%Y-%m-%d")))) ggplot(networksize, aes(x = as.Date(date, "%Y-%m-%d"), y = value, colour = as.factor(variable))) + geom_line(size = 1) + scale_x_date(name = paste("\nThe Tor Project - ", "https://metrics.torproject.org/", sep = ""), format = date_breaks$format, major = date_breaks$major, - minor = date_breaks$minor) + + minor = date_breaks$minor, limits = as.Date(c(start, end))) + scale_y_continuous(name = "", limits = c(0, max(networksize$value, na.rm = TRUE))) + scale_colour_manual(name = "Relay flags", values = c("#E69F00",

1 0

[compass/master] Don't list a relay as Exit if it has the BadExit flag.
by gsathya＠torproject.org 29 Aug '12

29 Aug '12

commit b2ce73eaef060f619666851dcddd65c8edd41941 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Aug 29 14:50:09 2012 +0200 Don't list a relay as Exit if it has the BadExit flag. --- compass.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/compass.py b/compass.py index 9f2b340..428812f 100755 --- a/compass.py +++ b/compass.py @@ -247,7 +247,7 @@ class RelayStats(object): group_weights = tuple(sum(x) for x in zip(group_weights, weights)) nickname = relay['nickname'] fingerprint = relay['fingerprint'] if not links else "https://atlas.torproject.org/#details/%s" % relay['fingerprint'] - if 'Exit' in set(relay['flags']): + if 'Exit' in set(relay['flags']) and not 'BadExit' in set(relay['flags']): exit = 'Exit' exits_in_group += 1 else:

1 0

[torbrowser/maint-2.3] bump recommended-versions for 2.2.38-2
by erinn＠torproject.org 29 Aug '12

29 Aug '12

commit 79c20186c24d2bf99faad2d52eacc5b7e4238ef3 Author: Erinn Clark <erinn(a)torproject.org> Date: Wed Aug 29 19:07:55 2012 +0100 bump recommended-versions for 2.2.38-2 --- build-scripts/recommended-versions | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/build-scripts/recommended-versions b/build-scripts/recommended-versions index 46c8079..ba836de 100644 --- a/build-scripts/recommended-versions +++ b/build-scripts/recommended-versions @@ -1,9 +1,9 @@ [ -"2.2.38-1-MacOS-i386", -"2.2.38-1-MacOS-x86_64", -"2.2.38-1-Windows", -"2.2.38-1-Linux-i686", -"2.2.38-1-Linux-x86_64", +"2.2.38-2-MacOS-i386", +"2.2.38-2-MacOS-x86_64", +"2.2.38-2-Windows", +"2.2.38-2-Linux-i686", +"2.2.38-2-Linux-x86_64", "2.3.20-alpha-1-MacOS-i386", "2.3.20-alpha-1-Windows", "2.3.20-alpha-1-Linux-i386",

1 0

[torbrowser/maint-2.2] bump recommended-versions for 2.2.38-2
by erinn＠torproject.org 29 Aug '12

29 Aug '12

commit 79c20186c24d2bf99faad2d52eacc5b7e4238ef3 Author: Erinn Clark <erinn(a)torproject.org> Date: Wed Aug 29 19:07:55 2012 +0100 bump recommended-versions for 2.2.38-2 --- build-scripts/recommended-versions | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/build-scripts/recommended-versions b/build-scripts/recommended-versions index 46c8079..ba836de 100644 --- a/build-scripts/recommended-versions +++ b/build-scripts/recommended-versions @@ -1,9 +1,9 @@ [ -"2.2.38-1-MacOS-i386", -"2.2.38-1-MacOS-x86_64", -"2.2.38-1-Windows", -"2.2.38-1-Linux-i686", -"2.2.38-1-Linux-x86_64", +"2.2.38-2-MacOS-i386", +"2.2.38-2-MacOS-x86_64", +"2.2.38-2-Windows", +"2.2.38-2-Linux-i686", +"2.2.38-2-Linux-x86_64", "2.3.20-alpha-1-MacOS-i386", "2.3.20-alpha-1-Windows", "2.3.20-alpha-1-Linux-i386",

1 0