Re: [tor-dev] Setting NumEntryGuards=2
On 2018-03-26 20:34, Mike Perry wrote: Florentin Rochet: On 2018-03-20 04:57, Mike Perry wrote: Arguments for staying with just one guard: 1. One guard means less observability. As Roger put it in the above blog post: "I think the analysis of the network-level adversary in Aaron's paper is the strongest argument for restricting the variety of Internet paths that traffic takes between the Tor client and the Tor network." http://freehaven.net/anonbib/#ccs2013-usersrouted Furthermore, I believe that conflux will also be useful against traffic analysis and congestion attacks. Since the load balancing is dynamic and hard to predict by an external observer, traffic correlation and website traffic fingerprinting attacks will become harder, because the adversary can no longer be sure what percentage of the traffic they have seen (depending on their position and other potential concurrent activity). Similarly, it should also help dampen congestion attacks, since traffic will automatically shift away from a congested guard. I am really enthusiast about multipath, either at the Tor level or even at the transport level: we discussed QUIC at the meeting, but MultipathQUIC could also be a long-term option now that we discuss more than 1 entry guard. However, I would argue that it does not really help against traffic correlation. Our paper at pets18 exploits Tor's forward compatibility feature to design silent cheap, almost instantaneous and perfect active traffic confirmation that does not care about user traffic to succeed. See Section 5, https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf In this case, Tor's forward compatibility is a bug. The Tor protocol is now versioned at the feature layer, so Postel-style permissive forward compatibility is no longer required: https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-versions.txt I have been bothered by the types of side channels you discuss in that paper for some time. They are tricky to remove, but not impossible. See https://trac.torproject.org/projects/tor/ticket/25574 and the child ticket and associated branch. Great! Roger indeed told me you were exploring similar problems. As you said, it's tricky to remove because of false positives and because you loose protocol flexibility, and it is not clear to me what the consequences can be over the years. I think we can reason about this as a scalability problem, not in size, but in *time* with its underlying technical issues and security concerns depending on how much we scale the protocol flexibility. It is not really this thread's topic, so I prefer not to talk too much here, but I would be glad to discuss more those problems or to help on any proposal design, and code. Just ping me on IRC :) (Jaym). Your paper also states that you got multiplier effects from various issues with Tor's protocol, which improved your results. If we remove these multiplier effects by fixing the protocol and behavior, then it seems to me that adaptive traffic routing will add further uncertainty to congestion-based attacks. Hard to tell, even if the intuition is on your side. It's probably possible to come up with something smarter than the various attacks I did. We will definitely need another round of analysis after any proposed change. While I feel that the various 'multiplier effects' should be removed, I don't really like the approach "patch the weaknesses quick and move on", often we miss to understand the root cause of the various problems, and we end up to add complexity to the software while there might be something better to do. Maybe the real debate would be to discuss what's the major threat between active/passive attackers, and what do we care about? The question is, why should we care about hardening passive attacker's work when the active form is always as easy? To your point: because I believe it is possible to make both active and passive attacker's jobs hard. I also believe that when we look deeply enough, we will find that improvements that make an active attacker's task harder will also improve things against many, if not all, classes of passive attacker. Roger made a related point that I want to inject here, so I remember to pick it up in the proposal: Roger said that we should consider active vs passive observers here. He contended that against passive observers, one guard is always better, and that we should not discount that benefit while considering an active attacker making circuits via a second guard. However, there are two main issues with calling the Tor-sometimes-uses-a-second-guard "attack" fully "active": 1. It is not always active. In day-to-day operation, clients will use a second guard whenever they pick an exit that is in the same family or /16 of their primary guard (this is because Tor rightly chooses exits first, to avoid leaking guard node choice via exit node choice). Clients will also do this when an onion service
[tor-dev] Connections failed to default obfs4 bridges
Hi, In a recent connectivity test to the default obfs4 bridges [0], we found that we are unable to connect to 10 or so of them (from open networks, i.e., no local filtering). Is this a feature, like some of them only respond to users in certain parts of the world? Or is this a bug, like the default list of bridges refers to old bridges that are no longer available? Or am I misunderstanding functionality here? Thanks! Rob [0] https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/PTConfigs/bridge_prefs.js signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Connections failed to default obfs4 bridges
On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote: > In a recent connectivity test to the default obfs4 bridges [0], we found that > we are unable to connect to 10 or so of them (from open networks, i.e., no > local filtering). > > Is this a feature, like some of them only respond to users in certain parts > of the world? Or is this a bug, like the default list of bridges refers to > old bridges that are no longer available? Or am I misunderstanding > functionality here? Do you mean 10 distinct IP addresses, or 10 ports on a few IP addresses? Not all the IP addresses in the list are distinct. Even while Lynn Tsai, Qi Zhong, and I were closely monitoring default bridge reachability, a lot of the default bridges were often offline, because of reboots, iptables problems, etc. See for example the "Orbot bridges" strip of Figure 5.2 here; the gray and red areas that precede blocking are where the bridge was simply offline: https://www.bamsoftware.com/papers/thesis/fifield-thesis.pdf#page=43 We have a lot of past measurements of default bridges. The rows with site="eecs-login" are from the U.S. https://www.bamsoftware.com/proxy-probe/ (download the repo, not probe.csv.gz, which isn't as recent) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Connections failed to default obfs4 bridges
> On Mar 28, 2018, at 12:23 PM, David Fifield wrote: > > On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote: >> In a recent connectivity test to the default obfs4 bridges [0], we found >> that we are unable to connect to 10 or so of them (from open networks, i.e., >> no local filtering). >> >> Is this a feature, like some of them only respond to users in certain parts >> of the world? Or is this a bug, like the default list of bridges refers to >> old bridges that are no longer available? Or am I misunderstanding >> functionality here? > > Do you mean 10 distinct IP addresses, or 10 ports on a few IP addresses? > Not all the IP addresses in the list are distinct. > Turns out this was 10 ports on the same IP address. And we did the measurements back in December, so they are already a bit dated. > Even while Lynn Tsai, Qi Zhong, and I were closely monitoring default > bridge reachability, a lot of the default bridges were often offline, > because of reboots, iptables problems, etc. See for example the "Orbot > bridges" strip of Figure 5.2 here; the gray and red areas that precede > blocking are where the bridge was simply offline: > https://www.bamsoftware.com/papers/thesis/fifield-thesis.pdf#page=43 > > We have a lot of past measurements of default bridges. The rows with > site="eecs-login" are from the U.S. > https://www.bamsoftware.com/proxy-probe/ (download the repo, not > probe.csv.gz, which isn't as recent) Ahh, this is great, thanks for sending! Best, Rob signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Connections failed to default obfs4 bridges
On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote: > Is this a feature, like some of them only respond to users in certain parts > of the world? Or is this a bug, like the default list of bridges refers to > old bridges that are no longer available? Or am I misunderstanding > functionality here? In general it's a bug. We don't have any fancy "only listen to this but not that" logic in those bridges. I would totally believe that some of them are down by now. We need to do two things better: (a) monitor how they're doing, and (b) reach out to the operators when they go down, so the operators can fix them or so we can take them out of the next Tor Browser. I think 'b' is where we've been falling down lately. Maybe we should add this topic to the plate for the upcoming relay advocate. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The case for Tor-over-QUIC
Rob Jansen: > Thanks for the detailed write-up Mike! Theoretically, moving to QUIC > seems great; it seems to solve a lot of problems and has enough > advantages that we could just run with it. > > I'll reiterate some of my primary concerns that I gave in Rome: > > - I think it would be a mistake to push forward with such a > significant change to Tor's transport layer without significant > testing and experimentation. We have tools that allow us to do > full-network-sized experiments (Shadow), and we have interested > researchers that want to help (including me). I am not trying to argue against doing the research. My goal was to make enough of a case for QUIC that we can begin work on an implementation and tune it as we study it, or at least identify the minimum set of experiments that are needed before we could commit to such a path. I expect us to have to tune things like queue length, queue management, slow start, reordering parameters, drop recovery strategies, and the backoff rates when drops happen. QUIC is also extensible enough such that things like explicit congestion notification and link capacity estimates can be used to try to avoid drops (though we would need to do this at the onion layer rather than the QUIC layer, because intermediate relays will not be able to add in ECN information in-band in our use of QUIC, due to onion crypto): https://tools.ietf.org/html/draft-johansson-quic-ecn-00 Because of this flexibility, I would be very surprised to discover that QUIC proves impossible to tune in order to outperform our current lack of congestion control. > - However, I am much less optimistic than you that it will just work > and instantly improve performance. You mention that Google has done > lots of tests, but my guess is they test in environments that look > like the Internet - i.e., fast core and slow edges. Do we know how it > would perform when the path contains additional 6 edges sandwiching 3 > potentially low bandwidth Tor relays? Tor is a significantly > different environment than the Internet; for example, an end-to-end > congestion signal in Tor will take orders of magnitude longer to > reach the client than in traditional networks. In drop-based congestion control, the duration of how long the drop signal takes to reach the client is not a function of where the drop happens. It is a function of the total RTT of the path. A drop early on the path takes just as long to discover as one burried in the middle. As a result, higher RTT latency does impact drop-based schemes quite heavily (and the higher the drop rates, the worse this gets), but Tor's latency is only orders of magnitude greater than the internet because of queuing. If our queues can be bounded, then the latency multiplier should be proportional to the number of Tor hops (and the average physical distance of these paths). > - Because of the above, I'm not sure that an end-to-end design is the > right way to go. As I mentioned, we have simulators and researchers, > so we should be able to learn more and make a more informed decision > before committing to a design that will be difficult to change later. I suppose that before we undertake or commit to a full implementation, a couple of basic experiments could inform us as to if Tor's latency and drop characteristics might severely impact vanilla QUIC performance. 1. What drop rates do fully-utilized QUIC networks tend to see? Are QUIC's backoff and recovery properties sufficient such that packet loss will remain reasonable under heavy use? Is this drop rate a function of the number of concurrent QUIC connections or other network properties? (I bet this information is known by groups studying QUIC and similar congestion control schemes, but I am not finding it with casual searching. TCP folk lore says "drop rate increases as concurrent connections increases" but I can't find concrete relationships.) 2. Given the above information about the level of drop rates that fully-utilized QUIC networks see under what circumstances, we can then conduct an experiment to inform us of what fairness and goodput look like under various link latencies with these drop rates. #2 will inform us about whether QUIC is acceptable as-is, or if we would need to explore ECN or other non-drop based congestion signals. We will need to be careful while conducting these experiments, though. I found a few research papers on QUIC, but nearly all of them state limitations wrt varying aspects of the protocol being disabled or enabled depending on Chromium/QUIC version (presumably due to whatever experiments Google was conducting at the time). Additionally, it looks like many of the QUIC implementations do not implement all (or any) of the drop detection and recovery strategies mentioned in the spec, and even the Google implementation goes back and forth on things like FEC. So we will need to be careful to test what we intend to use. > - We should be sure to pay close atten
