- tor-dev - lists.torproject.org

Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!
by Nathan Freitas 14 Feb '15

14 Feb '15

On Sat, Feb 14, 2015, at 03:04 AM, CJ wrote: > > > On 14/02/15 08:58, Nathan Freitas wrote: > > > > > > ----- Original message ----- > > From: Nathan of Guardian <nathan(a)guardianproject.info> > > To: guardian-dev(a)lists.mayfirst.org > > Subject: Orbot v15-alpha-3 with VPN and Meek! > > Date: Sat, 14 Feb 2015 02:57:34 -0500 > > > > > > More progress on Orbot VPN support, and now, thanks to our new PLUTO > > library (https://github.com/guardianproject/pluto) support for Meek > > (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4 > > as well. > > > > Currently you can use Meek or you can use VPN, but you can't use both > > together... still working on that, as I can't get Meek to talk to the > > passthrough HTTP proxy I use to allow socket connections out of the VPN > > filter. > > > > To use Meek, just enable the "Bridges" button on the home screen, > > without using any bridge config info, and it will default to using the > > Meek Azure instance. If you set the bridge line to 0 it will use Google, > > and 1 it will use Amazon, and 2 it will use Azure. > > > > The VPN mode is just as easy, just enable VPN using the homescreen > > toggle button, then start/restart Orbot. All apps on your phone should > > now be running through Tor. > > > > Remember, Bridges and VPN don't work at the same time, for now... but > > please test both features separately, and let me know how well they work > > for you. > > > > APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk > > SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc > > > > Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or > > https://github.com/n8fr8/orbot/tree/v15-dev > > > Hello Nathan! > > Glad seeing this VPN part going further! I just have concerns regarding > my app compatibility (orwall): does orbot still opens ports on > localhost, and are they still the same, or shall I detect orbot version > and/or probe for opened ports? Everything is the same as usual. I don't think we can support both Orwall and VPN at the same time, so that will be another choice the user will have to make. The VPN doesn't fulfill the requirements of advanced users who want the level of protection provided by Orwall and what Mike Perry originally outlined. It is tricky to start on boot, there is no guarantee system services can't route around it, and it can be killed if Orbot crashes. Root and IPTables will still be required for that. VPN mode is really just for circumvention of app blocks by novice users. +n

1 0

Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
by Nathan Freitas 13 Feb '15

13 Feb '15

On Fri, Feb 13, 2015, at 07:45 PM, Yawning Angel wrote: > Yes, this means that if you run "kittensomgmewmew.onion" and are scared > of the NSA's persistent attempts to extract your hidden service key, > via ultrasonic laser beamed from their satellites, you could run your > tor instance entirely in a ram disk, and load the HS key manually each > time from a USB token you wear around your neck. A very practical use of this in the Orbot context, is that we can now store all HS identity data in an IOCipher encrypted volume, which the user can unlock with a strong passphrase when they want to start up their onionsites. Currently, all HS data is stored in the standard Tor data paths, only protected by the per-app user permissions on Android. This means the data can be accessed by rootkit capable malware apps and forensic extraction tools. With IOCipher, that would make that a great deal harder, and impossible if they were in a locked state (i.e. the key is not in memory). We are working on adding OnionShare-capabilities to Orbot, so this is well timed! +n

1 0

Authority Directory new IP
by SiNA Rabbani 13 Feb '15

13 Feb '15

Dear Tor, I am planning to change the IP address of Faravahar, it's basically a reconfiguration of the networking and how we are hosting it, to better stand future DDoS attacks. Here is the ticket for it: https://trac.torproject.org/projects/tor/ticket/14487 Should I also attach a patch for tor's source code? All the best, Sina "Be the change that you wish to see in the world." - Mahatma Gandhi

1 0

Multithreaded Crypto
by Nik 12 Feb '15

12 Feb '15

Hello, I'd like to try to help out and do some work on Tor's multithreaded crypto, specifically for incoming/outgoing cells. I've read through https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/Multithreade… as well as #1749 and #7572. I have a few questions for tor devs and people who've worked on/are working on the relevant bits of code: 1) Does the section "Phase 1: Cell crypto" in the Multithreaded crypto wiki page still reflect the current design and coding plans (along with the additions from the "Athena's notes" section)? 2) If so, approximately what stage of "Cell crypto: The plan" (on Multithreaded crypto wiki page) has development gotten to/is work currently being done on? I (briefly) looked around in master, and it looks like a crypting queue isn't being used yet. So if this is still the plan I guess I can assume that development is somewhere in phase 1? 3) Is there any other work/other branches I should take a look at? (i.e. in #7572, nickm commented "Andrea made some progress here", and I'm vaguely aware that there was a GSOC project last summer on multithreaded crypto, but it's not clear to me how far that effort got or how much of that code has made it into master.) 4) Is anyone currently working on this I should talk to? I know this can be a tricky thing to get right, so I just want to get a sense of where the best place to start might be and also avoid duplicating work someone else is doing/has already done. Thanks! All the best, Nik

1 0

Re: [tor-dev] A proposal to change hidden service terminology
by str4d 11 Feb '15

11 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Erik de Castro Lopo wrote: > A. Johnson wrote: > >> Several of us [0] working on hidden services have been talking >> about adopting better terminology. > > In general, I am in agreement with this, but I wonder if now might > be a good time to unify Tor terminology with other similar > technologies like I2P and Cjdns/Hyperboria. It is interesting that you raise this, because we at I2P have been thinking the same thing. We discussed the issue of I2P terminology at 31C3 and decided that after 12 years of Tor/I2P coexistence, Tor had the upper hand with regard to commonplace terminology. In our next release, we are changing most of our user-visible tunnel-related terms (I2P destination, tunnel, eepsite etc.) to instead use "Hidden services" in some way [0], to draw parallels to Tor hidden services - because as far as an end user is concerned, they do "pretty much" the same thing. And as far as we could tell, "hidden services" is now considered "too generic" for Tor [1], so it made sense to use it generically. Tags are now frozen for the 0.9.18 release, but we are still open to further discussion about terminology. > > I have heard someone (forget who) propose that 'Dark Web' be > dropped in favour of CipherSpace which could include all of these > privacy perserving protocols, leaving terms like "OnionSpace" for > Tor, "I2PSpace/EEPSpace" for I2P etc. I am certainly in favor of this kind of collaborative approach. It's hard enough already trying to make this stuff understandable to end users (usability and UX of the tools themselves aside), without having multiple kinda-similar-but-not tools trying to do so in different ways. A "united concept front" would benefit tools _and_ users. str4d [0] http://zzz.i2p/topics/1780-hidden-services-done-right [1] http://www.dailydot.com/technology/tor-crowdfunding-hidden-services/ > > Cheers, Erik > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU20J5AAoJEIA97kkaNHPnnzYQAI1iVeLcOcjVCR/hJ4nYq8ND DlyfENy0QYUtg9k85qIqoA2EEskUPDHDSRMqLZciQo2RgC7nFoNmgNjePUKXNtGA hLDodOjuEUcXQyA0+fl3v6sfzLxOc+E6sbLdnuV/wDgTuSPveVOgWi5eGUX2mb0/ DbYgMxp0kD0KghFPF1EPtj0S6sP1J/wwoFMJDhYm3no7qbWK1CqQvtfyxjkSXAmg EcdVWOqOUjA66ETNaMpQQVTiZ5MZVKM+2u5bDFDpwd4cEOuoy5bkiwy5gZLsIRot hB13as06kiWz6WAN8gsPqHF7t0JslHh9jSKIYRwuBf+e/NUtCGjGVVGf4YHwolgB 2AjuoeTAxzzBeNB6BvmSNw5h/oBt2S1fg0/QirCDrmpuQDKomD8+NI5EFatAiNkn 5RsbPrN/Clp+fJeW/Ypgh+ZUT2pO+Kps9fkgAs4u5QI6FnuCPvYGjsTil5a599KA 81FKzXOHNJ9L7IORmPymOZbN/Ba+upu6cznuB5KCRAt9q5QxAonx9Ry/oulC9kkF 9gacUY7Krglg5AUUlZA9dCesUftP8yeGhM52RreAkJTfK/rI94WK9YIaV/C3lbPb 233SthcQK3SoyRqR49B1ht3/4DgVah+6/K9TfQN7ZHjA0LizqUILqWuqO/5CLxNX uqkIyMePKodbzO8qr2TW =GTFn -----END PGP SIGNATURE-----

3 3

Let's come up with the roadmap for the future of OONI
by Arturo Filastò 11 Feb '15

11 Feb '15

Hello Oonitarians and Divisionists, I would love to have your feedback on what you believe to be the most important topics for the future of OONI. I have made a list of what I believe are all possible and interesting tasks to perform, but we can't do them all and for sure we can't do them all at once. For this reason it would be very useful if you could express a vote from 1-5: 1: Nah, this is boring and pointless 2: Not really super important, I would give priority to other stuff 3: Useful, I would do it 4: This would be awesome 5: Epic! Feel free to also expand these topics with questions and feedback (or new ones). At the end of the list I will give you a table to cast your vote. # Get daily OONI measurements from 50 countries This means focusing on getting a large and diverse reliable OONI userbase. It does not simply mean to get at least 1 measurement in 50 countries, but it means either establishing relationships with trusted parties in 50 countries, or expanding our userbase to a point where we have at least 1 measurement per day for every test per country (from the same network). Ways of achieving this are: * Rent a VPS in X number of countries * Running the adopt an ooniprobe program (see below for more details) * Establish an agreement with operators in 50 countries to host the probing infrastructure (as previously stated) # Develop OONI tests for censorship circumvention tools This involves devising a methodology for testing the reliability of censorship circumvention tools in various countries. It means testing censorship circumvention tool both open source and propertairy. A cursory list of the protocols/tools we could be interested includes, but is not limited to: * Tor * VPN * Web proxies (hidemyass, etc.) * SSH tunnel * Freegate * Psiphon * Ultrasurf * alkasir If you think we should be testing some other tools too, please add to this list. Useful resources: http://cyber.law.harvard.edu/publications/2011/2011_Circumvention_Tool_Eval… http://cyber.law.harvard.edu/publications/2010/Circumvention_Tool_Usage # Develop scheme for orchestrating ooni-probes This means coming up with a protocol that allows an OONI test developer to schedule a measurement to be run with a certain input they decide on a set of probes in country X. Obviously security considerations need to be taken into account and access will be in the initial stage only limited to a very restricted set of OONI developers that will be made public. # Implement data analytics and visualization for OONI tests We have a bunch of data and we would like to give meaning to it. This would involve writing tools for querying the data in the database and extract useful analytical information from it. Based on this data we can then start looking at historical OONI data and provide some sample visually supported reports. This is a list of tests we should develop analytics for: * HTTP requests * DNS Consistency * DNS Injection * TCP Connect * HTTP Invalid Request Line * HTTP Header Field Manipulation * Multi protocol port traceroute # Implement pub-sub system for ooni collectors Currently OONI collectors (the things you send your ooniprobe measurement results to) keep in sync thanks to a bunch of shell scripts and cronjobs. To have more real time data it would be useful to have a pub-sub mechanism that allows the pipeline to subscribe to all the collectors and the collectors will then publish the collected reports to it, as soon as they are submitted. This will allow the OONI data to go through the data pipeline much faster (instead of ~2 hours, perhaps just some minutes or even less potentially). # Reach production quality ooni rasperry-pi (beagle-board) images This involves implementing what is specified in the lepidopter specification: https://github.com/anadahz/lepidopter/blob/master/specification.md We should then provide scripts for building the image yourself or how to download and burn it to an SD card on Windows, OSX, Linux (with screenshots). As a bonus we could also offer shipping of pre-made raspberry pi images already burn to an SD card, similar to what is done with rasbpian images. # Promote and further develop OONI on mobile (Android, iOS) This involves improving the GUI of OONI on mobile and getting it into the Google Play store and the Apple App store. We should also work on making it easier for developers of existing iOS and Android apps to add internet measurement capabilities to their app by linking to libight. # Do research based on OONI This would involve doing some research on internet censorship based on OONI probe or on internet measurement in general and publishing them in peer reviewed venues. # Publish monthly reports about the status of internet censorship in a country This would be sort of like a monthly e-zine, where every month we analyse the status of internet censorship in a given country. It should be backed by OONI data, but the core of it should be an editorial type piece explaining the context of the country and how censorship is affecting them. I expect most of this work to be carried out by somebody that has a background in journalism and social sciences. # Run "adopt an ooni-probe" campaign This is basically a program where people make a donation to support getting somebody in an interesting country an ooniprobe or receiving an ooniprobe themselves. # Integration with other censorship measurement projects This means finding better ways of using data from other projects as part of OONI research or getting them to use our data. # Reaching out to communities inside of censored regions This means getting a better understanding of what "benefit" we can give to people that are running the tool. On this topic also see: https://trac.torproject.org/projects/tor/ticket/14760 # Redesign the website for ooni This means removing the horrible bootstrap basic template of the current website and restructuring it so people actually understand what OONI is and how it can be useful to them. # Hold an international internet censorship conference This means running an event where we invite a bunch of people that are active in the field of internet censorship and discuss ideas and possible collaborations. # Implement a GUI for ooniprobe This means picking up where we left off with the OONI web gui and finish implementing it. This could potentially also be useful for the orchestration task as we could implement access control on the HTTP API that the web interface consumes. Goal | Vote ---------------------------------- Get daily OONI measurements | from 50 countries | 0 ---------------------------------- Develop OONI tests for | censorship circumvention | tools | 0 ---------------------------------- Develop scheme for | orchestrating ooni-probes | 0 ---------------------------------- Implement data analytics | and visualization for OONI | tests | 0 ---------------------------------- Implement pub-sub system | for ooni collectors | 0 ---------------------------------- Reach production quality | ooni rasperry-pi | (beagle-board) images | 0 ---------------------------------- Promote and further | develop OONI on mobile | (Android, iOS) | 0 ---------------------------------- Publish monthly reports | about the status of | internet censorship in | a country | 0 ---------------------------------- Run "adopt an ooni-probe" | campaign | 0 ---------------------------------- Integration with other | censorship measurement | projects | 0 ---------------------------------- Reaching out to communities| inside of censored regions | 0 ---------------------------------- Redesign the website for | ooni | 0 ---------------------------------- Hold an international | internet censorship | conference | 0 ---------------------------------- Implement a GUI for | ooniprobes | 0 ---------------------------------- Do research based on | OONI | 0 ---------------------------------- Thanks for taking the time to go through this long email, you can as always find us on IRC #OONI irc.oftc.net. Have fun! ~ Arturo

3 2

A proposal to change hidden service terminology
by A. Johnson 11 Feb '15

11 Feb '15

Hello all, Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problems with current terms are 1. '''Hidden''' and '''Dark''' have a negative connotations. 2. '''Hidden-service website''' is too long; '''hidden site''' is too vague. 3. '''.onion''' (read "dot onion") is hard to say and not very descriptive. 4. There is no general term for the set of available hidden services. 5. The term '''encrypted service''' is too general. This term refers to a setup (still needing development) in which Tor is required to connect to a service, but the service location is not hidden. Even without server anonymity, this setup can provide enforced client anonymity, secure name resolution, censorship circumvention, and end-to-end-encryption. Making the server location known can allow for improved performance (by shorter circuits) and security (by enabling location-aware path selection by the client). We’ve come up with the following suggestions for better terms, which we’d like to offer up for discussion: 1. '''onion service''' should be preferred to refer to what is now called a "hidden service". If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent). We couldn’t decide on the best names for alternative onion service setups, because they don’t exist yet! But, we have some ideas about how these things might be named: 1. Some names for a setup in which the onion service location is known but still must be connected to via the Tor protocol: * '''Tor-required service''', '''TRS''' for short * '''Direct onion service''', '''direct service''' for short 2. Some names to specify that the onion service is hidden, if that becomes necessary: * '''Protected onion service''', '''protected service''' for short * '''Tor-protected service''', '''TPS''' for short 3. Some names to specify that a client connects to an onion service non-anonymously: * '''Client-direct access''' * '''tor2web mode''' We’re maintaining an evolving wikipage with the above suggestions [1]. Some of us are already beginning to use the suggested terminology, to see how it works out. One nice goal might be for Tor to choose the new terms that it likes (if any) and use them in the rollout of next-gen onion services [2]. So we’re bringing up this subject now to a larger segment of the Tor community. Thoughts? Best, Aaron [0] Including David Goulet, Rob Jansen, George Kadianakis, Karsten Loesing, and Paul Syverson [1] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Termino… [2] https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t…

6 7

Re: [tor-dev] A proposal to change hidden service terminology
by Nathan Freitas 10 Feb '15

10 Feb '15

On Tue, Feb 10, 2015, at 01:13 PM, A. Johnson wrote: > Hello all, > > Several of us [0] working on hidden services have been talking about > adopting better terminology. I agree 100% with the term list and am eager to start using it. Some of the problems with current terms areh > 1. '''Hidden''' and '''Dark''' have a negative connotations. > 2. '''Hidden-service website''' is too long; '''hidden site''' is too vague. > 3. '''.onion''' (read "dot onion") is hard to say and not very descriptive. > 4. There is no general term for the set of available hidden services. > 5. The term '''encrypted service''' is too general. This term refers to a setup (still needing development) in which Tor is required to connect to a service, but the service location is not hidden. Even without server anonymity, this setup can provide enforced client anonymity, secure name resolution, censorship circumvention, and end-to-end-encryption. Making the server location known can allow for improved performance (by shorter circuits) and security (by enabling location-aware path selection by the client). > > We’ve come up with the following suggestions for better terms, which we’d > like to offer up for discussion: > 1. '''onion service''' should be preferred to refer to what is now called a "hidden service". If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. > 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. > 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. > 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. > 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent). > > We couldn’t decide on the best names for alternative onion service > setups, because they don’t exist yet! But, we have some ideas about how > these things might be named: > 1. Some names for a setup in which the onion service location is known but still must be connected to via the Tor protocol: > * '''Tor-required service''', '''TRS''' for short > * '''Direct onion service''', '''direct service''' for short > 2. Some names to specify that the onion service is hidden, if that becomes necessary: > * '''Protected onion service''', '''protected service''' for short > * '''Tor-protected service''', '''TPS''' for short > 3. Some names to specify that a client connects to an onion service non-anonymously: > * '''Client-direct access''' > * '''tor2web mode''' > > We’re maintaining an evolving wikipage with the above suggestions [1]. > Some of us are already beginning to use the suggested terminology, to see > how it works out. One nice goal might be for Tor to choose the new terms > that it likes (if any) and use them in the rollout of next-gen onion > services [2]. So we’re bringing up this subject now to a larger segment > of the Tor community. Thoughts? > > Best, > Aaron > > [0] Including David Goulet, Rob Jansen, George Kadianakis, Karsten > Loesing, and Paul Syverson > [1] > https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Termino… > [2] > https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0

Discussion on further hidden service statistics
by George Kadianakis 10 Feb '15

10 Feb '15

Hello, we recently started discussing about further statistics that we could measure about hidden services [0]. We believe that most of the interesting statistics should be collected using a relay-hiding statistics aggregation scheme [1], but we were also thinking of any stats that could be collected in a more short-term fashion. I will now enumerate the stats that Aaron considers interesting and low-hanging-fruit: (1) Number of descriptor updates (total count and distribution) (2) Number of RPs established on relays (3) Number of circuits using TAP and nTor (4) Number of descriptors with encrypted introduction points This time I'm going to put extra focus on how to use these statistics and _what questions they help us answer_. If these stats don't help us answer any interesting questions, they are not that useful. Also, this time we should have an *exact strategy* on how to use specific stats to derive the results we want, so that we don't spend 2 months after we write the code to figure out how to do extrapolations. So here are some first thoughts. For each statistic I also include the preliminary analysis from the stats tech report [2]: > (1) Number of descriptor updates (total count and distribution) (Sec. 4.2.4) > > Relays count how many descriptor updates they see per service. Assuming that stats > are published daily (which is not necessary), this is going to be a number between 1 and 24 > (since RendPostPeriod is currently one hour) and services pick a new directory after 24 hours > (see rendcommon.c:get_time_period()). > > Benefits > This could reveal overall HS descriptor stability, which reflects the frequency of events causing descriptor updates, such as changing IPs or changing authentication keys. Also, this could reveal client errors or DoS attacks on HSDirs. > > Risks > Depending on how many HSes are behind each HSDir, this statistic might or might not reveal uptime information about specific services. Still it doesn’t seem like something we want to risk. Also, if the result is greater than 24, it means that an HS with modded RendPostPeriod was publishing to that HSDir (and that the HSDir doesn’t have many clients). Do we want to reveal that? OTOH, it seems to me that if the directory is serving many services, this statistic doesn’t really provide any insight. In addition, this could be used to reveal the 9introduction points used by a hidden service (assuming its address is known, but its descriptors are encrypted) by DOSing suspected IPs and observing in the responsible HSDirs report a higher number of descriptor updates. > > [ohmygodel] Obfuscating this number by the maximum amount of descriptor updates per service that we would expect (so, 24) would provide reasonable privacy for the update frequency of any individual service while still providing a sufficiently accurate estimate of the average number of updates. This statistic would also be easily improved via anonymous statistics reporting. > I'm not yet convinced this is a useful stat. What is its use and which *questions* would it help us answer? I'm assuming that we would total count here, since revealing the exact distribution could leak information about specific hidden services. Also, this is related to the "Number of unique HSes per HSDir" statistic that we are already doing. This means, that we can do the division and arrive to "Average number of descriptor updates per HS". I'm not sure if I like this, since there are *specific* HSes corresponding to each HSDir. Are we sure that there are not edge-cases that this can be exploited to learn their uptime? I'm not. > (2) Number of RPs established on relays > Number of RPs established on relays (Sec. 4.3.3) > > Relays report how many ESTABLISH_RENDEZVOUS cells they received. > > Benefits > The number of received ESTABLISH_RENDEZVOUS cells indicates how many connection attempts there are by clients to services that are running. This number is different from the number of descriptor fetches which happen when clients don't know yet whether a service is running, which will be omitted if clients still have a descriptor cached from a previous connection, and which we may not even gather because of privacy concerns. We can easily weight the number of ESTABLISH_RENDEZVOUS cells with the probability of choosing a relay as rendezvous point to estimate the total number of such cells in the network. > > Risk > This should be reported with a time delay so that it is unlikely that any existing rendezvous connections included in the statistic. Otherwise, it is possible that the adversary could attempt to disrupt existing connections at the RP as a DoS. > > [ohmygodel] This seems straightforward and useful to collect, and it is closely related to the number of data cells at an RP, which we are already collecting. OK, I can see how this stat would give us the number of "connection attempts there are by clients to services that are running". Is this a number we are interested in? I guess so maybe. It seems related to the "How many hidden service clients are there?" question, which is obviously interesting, but it's not exactly there. This stat seems more innocent to collect for the simple reason that clients pick RPs at random, so they don't correspond to specific hidden services like HSDir stats do. However, there is again a correlation between "Number of RP cells" and this one. This would give the "Average number of cells per rendezvous circuit". To be honest, this might be a more interesting statistic than "number of RPs established", but it's more closely related to the application data of the hidden service circuit, so it should be analyzed with more scrutiny. A relay-hiding statistics aggregation scheme would make this statistic easier to collect. > Number of circuits using TAP and nTor > > Older clients (0.2.3.x) would build/extend circuits using TAP, newer clients would use nTor for that. IPs and RPs can report the number of introduction circuits that were built using either of the two methods. More precisely, relays would remember for each circuit how it was built, and as soon as they receive an \verb+ESTABLISH_INTRO+ or \verb+ESTABLISH_RENDEZVOUS+ cell, they increment one of two counters. See ticket 13466 for details. > Benefits > We would learn what fraction of clients and what fraction of services run older tor versions (0.2.3.x or older). > Risks > As tor-0.2.3.x gets less common and only a few hidden services still use it, an adversary would be able to track their introduction points by checking which relays still report TAP clients on their statistics. > > [ohmygodel] We should be able to hide the effect of circuits from any > one HS or client by adding obfuscation. Having IPs report statistics > could reveal unknown IPs, however. Also, why not have all relays > report this in addition to RPs? That seems useful and easy. This statistic can reveal other information too since it's basically a circuit count. For example, if you count and publish the number of circuits containing ESTABLISH_INTRO, you get the "Number of IPs established on the network" statistic. If you count and publish the number of circuits containing ESTABLISH_RENDEZVOUS, you get the "Number of RPs established on relays" statistic I discussed in the previous section. Also, why do we care how many hidden services are using older versions of Tor? And why do we care how many clients are using older versions of Tor? Is this to specifically detect botnet activity? Also, why do this just for hidden services? > Number of descriptors with encrypted introduction points > > Relays can look at published hidden-service descriptor and count descriptors with plain-text vs. encrypted introduction point sections. > > Benefits > We would learn what fraction of services uses authentication features. This statistic won't be available after implementing rend-spec-ng (224) > > Risks > There is no obvious risk from sharing this number if aggregated over a large enough time period. > > [ohmygodel] Both the benefit and risk seem low here. Roger mentioned this statistic as being interested to him; maybe we should implement it for that reason alone. This seems like a stat that would answer a very concete question "How many hidden services are using authorization currently?". Answering this question seems useful for evaluating the user base and popularity of this feature. However, I'm not sure if I want to learn this information at all. People who use hidden service authorization are cautious users, and it seems weird to count them like this. It might be okay if there are 10000 of these hidden services, but if there are only 100, I wouldn't want to out them like this. More thinking required. [0]: https://lists.torproject.org/pipermail/tor-dev/2015-February/008228.html [1]: https://lists.torproject.org/pipermail/tor-dev/2015-January/008086.html [2]: https://people.torproject.org/~karsten/volatile/hidden-service-stats-2015-0…

2 1

Is Bridges supposed to get a gurard flag?.
by Sasikantha babu 10 Feb '15

10 Feb '15

Hello All, I've been running a non-exit relay at home and a bridge on amazon cloud since dec-2014. And today I had noticed on atlas my bridge has got a guard flag and from the logs in the last 18 hours it had sent 4.73 GB and received 4.89 GB (finally I'm happy to see bandwidth being used on bridge). I've the following questions 1. Is a bridge supposed to get a guard flag ?. 2. Is there a difference between a guard flag of a relay and a guard flag of a bridge?. Thanks

1 0