[tor-dev] Store Salmon-related information in Tor Browser?

(Sending this email again because I failed to copy tor-dev@.) On Mon, Aug 17, 2020 at 12:16:08PM -0700, Philipp Winter wrote: > Hi Matt, > > We recently started experimenting with the Salmon social bridge > distributor: > https://gitlab.torproject.org/tpo/anti-censorship/bridgedb

Re: [tor-dev] 24 hours worth of BridgeDB usage metrics

On Tue, Jul 30, 2019 at 05:42:11PM +0200, Karsten Loesing wrote: > You say that you're planning to add aggregate statistics like numbers by > distributor without drilling down to transports or countries. Keep in > mind that this is going to reduce the noise that you added when rounding > up to

Re: [tor-dev] 24 hours worth of BridgeDB usage metrics

On Mon, Jul 29, 2019 at 09:22:52PM -0700, Rick Huebner wrote: > Could some metrics be added to summarize how the bridges and queries > are distributed across the hashrings? Thanks for this suggestion. I agree that it would be helpful and I'll look into incorporating it into the metrics. Cheers,

[tor-dev] 24 hours worth of BridgeDB usage metrics

Over at , we are working on having BridgeDB export metrics. The patch is almost done and I deployed the work-in-progress code on BridgeDB, so we can take a look at the metrics and think of ways to improve them. The metrics format encodes the approximate number

[tor-dev] Shortcomings of the pluggable transports specification?

We are working on improving Tor's pluggable transports specification: The goal is to make the spec useful to more people and fix issues that have accumulated over the years. For more context, have a look at the following ticket, which we use to coordinate

[tor-dev] Export BridgeDB usage statistics

Hi Karsten, I'm working on , which will make BridgeDB export usage statistics. I would like these statistics to be public, privacy-preserving, and -- ideally -- added to Tor Metrics. I wanted to hear your thoughts on 1) what statistics we should collect, 2) how

[tor-dev] Detecting multi-homed exit relays (was: Onion auto-redirects using Alt-Svc HTTP header)

On Wed, Nov 15, 2017 at 10:03:39AM -0600, Tom Ritter wrote: > Detecting exit nodes is error prone, as you point out. Some exit nodes > have their traffic exit a different address than their listening > port.[1] Right. It's not trivial for tor to figure out what exit relays are multi-homed -- at

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

On Tue, Nov 14, 2017 at 02:51:55PM +0200, George Kadianakis wrote: > Let me know what you think :) Section 9.4 in the Alt-Svc draft talks about abusing the header for tracking. In particular, a malicious website could give each Tor user a unique onion domain to track their activity. That's

Re: [tor-dev] User perception of onion service discovery

On Tue, Oct 03, 2017 at 08:25:15PM -0400, Philipp Winter wrote: > - Many respondents were not aware of search engines such as ahmia.fi. > Among those that were, many were not satisfied with both the search > results and the number of indexed onion sites. Unsurprisingly, >

[tor-dev] User perception of onion service discovery

This is the second part of our preliminary analysis of how Tor users interact with onion services [0]. In this part, we analyse the issue of onion service discovery. Onion services are private by default, so it's the operator's responsibility to disseminate their domain if they want it to be

Re: [tor-dev] User perception of the prop224 domain format

On Wed, Sep 27, 2017 at 10:25:04PM +0100, Ben Laurie wrote: > On 27 September 2017 at 21:26, Philipp Winter <p...@nymity.ch> wrote: > > However, our survey data is likely biased towards a particularly young > > and educated crowd that's presumably less bothered by technologic

[tor-dev] User perception of the prop224 domain format

We recently ran a survey on the usability of Tor and onion services [0]. I had a closer look at how our respondents perceive the prop224 domain format and wanted to share some early insights. The original survey question was: > The Tor Project is currently working on the next generation of onion

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote: > > On 26 Jan 2017, at 10:19, teor wrote: > > > >>> onion_address = base32(pubkey || checksum || version) > > > > Is the order in which the address is encoded once the checksum is > > calculated. checksum represents (the

Re: [tor-dev] OnionGatherer: evaluating status of hidden services

On Fri, Mar 10, 2017 at 06:25:04PM +0100, Massimo La Morgia wrote: > On Fri, Mar 10, 2017 at 5:39 PM, David Fifield wrote: > > Your extension reports not only the onion domains that it > > finds, but also the URL of the page you were browsing at the time: > > var

[tor-dev] Proposal 273: Exit relay pinning for web services

ng.txt Title: Exit relay pinning for web services Author: Philipp Winter, Tobias Pulls, Roya Ensafi, and Nick Feamster Created: 2016-09-22 Status: Draft Target: n/a 0. Overview To mitigate the harm caused by malicious exit relays, this proposal presents a novel scheme -- exit relay p

[tor-dev] Paper on how DNS affects Tor's anonymity

My colleagues and I published a (not yet peer-reviewed) research paper on how DNS affects Tor's anonymity. The key parts of our work are: - We measure the DNS setup of exit relays over time, showing that at times Google got to see almost 40% of DNS requests coming out of Tor. - We show how

Re: [tor-dev] [GSoC '16] Exitmap project - Introduction and request for comments

Hi Mridul, Thanks for your interest in exitmap. On Fri, Mar 18, 2016 at 11:26:01AM +0530, Mridul Malpotra wrote: > I will also be reading the tech report on Exitmap and would be > grateful if you can recommend any other resource(s) that I should be > referring to. Don't bother reading the

Re: [tor-dev] Interested in GSoC opportunity

On Mon, Mar 14, 2016 at 12:06:20PM +0530, Deepankar Tyagi wrote: > Extended goals: > #1 create a module which does anomaly detection(machine learning) Unless you have a very specific plan, I would advise against this. Sound applications of machine learning are time-consuming, and Tor's setting is

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

On Wed, Jan 13, 2016 at 05:47:03PM +0100, Karsten Loesing wrote: > Do the Zoossh results there look plausible? I'm surprised that descriptor parsing is so slow, but I think the results are plausible, yes. I should look into it. Thanks, Philipp ___

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

On Tue, Jan 12, 2016 at 09:40:35AM +0100, Karsten Loesing wrote: > Philipp, would you be able to write the Zoossh counterpart for the > descriptor types supported by it? I attached a small tool that should do the same thing Damian's script does for consensuses and server descriptors. Note,

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

On Tue, Jan 12, 2016 at 09:40:35AM +0100, Karsten Loesing wrote: > Philipp, would you be able to write the Zoossh counterpart for the > descriptor types supported by it? I'm even more curious now how those > numbers compare to metrics-lib and Stem. I'd love to, but I cannot promise when I'll be

Re: [tor-dev] Better relay uptime visualisation

On Mon, Dec 07, 2015 at 01:44:47PM -0800, David Fifield wrote: > On Mon, Dec 07, 2015 at 02:51:23PM -0500, Philipp Winter wrote: > > I spent some time improving the existing relay uptime visualisation [0]. > > Inspired by a research paper [1], the new algorithm uses single-linkage

Re: [tor-dev] Better relay uptime visualisation

On Mon, Dec 07, 2015 at 09:57:18PM +, nusenu wrote: > > and every column is a relay. White pixels mean > > that a relay was offline and black pixels means that a relay was > > online. Red pixels are used to highlight suspiciously similar clusters. > > I assume they are highlighted only if

Re: [tor-dev] Better relay uptime visualisation

On Tue, Dec 08, 2015 at 04:52:45PM +, nusenu wrote: >> Also, here are the steps to reproduce: >> >> wget >> https://collector.torproject.org/archive/relay-descriptors/consensuses/consensuses-2015-11.tar.xz >> tar xvJf consensuses-2015-11.tar.xz >> go get

Re: [tor-dev] Better relay uptime visualisation

On Mon, Dec 07, 2015 at 11:43:38PM -0500, grarpamp wrote: > Can a one be generated covering each year and maybe a five year one. I haven't checked the complexity of the clustering algorithm I use, but it's probably quadratic. I think a full year worth of uptimes would require pruning the data,

[tor-dev] Better relay uptime visualisation

I spent some time improving the existing relay uptime visualisation [0]. Inspired by a research paper [1], the new algorithm uses single-linkage clustering with Pearson's correlation coefficient as distance function. The idea is that relays are grouped next to each other if their uptime (basically

Re: [tor-dev] Better relay uptime visualisation

On Mon, Dec 07, 2015 at 05:43:01PM -0600, Tom Ritter wrote: > On 7 December 2015 at 13:51, Philipp Winter <p...@nymity.ch> wrote: > > I spent some time improving the existing relay uptime visualisation [0]. > > Inspired by a research paper [1], the new algorithm uses single-l

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

On Sun, Oct 18, 2015 at 02:50:47PM -0700, Damian Johnson wrote: > > Damian and I sat down yesterday at the dev meeting to talk about doing > > a comparison of the various descriptor-parsing libraries with respect > > to capabilities, run-time performance, memory usage, etc. > > Hi Karsten,

[tor-dev] Should cloud-hosted relays be rejected?

We sometimes see attacks from relays that are hosted on cloud platforms. I have been wondering if the benefit of having cloud-hosted relays outweighs the abuse we see from them. To get an idea of the benefit, I analysed the bandwidth that is contributed by cloud-hosted relays. I first obtained

[tor-dev] Seeing through Network-Protocol Obfuscation

https://kpdyer.com/publications/ccs2015-measurement.pdf They claim that they are able to detect obfs3, obfs4, FTE, and meek using entropy analysis and machine learning. I wonder if their dataset allows for such a conclusion. They use a (admittedly, large) set of flow traces gathered at a

Re: [tor-dev] Get Stem and zoossh to talk to each other

On Sun, Aug 16, 2015 at 02:44:40PM -0700, Damian Johnson wrote: Ideally, zoossh should do the heavy lifting as it's implemented in a compiled language. This is assuming zoossh is dramatically faster than Stem by virtue of being compiled. I know we've discussed this before but I forget

Re: [tor-dev] Future Onion Addresses and Human Factors

On Mon, Aug 10, 2015 at 09:36:22PM +, Alec Muffett wrote: On Aug 10, 2015, at 2:00 PM, Philipp Winter p...@nymity.ch wrote: Vanity addresses encourage people to only verify the human-readable part of an address before clicking on it. That creates a false sense of security, which

Re: [tor-dev] Future Onion Addresses and Human Factors

On Mon, Aug 10, 2015 at 08:47:05AM +0100, bernard wrote: On 9 Aug 2015, at 23:43, Philipp Winter p...@nymity.ch wrote: Vanity onion addresses, for example, might have done more harm than good Why do you say that? What harm would human readable .onion addresses do? And to who? Vanity

Re: [tor-dev] Get Stem and zoossh to talk to each other

On Fri, Jul 31, 2015 at 10:00:27AM -0700, Damian Johnson wrote: Hi Philipp, sorry about the delay! Spread pretty thin right now. Would you mind discussing more about the use cases, and give a mockup for what this new domain specific language would look like in practice? My first thought is

Re: [tor-dev] Future Onion Addresses and Human Factors

On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote: 1) it’s all very well to go an mine something like “facebookcorewwwi” as an onion address, but 16 characters probably already exceeds human ability for easy string comparison. I wonder if a better way forward is to focus on tools

Re: [tor-dev] Get Stem and zoossh to talk to each other

On Fri, Jul 31, 2015 at 04:22:19PM -0400, l.m wrote: I know I've already mentioned some thoughts on this subject. I would be interested in your thoughts on the types of challenging questions such a hypothetical DSL might answer. I've already put some effort into this (forking metrics-lib), but

Re: [tor-dev] Get Stem and zoossh to talk to each other

On Tue, Jul 28, 2015 at 07:30:02PM -0400, l.m wrote: What you need is to properly define this domain-specific language using a context-free grammar. Then it doesn't matter how you parse the data, or what language, and the semantic analysis phase can be mapped to a variety of analysis/viz tools

[tor-dev] Get Stem and zoossh to talk to each other

Hi Damian, I'm interested in building a lightweight, internal domain-specific language to explore archived Tor data. The goal is to make it easy to answer questions like the one that recently came up on tor-relays, how many guards shift location significantly across the Internet, and how often?

Re: [tor-dev] Roster introduction (Philipp Winter) (Sean Saito)

On Sun, Jul 05, 2015 at 09:21:38AM +, saitos...@ymail.com wrote: - I searched for my relay family by fingerprint and the resulting page's URL didn't contain my family, so I couldn't send the URL to somebody else. Could you give me some more details about this? Currently the search

Re: [tor-dev] Roster introduction

On Fri, Jul 03, 2015 at 02:22:57PM +0800, Virgil Griffith wrote: Main things accomplished so far: * Setup the basic website at: http://www.tor-roster.org/ Looks good so far! I know that this is work-in-progress, but I have some minor suggestions: - I searched for my relay family by

[tor-dev] Visualising similarities between relay descriptors

Visualising the similarity between two Tor relay descriptors helps with finding Sybil attacks. I added code to sybilhunter [0] that takes as input relay descriptors, determines all (n^2)/2 pairwise similarities, and outputs DOT code (part of Graphviz) that illustrates relay clusters and what

[tor-dev] Quantifying the similarity between Tor relays

It is often helpful to determine the similarity between relay descriptors. For example, to detect Sybil attacks, or to find partners in crime once we found a malicious relay. I recently added code to sybilhunter that can automate this task. Now to the underlying theory. The algorithm makes use

Re: [tor-dev] TOR SoP proposal: extending and improving TOR network anomaly detection

On Tue, Apr 14, 2015 at 01:38:54AM -0400, Kibo Schaffer wrote: I want to improve TOR's ability to detect anomalies such as sybil attacks, and make it easy to include other heuristics for other potential attacks. When a potential attack is detected, users and maintainers are notified (as

Re: [tor-dev] Summer of Privacy application, Censorship Analyzer

On Tue, Apr 14, 2015 at 11:56:12AM +0200, Miquel Llobet wrote: As far as coding goes, I played a bit with OONI (did a scan, turns out I'm clean :-) ). and built it from source. What bugs to you recommend to work on as a start? Ideally I can write a patch before the submission is due to attest

Re: [tor-dev] What's the explanation for weekly cycles in user graphs?

On Tue, Mar 17, 2015 at 06:09:00PM -0700, David Fifield wrote: You can eyeball more examples in the omni-graph: https://people.torproject.org/~dcf/graphs/relays-all.pdf That's a really useful overview! It would be great if we could include that on the metrics page. Is there a usual story we

Re: [tor-dev] Questions for the torflow developers

On Mon, Mar 09, 2015 at 11:15:21PM +, Francois Valiquette wrote: By reading the documentation of torflow, it is yet not clear to me, exactly which tests you are doing. One part of my project is to make a description of each possible attack an Exit Node can make and a description of a

Re: [tor-dev] Running doctor's sybil checker over archived consensuses

On Thu, Jan 15, 2015 at 06:11:25PM -0500, grarpamp wrote: On Thu, Jan 15, 2015 at 10:25 AM, Philipp Winter p...@nymity.ch wrote: The median amount of new fingerprints in a consensus is six. The Here are some preliminary notes about the most significant spikes. I'll 2008-10-25: Missing

Re: [tor-dev] Is it time to drop support for the v1/v2 protos?

On Mon, Jan 12, 2015 at 08:24:58PM +0100, Tom van der Woerdt wrote: Interestingly, that paints a completely different picture. I added that line to two machines (guard+exit) and after a few minutes : # cat /var/lib/tor/node*/infolog | grep Negotiated | awk '{ print $8 }' | sort | uniq -dc

Re: [tor-dev] Is it time to drop support for the v1/v2 protos?

On Sat, Dec 27, 2014 at 03:38:28PM +0100, Tom van der Woerdt wrote: After reading the Tor spec [1] I did some digging and realized that the old handshakes and link protocols (v1 (certs up-front) and v2 (renegotiation)) are not used anymore as of 0.2.3.6-alpha which introduced link proto v3.

[tor-dev] ScrambleSuit's replay protection incomplete

In short: The implementation of ScrambleSuit's replay protection is incomplete which means that an active adversary can circumvent it. All the credit for this discovery goes to Lasse Øverlier. ScrambleSuit uses Uniform Diffie-Hellman as one of its authentication mechanisms. To defend against

[tor-dev] A Tor document parser implemented in Go

I have started working on a project to detect sybils and other anomalies in the Tor network. Once the algorithms are implemented, I want to run them over historical data. While Stem is great, it's implemented in an interpreted language which makes it a little bit too slow for my needs. As a

Re: [tor-dev] Internet-wide scanning for bridges

On Sat, Dec 13, 2014 at 08:54:29AM -0500, A. Johnson wrote: There are even better solutions than this: 1. Port knocking: https://wiki.archlinux.org/index.php/Port_Knocking 2. Single-packet authorization: http://www.cypherpunks.ca/~iang/pubs/bridgespa-wpes.pdf ScrambleSuit has

Re: [tor-dev] Malicious relays and honeypots

On Wed, Nov 26, 2014 at 10:30:42AM +, Gareth Owen wrote: I wonder if it might be worth having a discussion on how to detect malicious and/or suspicious relays. To my knowledge, the project currently only scans for MITM and tries to detect larger Sybil attacks (but doesn't always act when

Re: [tor-dev] Email Bridge Distributor Interactive Commands

On Sun, Jul 20, 2014 at 06:52:44PM +, Matthew Finkel wrote: So, the questions I am posing to those in the community who has an opinion about this: What do you think? What problems do you currently have with this? How can this be improved? Non-technical users might be confused by the

Re: [tor-dev] Using ScrambleSuit with something other than Tor

Hi Yuhao, On Fri, Jul 11, 2014 at 08:20:25PM +0800, Yuhao Dong wrote: I'm Yuhao Dong (undergrad student at University of Waterloo) and I'm currently doing research on, surprise, my own traffic obfuscation system. Cool! I'm in Toronto until the middle of August -- in case you are back until

Re: [tor-dev] Introducing CollecTor (was: Spinning off Directory Archive from Metrics Portal)

On Wed, Jun 04, 2014 at 04:54:03PM +0200, Karsten Loesing wrote: On 25/05/14 10:35, Karsten Loesing wrote: I'm continuously tweaking the Metrics Portal [0] in the attempt to make it more useful. My latest idea is to finally spin off the Directory Archive part from it, which is the part

Re: [tor-dev] RFC: obfs4 (Name not final)

On Wed, May 21, 2014 at 06:36:52AM +, Yawning Angel wrote: * obfs4 always does a full handshake. ScrambleSuit style session ticket handshakes are not supported. Even with Elligator2 mapping taken into account, the obfs4 handshake is significantly faster, so there is less of a

Re: [tor-dev] GSoC Ideas

On Tue, Feb 25, 2014 at 01:57:11PM +0530, Vighnesh Birodkar wrote: 2. Develop a Censorship Analyzer Will this be a part of any existing tor projects ? What is a student required to do to be considered suitable for this ? It is not yet clear if this project will be part of GSoC. Required are

Re: [tor-dev] Coordination of censorship analysis tool

On Wed, Feb 12, 2014 at 08:53:53PM -0500, Utsarga Sikder wrote: If you guys want to set up a meeting time, fill this out. If you want to see the results, go here - http://whenisgood.net/nhhy5yt/results/gqtpzak Looks like Feb. 22nd at 15:00 UTC is fine for us all. Let's meet in #tor-dev on

Re: [tor-dev] Coordination of censorship analysis tool

On Wed, Feb 12, 2014 at 12:32:27PM +0800, Deepak Kathayat wrote: Also, would it be possible to have a chat over #tor-dev sometime, where each of us could discuss in length about how the work could be divided and the amount of time one would be willing to put in for their part? Sounds like a

Re: [tor-dev] Coordination of censorship analysis tool

We recently had a small IRC chat in #tor-dev about the project. Deepak was wondering if the project could be implemented as browser extension. It would be interesting to explore this direction in more detail -- perhaps in parallel to an implementation based on OONI. Another important

[tor-dev] Coordination of censorship analysis tool

Hi Deepak, Utsarga, Tobias, and Yiwen! The four of you recently expressed interest in the censorship analyser project [1]. At this point, we only have a paper which discusses what we want from the tool [2]. There is no official code repository but Tobias recently started experimenting with some

Re: [tor-dev] Exitmap Patches

On Sun, Feb 02, 2014 at 02:02:33PM -0800, Damian Johnson wrote: Hi Philipp. For kicks and giggles I decided to dig into Exitmap a bit this weekend. Patches are available from... https://git.torproject.org/user/atagar/exitmap.git I reviewed and merged everything. Thanks, Damian; you clearly

Re: [tor-dev] Seeking advice on master level project

Hi Yiwen, On Thu, Jan 23, 2014 at 06:59:43PM -0600, Yiwen Zhu wrote: I am current a master student working on a graduation project. I am interested in the project Develop a Censorship Analyzer for Tor. But I am new to Python and only have 1 semester to finish it. So it seems too large scale

Re: [tor-dev] Projects to combat/defeat data correlation

On Mon, Jan 20, 2014 at 08:30:12AM -0500, Ian Goldberg wrote: On Sat, Jan 18, 2014 at 01:40:43AM +, Matthew Finkel wrote: obfs3 is supposed to be fairly difficult to detect because entropy estimation is seemingly more difficult than typically assumed, and thus far from what has been

Re: [tor-dev] Projects to combat/defeat data correlation

On Sat, Jan 18, 2014 at 01:40:43AM +, Matthew Finkel wrote: obfs3 is supposed to be fairly difficult to detect because entropy estimation is seemingly more difficult than typically assumed, and thus far from what has been seen in practice this seems to be true. There's a recent paper which

Re: [tor-dev] Slight obfsproxy API change (#10342)

On Wed, Dec 11, 2013 at 09:33:47PM +, George Kadianakis wrote: Do you agree with the changes? If yes, I will merge Ximin's patch for #10342, and you will have to update your transport codebase appropriately. Please let me know. For the record, I'm OK with this and replied here:

Re: [tor-dev] Design for an exit relay scanner: feedback appreciated

On Sun, Dec 01, 2013 at 05:09:55PM -0800, Damian Johnson wrote: You might want to look into PEP8 [1], Python's de-facto style guide. It's certainly up to you which bits you do/don't like, but coming close will make your code more uniform with the rest of the Python world. PyPI has a slick pep8

Re: [tor-dev] Design for an exit relay scanner: feedback appreciated

On Tue, Nov 26, 2013 at 03:21:04PM +0100, Lunar wrote: Philipp Winter: I now have similar code which is based on stem: https://github.com/NullHypothesis/exitmap However, the problem with a parallel single-Tor-process design is that there is no easy way for scanning modules to figure out

Re: [tor-dev] Design for an exit relay scanner: feedback appreciated

On Thu, Oct 10, 2013 at 07:23:11AM +, Aaron wrote: I have been working on adding a Tor Network Test Template to ooni-probe; the basic concept is to extend the Tor controller library we use (txtorcon) to be able to build and attach circuits to specific streams, and iterate over the exits in

Re: [tor-dev] next globe update feedback

On Sun, Nov 03, 2013 at 11:23:18AM -0800, Damian Johnson wrote: I worked on a new update for globe... Damn this is awesome! I'm tempted to link to this from our front page (replacing Tor Browser in the project matrix on www.torproject.org, since TBB is already the featured item on the

Re: [tor-dev] Design for an exit relay scanner: feedback appreciated

On Thu, Oct 10, 2013 at 07:23:11AM +, Aaron wrote: I have been working on adding a Tor Network Test Template to ooni-probe; the basic concept is to extend the Tor controller library we use (txtorcon) to be able to build and attach circuits to specific streams, and iterate over the exits in

Re: [tor-dev] Design for an exit relay scanner: feedback appreciated

On Thu, Oct 10, 2013 at 12:50:32PM +0400, meejah wrote: I have been working on adding a Tor Network Test Template to ooni-probe; the basic concept is to extend the Tor controller library we use (txtorcon) to be able to build and attach circuits to specific streams, and iterate over the exits

Re: [tor-dev] Pluggable transport weekly meeting

On Fri, Sep 06, 2013 at 02:58:55AM -0600, Vmon wrote: CEST: 18:00 BST (Summer GMT): 17:00 EST: 12:00 MNT: 10:00 PST: 9:00 That's OK for me. Thanks for organising this, vmon. Cheers, Philipp ___ tor-dev mailing list tor-dev@lists.torproject.org

Re: [tor-dev] Idea regarding active probing and follow-up of SSL connections to TOR bridges

On Sat, Jul 06, 2013 at 09:34:06PM +0300, Lag Inimaineb wrote: Anyway, one of the main topics discussed in that talk was the problem of preventing the blockage of TOR bridges by oppressors. While many fixes were mentioned, none of them actually solve the problem of the bridge being probed, by

Re: [tor-dev] Idea regarding active probing and follow-up of SSL connections to TOR bridges

On Sat, Jul 27, 2013 at 05:17:29PM +0300, Lag Inimaineb wrote: Specifically, after reading Nick Mathewson's proposal, I can see it is pretty much identical to what I've proposed (though his proposal has been around for more than a year). Do you have any information as to whether anyone has

Re: [tor-dev] Building better pluggable transports (Google Summer of Code)

On Tue, May 28, 2013 at 07:55:45PM -0400, Tariq Elahi wrote: 2. Can manipulate (add, delete, change) said traffic in time and data dimensions. The challenge is to predict what can actually be done with these three simple atoms. Be it terminating non-whitelisted TCP connections after 60

Re: [tor-dev] Building better pluggable transports (Google Summer of Code)

On Tue, May 28, 2013 at 02:33:40PM -0400, Tom Ritter wrote: Can a country block SSH?  Surely state-sponsored network operations take place over SSH, so I suspect a country cannot block it quickly, easily, and without internal retaliation from it's legitimate users.  Bureaucracy.   There would

Re: [tor-dev] Brainstorming a Tor censorship analysis tool

First of all thanks a lot for summing all of that up in such great detail, Arturo. Comments inline. On Fri, Dec 21, 2012 at 04:16:32PM +0100, Arturo Filastò wrote: # Collection of packet captures specific to the sent and received packets When you run a ooniprobe test that inherits from the

[tor-dev] Brainstorming a Tor censorship analysis tool

Hi there, Deliverable 6 for sponsor Z says: 6. Start a tool that a censored developer can run to discover why their Tor is failing to connect: brainstorm a list of things to check, and sort them by how useful they'd be to check / how hard they'd be to build. (#7137) The deliverable is due on

Re: [tor-dev] Next ten Tor Tech Reports (was: First five Tor tech reports)

On Wed, Aug 08, 2012 at 12:22:16PM +0200, Karsten Loesing wrote: Feedback much appreciated! The pdf documents look really good now. I don't know if the tech reports get cited a lot but it might be worth adding BibTeX entries next to the pdf download links. Also, in order to give the page more

Re: [tor-dev] Flash proxy deployment

Perhaps, the flash proxy concept could also be used for bridge reachability scanning [1]. Web sites could embed JavaScript code which tries to establish a connection to a provided bridge. The result (reachable or not) is then sent back. When users from different censoring countries visit one of

Re: [tor-dev] GSoC Intro: Stegotorus

On Mon, Jun 04, 2012 at 06:35:53AM -0600, vmon wrote: After submitting my idea, I found out that at the end of the day, it wasn't *that* original. Zack/zwol had worked on it for a year. It is called Stegotorus. However, considering, the arm-race nature of the problem and the state of

[tor-dev] brdgrd: Protecting bridges from the GFC

Hi, I've been working on a small tool whose purpose is to protect bridges from the Chinese firewall. The tool runs independently of Tor and analyzes/rewrites SYNs and SYN/ACKs which it gets with the help of libnetfilter_queue. It is quick and easy to set up and can be run by bridge operators.