Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
Obfs4 can apparently solve most of the problems pertinent to identifying Tor bridge traffic by inspection of TLS headers... Meek relies on SNI field of TLS headers to communicate to bridges via a "front end ". >From an overall cursory glance it appears that obfs4 was introduced in 2014 while Meek came later (probably 2015). Thus why would one choose to go back to relying on TLS traffic that could potentially be identified by the adversary is a bit unclear (considering that there already existed a superior solution then , i.e. obfs4). On Sun, Oct 28, 2018, 03:37 Carolin Zöbelein wrote: > Hi :), > > I can't give you an answer to your history questions, since I wasn't > involved in the history of PTs but I have the feeling you have this > fundamental question "Why we should work on an other PT, as long as the > stuff which we already have works fine?" (?) > > Simple answer: You should always have an active role (beeing faster > like the other party in development) and not a passive role (waiting > until your stuff doesn't work anymore before you work on something new) > in the fight against censorship. > > Best regards, > Carolin > > Am Samstag, den 27.10.2018, 17:20 +0530 schrieb Piyush Kumar Sharma: > > Hello all, > > I have a few specific questions related to the pluggable transports. > > > > 1.) I believe that obfs4 stops active probing(the latest problem as > > brought to notice by Ensafi et al, IMC 2015 and Shinying Cho, FOCI > > 2018), and hence discovering obfs4 Tor bridges using active probing > > is not possible. Is that true? If so, then we are good to go and > > hence we don't need any other pluggable transport to work for us as > > long as obfs4 is working? > > > > 2.) What was the motivation to bring in meek as a pluggable > > transport, given the fact that obfs4 works great to cover all the > > existing problems with Tor detection. Was the motivation just the > > fact that, it will be much easier for the users to use meek than > > obfs4 or something other than this? > > > > 3.) I searched a lot but could not find the timeline in which > > pluggable transports were built. As in what was developed and > > deployed first, obfs4 or meek? > > > > Regards > > > > Piyush > > IIITD > > ___ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] (no subject)
Hi All We (myself and my student, cc'ed here) have some questions regarding Tor relay bandwidth. We created a small testbed (private Tor network) involving relays, clients and servers over virtual machines. The client uses the relays to create two hop circtuits to communicate to the server. The link bandwidths between the virtual machines is otherwise ~ 10 Gbps (tested via end-to-end measurement tools like iperf and via downloading large files of sizes ~2 GB through https downloads). When not using Tor, the client achieve a download rate of approximately 8 Gbit/s while downloading a file of approximately 2 Gbytes. The same process, when repeated over Tor circuit (through relays of the private Tor network, that used virtual machines), p*rovides a maxmium download rate **of about 700 Mbit/s for the client (while the CPU utilization was over 80%).* This is much less compared to the expected throughput of 8Gbps achieved when client communicates directly to the server (without using Tor circuits). We tinkered around with the Tor config and discovered that when changed the config fields of BandwidthBurst and BandwidthRate to 100 MBytes, we achieved end-to-end throughput of about 100 Mbit/s (while the CPU Utilization was less than 20%) (while the underlying network link capacity is 1 Gbit/s). The moment the BandwidthBurst and BandwidthRate values are increased to 1 GB (which should effectively be 8 Gbit/s), the achieved throughput is about 650-700 Mbps (which is still 8 times slower than expected). Further, removing all bandwidth restrictions, the inter VM bandwidth (for the relays in the private Tor network) is around 8 Gbit/s (measured both via Iperf and through downloading a file > 2 GBytes using encrypted HTTP traffic). While this is as per the expected behavior of TCP, to utilize all the available bandwidth, the same does not happen for Tor which continues to ramp upto a maximum of 700 Mbit/s We are confused as to why Tor's link bandwidth utilization is not higher (Even on a private Tor network), even when using a high capacity VMs in the private Tor network -- each one having about 4 cores and 8 GBytes of RAM. I understand after speaking from some Tor developers and maintainers that Tor does not utilize all the available CPU cores. Our VMs however do not have any other process running either. We run the Tor processes over Debian servers with little no other programs. More strangely, while download via HTTPS achieves a very large fraction of the link capacity (>80%), Tor traffic happens to achieve a throughput of around 700 Mbit/s (which is around 90% lower than the max link bandwidth). We tried the same with 2-hop Tor circuits, hoping to see some improvement. But to no avail. We continue to observe the same poor bandwidth utilization. It would be great if you shed some light as to where we may be going wrong. Regards Sambuddho ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor's current traffic scheduling
Hi All I am a bit curious to know how does the traffic scheduling work in the present Tor distributions. Is it EWMA or the old round robin method ? Thanks Sambuddho ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Reg : using the keep alive messages
Sorry about the typo..I meant which is the relevant part of the code which I can begin looking into if I want to inject RELAY_DROP cells in a circuit in forward direction (from the OP towards the exit) and backward direction (from exit to OP). Thanks Sambuddho On Fri, Jun 24, 2011 at 8:36 PM, Sambuddho Chakravarty sc2...@columbia.eduwrote: Which is the relevant part of the that should I look into for injecting such cells in streams ? Thanks Sambuddho On Thu, Jun 9, 2011 at 3:03 PM, Sambuddho Chakravarty sc2...@columbia.edu wrote: Dear Roger Thanks for your response. I read the spec document about the RELAY_DROP cells. You say that no one has understood the passive correlation attack to utilize the RELAY_DROP cells. I am however little curious to see if moderate padding (enough to not mess up QoS of various services) can be used to prevent some of the attacks that rely on parameters such as OWD , RTT and B/W variation to link relays that are being used in a circuit. I am curious from the practical point of view of exploring such padding to prevent our bandwidth based confirmation attack or the MD attack (and its 2009 variant) . Thanks Sambuddho On Thu, Jun 9, 2011 at 12:29 PM, Roger Dingledine a...@mit.edu wrote: On Wed, Jun 08, 2011 at 08:11:58PM -0400, Sambuddho Chakravarty wrote: Hi All I read in the Tor design spec that Tor control protocol supports keepalive messages which could be used for link padding . I wonder if anyone has ever explored using them... I don't think you mean the Tor control protocol. There's no need to pad that connection (or if there is, you've screwed up badly somewhere else). The Tor protocol supports PADDING cells -- see sec 3 of tor-spec.txt: PADDING cells are currently used to implement connection keepalive. If there is no other traffic, ORs and OPs send one another a PADDING cell every few minutes. There's also a DROP relay cell. While PADDING cells can only be sent to the adjacent relay, the client can send DROP cells to any relay on her circuit, and any relay on the circuit can inject DROP cells to the client. See also sec 7.2 of tor-spec. But that said, I think the answer to your question is no. AFAIK nobody has understood passive correlation attacks well enough to get to the if I change the design like this, does the attack work less well research stage. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Reg : using the keep alive messages
Which is the relevant part of the that should I look into for injecting such cells in streams ? Thanks Sambuddho On Thu, Jun 9, 2011 at 3:03 PM, Sambuddho Chakravarty sc2...@columbia.eduwrote: Dear Roger Thanks for your response. I read the spec document about the RELAY_DROP cells. You say that no one has understood the passive correlation attack to utilize the RELAY_DROP cells. I am however little curious to see if moderate padding (enough to not mess up QoS of various services) can be used to prevent some of the attacks that rely on parameters such as OWD , RTT and B/W variation to link relays that are being used in a circuit. I am curious from the practical point of view of exploring such padding to prevent our bandwidth based confirmation attack or the MD attack (and its 2009 variant) . Thanks Sambuddho On Thu, Jun 9, 2011 at 12:29 PM, Roger Dingledine a...@mit.edu wrote: On Wed, Jun 08, 2011 at 08:11:58PM -0400, Sambuddho Chakravarty wrote: Hi All I read in the Tor design spec that Tor control protocol supports keepalive messages which could be used for link padding . I wonder if anyone has ever explored using them... I don't think you mean the Tor control protocol. There's no need to pad that connection (or if there is, you've screwed up badly somewhere else). The Tor protocol supports PADDING cells -- see sec 3 of tor-spec.txt: PADDING cells are currently used to implement connection keepalive. If there is no other traffic, ORs and OPs send one another a PADDING cell every few minutes. There's also a DROP relay cell. While PADDING cells can only be sent to the adjacent relay, the client can send DROP cells to any relay on her circuit, and any relay on the circuit can inject DROP cells to the client. See also sec 7.2 of tor-spec. But that said, I think the answer to your question is no. AFAIK nobody has understood passive correlation attacks well enough to get to the if I change the design like this, does the attack work less well research stage. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Reg : using the keep alive messages
Dear Roger Thanks for your response. I read the spec document about the RELAY_DROP cells. You say that no one has understood the passive correlation attack to utilize the RELAY_DROP cells. I am however little curious to see if moderate padding (enough to not mess up QoS of various services) can be used to prevent some of the attacks that rely on parameters such as OWD , RTT and B/W variation to link relays that are being used in a circuit. I am curious from the practical point of view of exploring such padding to prevent our bandwidth based confirmation attack or the MD attack (and its 2009 variant) . Thanks Sambuddho On Thu, Jun 9, 2011 at 12:29 PM, Roger Dingledine a...@mit.edu wrote: On Wed, Jun 08, 2011 at 08:11:58PM -0400, Sambuddho Chakravarty wrote: Hi All I read in the Tor design spec that Tor control protocol supports keepalive messages which could be used for link padding . I wonder if anyone has ever explored using them... I don't think you mean the Tor control protocol. There's no need to pad that connection (or if there is, you've screwed up badly somewhere else). The Tor protocol supports PADDING cells -- see sec 3 of tor-spec.txt: PADDING cells are currently used to implement connection keepalive. If there is no other traffic, ORs and OPs send one another a PADDING cell every few minutes. There's also a DROP relay cell. While PADDING cells can only be sent to the adjacent relay, the client can send DROP cells to any relay on her circuit, and any relay on the circuit can inject DROP cells to the client. See also sec 7.2 of tor-spec. But that said, I think the answer to your question is no. AFAIK nobody has understood passive correlation attacks well enough to get to the if I change the design like this, does the attack work less well research stage. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
