[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 mult

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 of

[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 thi

[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 l

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 parti

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, > a

[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 publ

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 wrote: > > However, our survey data is likely biased towards a particularly young > > and educated crowd that's presumably less bothered by technological > > hurd

[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 first two bytes of) 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 onionsJson = JSON.stringif

[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 pinning

[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 web

[tor-dev] Exitmap's control flow

Hi Mridul, I'm copying tor-dev@, so other folks can chime in. On Thu, May 12, 2016 at 10:16:45AM +0530, Mridul Malpotra wrote: > a) Can you give me a short description about the program flow on how the > EventHandler class enables modules to be executed in exitmap? From my > initial pondering ove

Re: [tor-dev] Tor Volunteer - Censorship analyser

On Tue, May 03, 2016 at 11:33:54PM +0200, Lucia Di Marco wrote: > My questions here are only two: do you think this project is not needed > anymore now we have a lot of recent data about censorship in other > countries (OONI Explorer) and other tools? If I develop this software (I > will probably d

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 techni

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] Interested in GSoC opportunity

On Tue, Mar 08, 2016 at 10:18:20PM +0530, Deepankar Tyagi wrote: > On Mar 8, 2016 9:31 PM, "Philipp Winter" wrote: > > On Tue, Mar 08, 2016 at 11:35:03AM +0530, Deepankar Tyagi wrote: > > > idea #2 Exitmap Improvements > > > > > > I got stuck when def

Re: [tor-dev] Interested in GSoC opportunity

On Tue, Mar 08, 2016 at 11:35:03AM +0530, Deepankar Tyagi wrote: > idea #2 Exitmap Improvements > > I got stuck when defining timeline for this project. > I would appreciate any insights regarding what should be deliverable by > mid-term of GSoC. > > Also this project will a involve lot of brains

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 ___ tor-

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, howeve

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 d

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 git.torproject.org/user/phw/sybi

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, e.

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 th

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 05:43:01PM -0600, Tom Ritter wrote: > On 7 December 2015 at 13:51, 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 > > clus

[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] 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, started

[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 th

[tor-dev] "Seeing through Network-Protocol Obfuscation"

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 colle

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 befo

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 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 > > secur

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 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 &

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 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

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),

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 to

[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 s

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 fingerpri

[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 makes

[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] exitmap feature requests?

On Wed, May 06, 2015 at 06:15:46PM +, nusenu wrote: > do you consider feature requests via [1] or would you recommend > forking and implementing it oneself? I'm always happy to get feature requests. If a feature involves a lot of work, however, it might take me a while to get to it. In that

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 > atte

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 nec

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 w

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 > de

[tor-dev] Relays that change their fingerprints a lot

Inspired by Gareth's 31C3 talk [0], I taught sybilhunter [1] to calculate the amount of unique fingerprints a Tor relay used over time. Armed with that feature, I extracted the top 10 relay IP addresses that had the most fingerprints for every month since 2007 [2]. While most IP addresses show up

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 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 >

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

On Thu, Jan 15, 2015 at 01:34:01PM -0800, David Fifield wrote: > Maybe the checker should also check for when a lot of relays go away at > once. It looks that happened in mid-April, where relays that had been > started at different times in the beginning of the year all stopped at > once. > > (Oh,

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

I reimplemented doctor's sybil checker [0] in Go [1] which makes it possible to (somewhat) quickly analyse archived consensuses. The algorithm is quite simple. It iterates over every consensus ever published, keeps track of all relay fingerprints, and tells us how many previously unseen relay fin

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 -d

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

On Mon, Jan 12, 2015 at 06:57:01PM +0100, Tom van der Woerdt wrote: > 23% is a lot though - so high that I really doubt it's true. The > ratios between handshakes and deduplicated handshakes is also rather > strange. Is there anything we can do to the dataset to find out why > the amount is so high

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 rep

[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 resul

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: > 2. Single-packet authorization: > > > ScrambleSuit has

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

On Fri, Dec 12, 2014 at 04:33:05PM -0800, Vlad Tsyrklevich wrote: > I've attached a patch to warn bridge operators running with ORPort set to > 443 or 9001 as a stop-gap measure. You are raising good points here but keep in mind that we also want at least *some* (vanilla) bridges which run on port

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 wh

[tor-dev] Sybil attack detection (was: Karsten's July 2014)

On Tue, Aug 05, 2014 at 11:37:45AM +0200, Karsten Loesing wrote: > Started looking into better algorithms to detect Sybil attacks on the > Tor network. Current thinking is that we should define relay similarity > metrics like common IP address prefix length or time between first seen > in a consen

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 par

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 pa

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

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

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 OFT

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

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 side-projec

[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 clea

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 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 whi

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 be

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: https://t

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 p

Re: [tor-dev] Torsocks 2.0 RC code review

On Fri, Nov 29, 2013 at 11:37:27AM -0500, David Goulet wrote: > On 29 Nov (15:07:41), Philipp Winter wrote: >> I also have a minor feature request. It would be great if >> torsocks could display the source IP address and port of >> connections. I'm currently w

Re: [tor-dev] Torsocks 2.0 RC code review

On Tue, Nov 26, 2013 at 05:17:58PM -0500, David Goulet wrote: > I would really love to have help with code review so it can get accepted > as a replacement in the near future. Some of you already gave feedbacks > so thanks but now it needs the "seal of approval" from the community :). Thanks for t

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

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 exi

Re: [tor-dev] obfsproxy buffering

On Sun, Nov 17, 2013 at 07:33:12PM -0800, David Stainton wrote: > It seems like the solution is to write a super simple "framing > protocol"... which is to say that I can first send a frame length; and > on the receiving end simply read until frame length worth of data is > consumed... and then app

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 do

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 th

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 exi

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

I am working on a Python-based exit relay scanner which should detect malicious and misbehaving exits. The design should have a reasonable balance between being fast/parallel and stressing the network as little as possible. I came up with the following three steps: 1. Spawn a "parent" Tor proce

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.or

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] 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

[tor-dev] The ScrambleSuit pluggable transport / Philipp's May 2013 and earlier

Over the last months, I have been working on a pluggable transport protocol called "ScrambleSuit" [1, 2]. It is one---but not the only---answer to active probing as done by the Great Firewall of China. Active probing allows the GFW to detect and block vanilla as well as obfs2 Tor bridges; and per

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 second

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 woul

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 s

[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 du

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 e

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 th

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 develo

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

> Basically, the tool achieves two things: > - Evading the Chinese DPI engine by rewriting the TCP window size > during the TCP handshake. This leads to a fragmented cipher list > which does not seem to be recognized by the GFC. > - Blocking scanners with two dirty hacks. I removed the "two di

  1   2   >