- tor-dev - lists.torproject.org

IDE for Tor?
by Lain Iwakura 15 Dec '15

15 Dec '15

Hello guys; Sorry such silly questions novice. But what IDE you use, and why? In Linux, of course. ... For C and python. I see Eclipse (Mars), but it seems more to own java. Codeblocks, perhaps? Excuse me still could not find me in the documentation. thank you : )

4 3

Reminder: Tomorrow's Wednesday Tor dev meeting is 1330 UTC!
by Nick Mathewson 15 Dec '15

15 Dec '15

---------- Forwarded message ---------- From: Nick Mathewson <nickm(a)freehaven.net> Date: Thu, Dec 10, 2015 at 2:49 PM Subject: Weekly Tor developers meetings; IRC time change! To: tor-dev(a)lists.torproject.org Hi, all! (This is about the IRC meeting on OFTC on #tor-dev to talk about developing the program called "tor".) We have have fewer people at the new Wednesday time than we did at the old one. That's not great. The Monday/Tuesday time is convenient for a bunch of folks, though, so that's nice. So for next week at least, we will move Wednesday earlier to be closer to the old time, and keep Monday/Tuesday as it is. That makes the meeting times: TUESDAY 0100 UTC (== 8 pm eastern on Monday. No change.) WEDNESDAY 1330 UTC (==0830 am eastern on Wednesday. Changed.) There's no need to show up to both, but you can if that's convenient. If both are equally convenient for you and you only want to do one, please favor the Wednesday one. One of the topics at the next meetings will be Good Meeting Times and Getting More People to Come. If you want to talk about meeting times, but neither of these times will work, just send me a note or find me online so I know. Let's keep trying till we get this right! cheers, -- Nick

1 0

apparmor in lxc containers [#17754]
by Peter Palfrader 15 Dec '15

15 Dec '15

Hi Intri, https://bugs.torproject.org/17754 reports that tor no longer works in LXC containers. I have set up an ubuntu wily VM, and a wily LXC container in it, and I can confirm that with the AppArmorProfile= line in the service file, tor will not launch. Do you have any ideas how to properly fix this? Or what the best workaround would be to document? Thanks, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/

3 2

Summary of meek's costs, November 2015
by David Fifield 14 Dec '15

14 Dec '15

Here's the summary of meek's CDN fees for November 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 July 2015 $732.01 + $837.08 + $0.00 = $1569.09 August 2015 $656.76 + $819.59 + $154.89 = $1631.24 September 2015 $617.08 + $710.75 + $490.58 = $1818.41 October 2015 $672.01 + $110.72 + $300.64 = $1083.37 November 2015 $602.35 + $474.13 + $174.18 = $1250.66 -- total by CDN $8045.93 + $8461.45 + $1120.29 = $17627.67 grand total https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… The number of users is holding steady at around 4,000–5,000. meek-google had an outage as a result of a server migration between 23 November and 4 December. If you want to set up your own bridge and CDN instance without rate limiting, I can help you do it. Here are some docs to look at: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-server… https://trac.torproject.org/projects/tor/wiki/doc/meek#GoogleAppEngine https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure == App Engine a.k.a. meek-google == Here is how the Google costs broke down: 2162 GB $259.52 6856 instance hours $342.83 Compared to the previous month: 2842 GB $341.06 6619 instance hours $330.95 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Asia Pacific (Singapore) 39M requests $47.84 361 GB $52.28 Asia Pacific (Sydney) 1M requests $2.24 4 GB $0.64 Asia Pacific (Tokyo) 16M requests $20.27 106 GB $13.78 EU (Ireland) 122M requests $146.93 736 GB $58.25 South America (Sao Paulo) 3M requests $8.43 11 GB $2.71 US East (Northern Virginia) 78M requests $78.74 535 GB $42.01 -- total 263M requests $304.45 1755 GB $169.67 https://globe.torproject.org/#/bridge/F4AD82B2032EDEF6C02C5A529C42CFAFE5165… == Azure a.k.a. meek-azure == Zone 1 1467 GB $126.31 Zone 2 350 GB $47.87 -- total 1817 GB $174.18 https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html https://lists.torproject.org/pipermail/tor-dev/2015-April/008596.html https://lists.torproject.org/pipermail/tor-dev/2015-May/008767.html https://lists.torproject.org/pipermail/tor-dev/2015-June/008932.html https://lists.torproject.org/pipermail/tor-dev/2015-July/009030.html https://lists.torproject.org/pipermail/tor-dev/2015-August/009213.html https://lists.torproject.org/pipermail/tor-dev/2015-September/009533.html https://lists.torproject.org/pipermail/tor-dev/2015-October/009672.html https://lists.torproject.org/pipermail/tor-dev/2015-November/009941.html

1 0

Help me help you : )
by Lain Iwakura 11 Dec '15

11 Dec '15

Hello guys; My name is Lain, I'm from Brazil. only it's not my real name. :) And I love it. I identify a lot with the Tor project, and would like a simple guideline. I work with programming (Pascal) in the last five years, I want to contribute to developing the project. but do not know where to start, take that language, which would be more effective my acting. ... something that a veteran is tired of doing I could do, and learn from that expedite the work. Anyway, give me some tips. Hey! I am learning English for that. help me to be useful. :)

3 3

Bitcoin-paid hidden meek relays?
by Jacek Wielemborek 11 Dec '15

11 Dec '15

List, I'm starting this thread in relation to the following discussion: https://security.stackexchange.com/questions/107490/how-will-france-block-t… I definitely don't have a perfect knowledge of Tor, so correct me if I'm wrong at any point. I heard that Tor entry nodes right now are distributed to users as IP addresses, which are scarce resources that could be blocked. In order to make this more difficult, pluggable transports were introduced - those try to use other protocols to define communication with Tor network, lowering the cost of introducing new way to connect with it. One that particularly caught my attention is Meek, which uses CDNs to evade censorship. CDNs share same IPs for many critical Internet serices, so blocking them is not an option and having them behind TLS makes it even more complicated. The problem I noticed though is that the costs of Meek go up and if I read the reports from David Fifield (the maintainer of Meek), the bandwidth has to be limited to avoid abuse. This slows the transport down and I thought of another approach. Instead of using a limited amount of Meek nodes, we could encourage users to run those on their own and distribute them in a way similar to regular Tor entry nodes. The catch would be that those nodes would require a small Bitcoin pre-payment that covers the cost of bandwidth used. The node would require the user to pass some proof of payment during the connection and not respond at all if there was no payment made. Here's an example way this could work: 1. User sends a message to bridges(a)bridges.torproject.org with a request for a meek bridge and a GPG public key attached, 2. The bridge service replies with a Bitcoin address created just for the user, 3. As soon as the user sends any Bitcoins, it receives another e-mail with the hostname of the Meek relay and a token that one should use Together with Amazon AWS, this could be an automated solution to the bandwidth and payment problem that would result in short-lived relays that are difficult to detect. What do you think about it? Hopefully I didn't mess it up in the fundamentals and this could actually help any little. Cheers, d33tah

5 5

Weekly Tor developers meetings; IRC time change!
by Nick Mathewson 10 Dec '15

10 Dec '15

Hi, all! (This is about the IRC meeting on OFTC on #tor-dev to talk about developing the program called "tor".) We have have fewer people at the new Wednesday time than we did at the old one. That's not great. The Monday/Tuesday time is convenient for a bunch of folks, though, so that's nice. So for next week at least, we will move Wednesday earlier to be closer to the old time, and keep Monday/Tuesday as it is. That makes the meeting times: TUESDAY 0100 UTC (== 8 pm eastern on Monday. No change.) WEDNESDAY 1330 UTC (==0830 am eastern on Wednesday. Changed.) There's no need to show up to both, but you can if that's convenient. If both are equally convenient for you and you only want to do one, please favor the Wednesday one. One of the topics at the next meetings will be Good Meeting Times and Getting More People to Come. If you want to talk about meeting times, but neither of these times will work, just send me a note or find me online so I know. Let's keep trying till we get this right! cheers, -- Nick

1 0

Hidden service patch workshop on #tor-dev IRC channel (17/12/2015)
by George Kadianakis 10 Dec '15

10 Dec '15

Dear tor-dev, Everyone who is working on any kind of improvement to hidden services or related applications and would like to give or receive assistance (code reviews, advice, etc.) is welcome on: Thursday December 17, 16:00 UTC @ #tor-dev OFTC channel This might become a regular biweekly thing, if it proves to be successful. Cheers!

1 0

tor control port filtration with a series of tubes
by David Stainton 09 Dec '15

09 Dec '15

or-ctl-sieve - granular bidirectional control port filtration https://github.com/david415/or-ctl-sieve or-ctl-sieve does what it says on the tin and comes with a handy config file that we use with arm (tor-arm): https://github.com/david415/or-ctl-sieve/blob/master/tor-arm-filter.json I wrote this in Tubes... the new async message passing API for twisted... and this caused me to draw the this ASCII diagram of the flow graph: https://github.com/david415/or-ctl-sieve/blob/master/or_ctl_sieve/sieve.py#… cheers, david

1 0

Better relay uptime visualisation
by Philipp Winter 08 Dec '15

08 Dec '15

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 a binary sequence) is highly correlated. Check out the following gallery. It contains monthly relay uptime images, dating back to 2007: <https://nymity.ch/sybilhunting/uptime-visualisation/> If you aren't familiar with this type of visualisation: Every image shows the uptime of all Tor relays that were online in a given month. Every row is a consensus 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. A nice example is the Heartbleed incident: <https://nymity.ch/sybilhunting/uptime-visualisation/slide_2014-04.html> The huge red block on the left shows all the relays that were removed by the directory authorities because they didn't rotate their key pairs in time. The downside of single-linkage clustering is that it takes longer to compute. On my laptop, I can create an image covering one month in under three minutes, so it's tolerable. Another practical problem is that it's cumbersome to learn the relay fingerprint of a given column. I'm looking into JavaScript/HTML tricks that can show text when you hover over a region in the image. Perhaps somebody knows more? [0] <https://bugs.torproject.org/12813> [1] <http://nms.csail.mit.edu/papers/clustering-imw2002.pdf>, Section 2 Cheers, Philipp

6 13

tor 0.2.7.5 make error
by grarpamp 08 Dec '15

08 Dec '15

"Makefile", line <nums>: Need an operator make: fatal errors encountered -- cannot continue 6772:export TESTING_TOR_BINARY=$(top_builddir)/src/or/tor 6794:export PYTHON= 6795:export SHELL=/bin/sh 6796:export abs_top_srcdir=/tmp/tor-0.2.7.5 6797:export builddir=. This is on a FreeBSD 8.x from early 2014. The autotools is probably too old there. Haven't got around to supplying a better fix than commenting them out of .in and not using autoreconf -fiv. 8.x is EOL anyways.

2 2

Tor Messenger 0.1.0b4 is released
by Sukhbir Singh 08 Dec '15

08 Dec '15

We are pleased to announce another public beta release of Tor Messenger. This release addresses a number of stability and usability issues, and includes the default bridge configurations for pluggable transports. The initial public release [0] was a success in that it garnered a lot of useful feedback. We tried to respond to all your concerns in the comments of the blog post [1] but also collected and aggregated a FAQ of the most common questions [2]. * Before Upgrading Before upgrading to the new release, you will need to backup your OTR keys or simply generate new ones. Please see the following steps to back them up [3]. In our eagerness to build on work done by Tor Browser, we made the decision to store your profile directory inside the application bundle. This complicates matters when you want to use the same accounts and keys across updates, especially while we don't have an automatic updater [4]. Also, as was vociferously pointed out by some of our early adopters, this probably isn't a very intuitive user experience. Copying the extracted application to someone else's computer would unknowingly transfer your accounts and OTR keys. It's unclear if this is commonly done and we'd love feedback on this point to understand the urgency of the issue. In future releases, we plan on revisiting this decision. The number one item on our roadmap is porting Tor Browser's updater patches [5] so that keeping Tor Messenger up-to-date is seamless and automatic. We also plan to add a UI to make importing OTR keys and accounts from Pidgin, and other clients, as easy as possible [6]. * Downloads Please note that Tor Messenger is _still in beta_. The purpose of this release is to help test the application and provide feedback. *At-risk users should not depend on it for their privacy and safety*. Linux (32-bit) https://dist.torproject.org/tormessenger/0.1.0b4/tor-messenger-linux32-0.1.… Linux (64-bit) https://dist.torproject.org/tormessenger/0.1.0b4/tor-messenger-linux64-0.1.… Windows https://dist.torproject.org/tormessenger/0.1.0b4/tormessenger-install-0.1.0… OS X (Mac) https://dist.torproject.org/tormessenger/0.1.0b4/TorMessenger-0.1.0b4-osx64… sha256sums.txt https://dist.torproject.org/tormessenger/0.1.0b4/sha256sums.txt sha256sums.txt.asc https://dist.torproject.org/tormessenger/0.1.0b4/sha256sums.txt.asc The sha256sums.txt file containing hashes of the bundles is signed with the key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391). * Changelog Here is the complete changelog since v0.1.0b2: Tor Messenger 0.1.0b4 -- November 22 2015 All Platforms Bug 17492: Include default bridges configuration Use tor and the pluggable transports from tor-browser 5.0.4 Bug 17552: Instantbird should handle XMPP message stanzas with subjects ctypes-otr Bug 17539: Pass username when interpolating resent string Bug 15179: Add an OTR Preferences item to the Tools menu Use the FIREFOX_42_0_RELEASE tag on mozilla-release Use the THUNDERBIRD_42_0b2_RELEASE tag on comm-release Bug 16489: Prevent automatic logins at startup Update Tor Messenger logo in Tor Launcher Mac Bug 16476: Themes preference is positioned incorrectly Bug 17456: Application hang when navigating the preferences menu Tor Messenger 0.1.0b3 -- October 30 2015 Windows Bug 17453: Fix Tor Messenger crash when starting up in Windows [0] - https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily/ [1] - https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily/#c… [2] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/FAQ [3] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/FAQ#Whereare… [4] - https://bugs.torproject.org/13861 [5] - https://bugs.torproject.org/14388 [6] - https://bugs.torproject.org/16526 -- Sukhbir

1 0

Shared random value calculation edge cases (proposal 250)
by George Kadianakis 07 Dec '15

07 Dec '15

Hello there believers of prop250, you can find the latest version of the proposal in the upstream torpec repo: https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-… Implementation is also constantly moving forward as you can see in the ticket: https://trac.torproject.org/projects/tor/ticket/16943 Now that we have ironed out the whole voting procedure, it's time to finish this up by figuring out the last details of the shared random value calculation. The logic in the current proposal seems reasonable (see section 3.3), but I have some doubts that I wanted to communicate with you. - I'm afraid of edge cases where different authorities will calculate different shared random values. This is bad because if it happens at the wrong moment, it might break the consensus. For example, imagine that there are 5 authorities that are doing the prop250 protocol. Since there are 5 auths, they can create a valid consensus on their own with SR info in it. Now imagine that one of them, Alice, has a different view of the previous_SRV than the others (maybe because she _just_ booted up before voting and she doesn't have a previous consensus). In this case, Alice will calculate a different SRV than the other 4, and hence the consensus will break because 5 signatures could not be collected. Is this something likely to happen? If yes, a way to protect against it is to add a flag on the votes denoting support for the SR protocol, and have dirauths toggle it off if they are voting for 00:00UTC and they don't know the previous_SRV or if they don't have a consensus. This can also be used as a torrc-enabled killswitch, if the SR protocol bugs out completely and we need to disable it for the sake of the network. What do you think? - Another bothersome thing is the disaster SRV calculation. Specifically, the proposal says: =============================== prop 250: ==================================== If the consensus at 00:00UTC fails to be created, then there will be no fresh shared random value for the day. In this case, and assuming there is a previous shared random value, directory authorities should use the following construction as the shared random value of the day: SRV = HMAC(previous_SRV, "shared-random-disaster") where "previous_SRV" is the previous shared random value. =============================================================================== this logic is not implemented in the current code, and it's not straightforward to implement. Again because the previous_SRV is blended in the formula, but also because it's not easy to know that "the consensus at 00:00UTC fails to be created". For example, if you are a dirauth that just started up at 00:30UTC, and you asked for the previous consensus and you were given the 23:00UTC consensus, then you won't know that the 00:00 consensus was not created and that you need to do the disaster procedure. This will again break the consensus. Not sure if this is a likely scenario as well, and if we should protect against it. What do you think? It depends on the logic that authorities have for fetching consensuses. Do they ensure that they always have the latest consensus? Do we need to add such logic as part of prop250? :/ A way to protect against it is to use the "SR support" vote flag I talked about before, and toggle it off if you are a dirauth and you don't have the latest consensus. Terrible? Would that even allow dirauths to bootstrap SR? - Another interesting part of prop250 is: =============================== prop 250: ==================================== If the shared random value contains reveal contributions by less than 3 directory authorities, it MUST NOT be created. Instead, the old shared random value should be used as specified in section [SRDISASTER]. =============================================================================== do you think this is useful? The fact that we use consensus methods, ensures us that at least 5 dirauths understand the SR protocol, otherwise we don't do it. Should we care about the number of reveal values? And why should the constant be 3, and not 5 or 2? Those were my doubts. Sorry for the extra confusion, but I'm currently reading the proposal and trying to minimize the amount of edge cases that can happen in the implementation (especially if they result in breaking the consensus for everyone). Maybe I'm trying too hard, and there are already multiple such edge cases in the consensus protocol that just never happen and are not worth fixing. In any case, the shared random value calculation seems to be the last piece of the puzzle here, so let's figure it out and finish up! Thanks!

6 16

Graphs - Estimated Traffic Capacity
by David Goulet 07 Dec '15

07 Dec '15

Hello everyone! I would like to share this graph I've been working on along side with Aaron Johnson (thanks to him for the algorithm I'll be describing). This shows both the maximum additional and total traffic the network can sustain for both HS and Exit. The "additional" traffic here means that we consider the current load on the network thus the additional value is what can be added more on top of the current traffic. http://ygzf7uqcusp4ayjs.onion/tor-health/tor-health/bandwidth_capacity.html (Please ignore the initial downward spike, technical issue) Here is the algorithm we are using for this. It's in no ways an accurate value but rather an estimation as you will see with the following algorithm to compute the traffic capacity you see. 1. Using the latest consensus, build a list of relays that are Running, Valid and Fast (weight selection only picks relays with Fast flag). Then compute their positionnal consensus weights. 2. For each of them, set their total capacity to min(avg BW, observed BW). 3. For each of them, compute the unused capacity that is use the extrainfo descriptor read/write bytes history for the amount of traffic used and substract that to the total capacity. max(mean(write_history_values) / write_interval, mean(read_history_values) / read_interval) 4. For HS traffic, that is a 6-hops circuit, we go over all relays and find the relay that has the lowest unused capacity divided by it's probability of being picked in the Guard/Middle position: picked_prob = (guard_weight * 2) + (middle_weight * 4) unused = relay.unused_capacity / picked_prob We use time 2 here since there are two guards in the 6 hops circuit and 4 middle nodes. We get the minimum value between each relays. 5. The minimum "unused" value times the picked_prob is the amount of bytes that we'll give to all relays thus reducing their unused capacity: relay.unused_capacity -= (min_unused * picked_prob) At each iteration of the algorithm, this will make at least one relay go to 0 unused capacity so when this happens, remove that relay from the set of relays to be picked. Once we can't pick a relay anymore for the 6 hops circuit (that is no more guards or middle), we stop. 6. Add min_unused value to the total number of bytes. Goto step 4. Ok... this can maybe be not that trivial to understand at first, feel free to ask questions but the basic idea is that at each iteration of the algorithm you spread a specific amount of bytes to each relay depending on the probability of being picked until you have no more relays capacity for such a circuit. For the "Max Total" traffic, the relay.unused_capacity is equal to the relay capacity. For Exit traffic, we do the same logic but with a 3 hops circuit where each position is multiplied by 1 since there is one guard, middle and exit (in normal circumstances). I know that we have sometimes 1, 4, 5, 6 or 7 hops circuit but the general case is considered here and we have no stats on how frequent those unusual circuits are. Anyway, if you think this algorithm could be improved, please respond. If you think this algorithm is wrong, please respond. If you can reproduce the result on your own with this algo, omg please respond! :) The above could be totally wrong but hopefully we did a fairly good job. Please remember, this is an estimate. :) Thanks! David

5 7

metrics-lib 1.0.0 is released
by Karsten Loesing 05 Dec '15

05 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, I just released metrics-lib 1.0.0: https://dist.torproject.org/descriptor/1.0.0/ metrics-lib, which also goes by the name DescripTor, is a Java API that fetches Tor descriptors from a variety of sources like cached descriptors and directory authorities/mirrors. The DescripTor API is useful to support statistical analysis of the Tor network data and for building services and applications. # Changes in version 1.0.0 - 2015-12-05 * Major changes - This is the initial release after four years of development. Happy 4th birthday! Special thanks to iwakeh for helping with metrics-lib development over the past year including pushing for finally putting out this release! Happy descriptor parsing! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWYqQ2AAoJEJD5dJfVqbCrHjUH/2Yavypi6BK6F1R3bAyMfCUd t140r4FlH1FBOuWi9qt5p5fbkGroef7ttMHZz3cXqjUJWyfOC3TynB7g152hIflQ E6JeilxeCY62RiOpJ2nRF0KBAKmL1QyVinvE3USORXyT+RvPAhtVpNPU6A8AQlxn lUWsjeD7HNMn9s1VXy3O3m0fs3CGxflbwfbbS8kTP6OINu7nP5f3ldcAm2ykDB0R mG1BgkvGoamhuQmimWVv8S5c/N+pOPLN9La75kSC4BppgBAiD5MCP6zJHhkvMmAG h9ciWsZdAxuKjEdLVCIYRXkNIGAMLikr7HpYB5ewBu8tcGkBHQaCXweNA5sI0Po= =jY3h -----END PGP SIGNATURE-----

1 0

Have the Tor daemon use more cores
by Jeremy 03 Dec '15

03 Dec '15

On 12/02/2015 07:00 AM, tor-dev-request(a)lists.torproject.org wrote: >> >I've been working on the volunteer project described here >> >https://www.torproject.org/getinvolved/volunteer.html.en#useMoreCores >> >but can't spend much more time on it. >> > >> >Right now, I have refactored circuit_receive_relay_cell() in relay.c >> >(which calls relay_crypt() and eventually the AES crypt routines) to >> >use the workqueue.c infrastructure similar to cpuworker.c. >> > >> >When the refactored code runs in single threaded mode, all seems >> >good. Once I activate the thread pool and start sending it work with >> >threadpool_queue_work(), it Bootstraps 100% okay and runs for several >> >minutes before crashing on cells it doesn't handle properly. >> > >> >I'm happy to share my code with anyone interested. > Sure I think I'm the person that used the workqueue stuff last, so I'd > be up for doing the rest of the work (nb: I am traveling/in meetings for > the rest of the week, so it'll be next week at the earliest that I can > really spend quality time). > > Regards, > > -- Yawning Angel Yawning, or anyone else: If you assess the code has potential, I can assist & work on it more. If it is a big miss, then I might start with a smaller contribution. Thanks, Jeremy

1 0

txtorcon 0.14.2
by meejah 03 Dec '15

03 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With Twisted 15.5.0, a deprecated endpoint interface class is still being used. This release backports the fix for that to the 0.14.x branch. You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.14.2 https://github.com/meejah/txtorcon/releases/tag/v0.14.2 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.14.2.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.14.2.tar.gz.asc http://timaq4ygg2iegci7.onion/txtorcon-0.14.2-py2-none-any.whl http://timaq4ygg2iegci7.onion/txtorcon-0.14.2-py2-none-any.whl.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check fbc95c41e924b0e10156c46227eac2b4acf42a3b8d01f0ea3022897a10dc059a txtorcon-0.14.2-py2-none-any.whl f99819b1a71b8dea9e80317ec83c990b4ff608c98bc78a9fc1dc9991d349d13f txtorcon-0.14.2.tar.gz EOF thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWX3WRAAoJEMJgKAMSgGmnOasH/i3NuaGRXu/wgdSHwDldPCpt FCVFXN9RT8nTV8EN72V1iwqW0ir38YG8rM9TVNbImZlPFbMLaV0zJsb+rNId5xgb uNBnlzrzdJOtlgofg4aKHBHjvDioV4xrZiypzOOc5u2Hyd8xuOPkI3fEVx+QfaKA Cjbys6lCM2HZpeWkHlPKM3xnN9BoJ7IZodbv54fEehR5MgljkgwCoQJOdDy8tf9L FQmpDXb7ptNXqbHNUltg8zkyIt345u6XcvZWX8wCxVu4PHCucdUW0VWzq33dNCuA jbGvsesrJsr6+2a6wMq0FXJByaU1ymkwdp0OV55ASdNg5KBcfh4Sf4gMNiYGQw8= =bBHR -----END PGP SIGNATURE-----

1 0

Have the Tor daemon use more cores
by Jeremy 03 Dec '15

03 Dec '15

>> I've been working on the volunteer project described here >> >https://www.torproject.org/getinvolved/volunteer.html.en#useMoreCores but >> >can't spend much more time on it. >> > >> >Right now, I have refactored circuit_receive_relay_cell() in relay.c (which >> >calls relay_crypt() and eventually the AES crypt routines) to use the >> >workqueue.c infrastructure similar to cpuworker.c. >> > >> >When the refactored code runs in single threaded mode, all seems good. Once >> >I activate the thread pool and start sending it work with >> >threadpool_queue_work(), it Bootstraps 100% okay and runs for several >> >minutes before crashing on cells it doesn't handle properly. >> > >> >I'm happy to share my code with anyone interested. > Hi Jeremy! > > This is great! Thanks for this. You should definitely post your code (link to > branch or .diff) to ticket #7572 [1] so someone at some point can take a look > at it and help you out. > > Thanks! > David > > [1]https://trac.torproject.org/projects/tor/ticket/7572 > Thank you. I have posted my code and tried to explain my thought process on ticket #7572.

1 0

Scaling Tor Metrics
by Karsten Loesing 01 Dec '15

01 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, the Tor Metrics website [0] claims to be "the primary place to learn interesting facts about the Tor network" and invites its visitors who "come across something that is missing" to contact the website authors about it. That's a bold statement I put there! :) Yet, there's considerable product backlog with possible enhancements [1] that doesn't seem to ever become shorter. Even worse, it can be expected that the backlog will refill quickly once the community notices that feature requests are suddenly considered. The main reason for this unfortunate situation is that Tor Metrics contains many moving parts, including some heavy database lifting that takes place below the surface, that all want to be maintained. Adding more parts just makes the whole thing even more likely to break. At the same time, knowing about the situation that Tor Metrics has become almost closed to contributions is painful. This posting shall discuss possible solutions. The goal is to let Tor Metrics grow in a healthy fashion that encourages contributions from the community. These solutions are not mutually exclusive, and the best solution may use parts of more than one solution sketched out here. 1 Make Tor Metrics better and bigger, internally The obvious solution is that the maintainers of Tor Metrics could just work harder to overcome the problems stated above. Let's think this through. 1.1 Add more development resources If only the current Tor Metrics maintainers had more time to devote to cleaning up existing parts and to add new parts, that would solve our problem. They could refactor parts that are hard to maintain, and they could work off the serious backlog that has piled up. Of course, this means dropping or handing over responsibilities for other products, and it may mean finding (and paying) new developers to help maintain Tor Metrics. It's unclear whether anything like this would fit into Tor's budget, and whether these changed priorities would make users of tools that had to be dropped or handed over unhappy. 1.2 Rewrite internal parts of Tor Metrics to encourage external contributions Most of Tor Metrics would have run 10 or 15 years ago with only minor modifications. It's not necessarily a bad thing to use established technologies. But maybe, if we rewrite it using modern data-processing, web, and visualization frameworks, it becomes more attractive to other developers to contribute code and help maintain existing (well, then rewritten) code. The result would be a larger Tor Metrics website that is easier to maintain and hopefully maintained by more people. It's unclear how realistic this plan is, though, and it requires attention by Tor Metrics maintainers to bring it enough into shape for external contributors to get involved. 2 Add more ways to contribute to Tor Metrics externally It may be possible to further grow Tor Metrics without adding more code to it, hence not making it any harder to maintain. However, if code to generate visualizations is run elsewhere, there's a certain risk that results are not perceived as trustworthy as if that code were run as part of Metrics. This is primarily a problem of setting user expectations right. We could add different ways for contributing to Tor Metrics, depending on the level of commitment that contributors are willing to make. Possible new ways (in addition to filing a Trac ticket, which is already possible, though not very effective) are: 2.1 Accept contribution of static data or static graphs Somebody might contribute data (in a tarball, download link, etc.) or a static graph (static as in "doesn't break, ever", not "static HTML with a tiny amount of JavaScript that will surely never break"). The Tor Metrics team reviews that and puts it on the Tor Metrics website, together with a short description, author information, license, etc. There are plenty of visualizations on Trac and on the mailing lists, so we'll have to define criteria what we add and what not, and we'll need a good process for making that happen. 2.2 Link to external websites Somebody might write a website that visualizes Tor network data. The Tor Metrics team reviews the idea behind it, but not necessarily look at its code, and adds an external link to Tor Metrics. It becomes obvious that the authors remain responsible for their visualization, so there's no risk involved for Tor Metrics, but users may not trust it as much, because it doesn't have the Tor Metrics label. Note that we're already doing this approach by linking to the visualizations showing "Tor users as percentage of larger Internet population" [2] and "Data flow in the Tor network" [3]. Also note that we could as well have hosted the former directly on Tor Metrics with appropriate attribution, because it's a static image. This is not the case with the latter. 2.3 Run an externally developed website as if it were part of Tor Metrics Let's imagine that somebody produces a visualization of Tor network data and would like to make it part of Tor Metrics but without limiting themselves to the technology used by Tor Metrics. We could let them write their visualization as website and integrate it into Tor Metrics after reviewing its code. Technically, part of this integration would be to "redress" the website by applying the Tor Metrics design (which has lots of room for improvement, but let's just say the result will look as seamlessly integrated into Tor Metrics as the "Network bubble graphs" [4]). Another part would probably be to rewrite web requests, so that users still think they're talking to https://metrics.torproject.org/, but really they're talking to another webserver behind that. Regarding hosting and maintenance, in theory, the website could be hosted by the original creators, but that effectively means that the Tor Metrics team gives up part of the control about what's on the Tor Metrics website. The creators of the external website could change parts or add new parts that wouldn't be reviewed by Tor Metrics developers, but they would be perceived as part of Metrics, which seems bad. The Tor Metrics team could run the externally developed website on a separate host or on the same host as Tor Metrics. We could imagine variants where the original creator stays around to fix any issues as they come up, or we could imagine that they donate their visualization that the Tor Metrics people will then maintain. We could even imagine that the Tor Metrics maintainers some day decide to integrate the originally external website into Tor Metrics proper, but that would not be required for this model to work. All these ideas require writing down guidelines, criteria, and processes. In particular, they require more thoughts and input from other people who are not currently involved in Tor Metrics maintenance and who can be expected more objective. And once these ideas are implemented, we'll need more Tor Metrics maintainer than just one. What are your thoughts? All the best, Karsten [0] https://metrics.torproject.org/ [1] https://trac.torproject.org/projects/tor/query?status=!closed&component=Met… [2] https://metrics.torproject.org/oxford-anonymous-internet.html [3] https://metrics.torproject.org/uncharted-data-flow.html [4] https://metrics.torproject.org/bubbles.html -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWVdmJAAoJEJD5dJfVqbCrmlEH/j6IjRNEkXzRVJBIBcFMKIwR eAA958Zg+DCzKPHI6Y7KZ/jGCHMP21r+YGIFevbJV4LDos9D2G0RP681/5PK7/dW if4Pz0xhl/LqbhLoOSqU2wGJG+GdWgjuTxO1TBMPUhYK71lwJsZ0cUzbNee7iAqJ zjdl3W3o4XJma0ZjZFH/gVVPbemvQHftrO8d0v7L2gFHfXmJg0kEwSZ4lJW0hfOx wIizEadFSx9/7CrINvbcHbyck0N+DRSfRYyMNSjpyFbnYI7HjYk7/+jvLWALEYZT 0MZbuL/zl/PFpkTDNY0jzE5fPaKjtS2pEoZn85Wn1+0kCjeFLE/Hvulvn6ZFxsA= =n5p1 -----END PGP SIGNATURE-----

6 5

Have the Tor daemon use more cores
by Jeremy 01 Dec '15

01 Dec '15

I've been working on the volunteer project described here https://www.torproject.org/getinvolved/volunteer.html.en#useMoreCores but can't spend much more time on it. Right now, I have refactored circuit_receive_relay_cell() in relay.c (which calls relay_crypt() and eventually the AES crypt routines) to use the workqueue.c infrastructure similar to cpuworker.c. When the refactored code runs in single threaded mode, all seems good. Once I activate the thread pool and start sending it work with threadpool_queue_work(), it Bootstraps 100% okay and runs for several minutes before crashing on cells it doesn't handle properly. I'm happy to share my code with anyone interested. Thanks.

3 2

BridgeDB 0.3.4 is released
by isis 01 Dec '15

01 Dec '15

Hey, I've just tagged and released BridgeDB 0.3.4. For those interested, here are the changes (c.f. https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG) Changes in version 0.3.4 - 0.3.5 - 2015-11-30 * FIXES #14685 https://bugs.torproject.org/14685 This disables distribution of obfs2 bridges. This pluggable transport has known distiguishers which allow adversaries to identify client connections to obfs2 bridges, which in turn allows these connections to be blocked/censored. With numerous obfs3 and obfs4 bridges both readily available, users should not be presented with an easily-configurable choice that is known to be unsafe for the majority of users. And includes the following general changes: * ADDS error pages to BridgeDB's web interface, to provide friendlier explanations for downtime, missing pages, and internal server errors. For example: https://bridges.torproject.org/404 -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

[Applications Team] Meeting next Tuesday 19:00 UTC
by Georg Koppen 01 Dec '15

01 Dec '15

Hi, just a reminder that the applications team is having its monthly meeting next week on Tuesday, December 1 at 19:00 UTC in #tor-project on irc.oftc.net. There is no proposed topic for this meeting yet. Please come up with suggestions if you feel there is something we should discuss. See you there, Georg

2 1

BridgeDB 0.3.3 is released
by isis 01 Dec '15

01 Dec '15

Hello! I released BridgeDB 0.3.3 a few weeks ago, and deployed it on the production server. However, I completely forgot to email the list to notify you all of the changes. Oops, sorry! For those who are curious, BridgeDB-0.3.3 brought about the following changes (and, as always, the current changelog is available at https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG) Changes in version 0.3.3 - 2015-10-25 * FIXES #12029 https://bugs.torproject.org/12029 BridgeDB now has an API for creating Bridge Distributors. See the bridgedb.distribute module, or its developer documentation at https://pythonhosted.org/bridgedb/bridgedb.distribute.html. * FIXES PART OF #12506 https://bugs.torproject.org/12506 BridgeDB's two Distributors (HTTPS and Email) are now entirely modularised and self-contained within separate subdirectories in the source code. This is the first step to redesigning these Distributors into their own separate processes, which will allow the Distributors to remain functional while BridgeDB is reparsing bridge descriptors. * FIXES #15968 https://bugs.torproject.org/15968 BridgeDB now sends a Content-Security-Policy header which explicitly allows Javascript, images, CSS, and fonts, from https://bridges.torproject.org. All other types of content are forbidden, including: - embedding https://bridges.torproject.org within <iframe>, <embed>, or <object>, and attempting to source additional resources into its embedded context - inline Javascript, including Javascript within SVG files - inline CSS - externally hosted fonts - inline SVG, e.g. via the HTML5 <svg> tag - any and all connections made via Javascript XMLHttpRequests, WebSockets, sendBeacon(), and Web Workers - plugins - applets BridgeDB's Content-Security-Policy does not yet make use of certain newer, lesser supported, Content-Security-Policy v2.0 directives, such as "reflected-xss" and "frame-ancestors", but may someday. * FIXES #16273 https://bugs.torproject.org/16273 Several links to Tor Project gitweb URLs within the developer documentation were outdated in that they still used the old gitweb URL format. These are now updated. Thanks to David Fifield for the bug report and patches. * FIXES #16330 https://bugs.torproject.org/16330 BridgeDB can now handle bridge-server-descriptors with extra-info-digest fields which have two values, as well as both bridge-server-descriptors and bridge-extrainfo descriptors which contain Ed25519 key material and signatures. See Tor proposals #220 and #228 for more information on the changes to these descriptors. Note that BridgeDB can now parse this information, but does not yet make use of any Ed25519 cryptographic material within bridge descriptors. https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt https://gitweb.torproject.org/torspec.git/tree/proposals/228-cross-certific… Thanks to Atagar for patching Stem. * FIXES #16616 https://bugs.torproject.org/16616 The HSDir flag can now be included within bridge-networkstatus documents. BridgeDB now has unittests which guarantee that its parsers safely ignore this flag, as well as any flags unknown to BridgeDB which may appear in the future. Thanks to Roger Dingledine for alerting me about the change. * FIXES #16649 https://bugs.torproject.org/16649 Mobile users, and other users with small screen pixel ratios, will find that the UI of BridgeDB's HTTPS Distributor has greatly increased in usability and readability. And includes the following general changes: * FIXES an error when requesting the non-HTML version of the bridges page (e.g. https://bridges.torproject.org/bridges?format=plain) * REMOVES the `bridgedb test` commandline option. BridgeDB's tests can be run via `python setup.py test` or `make test` (or `make coverage` for generating HTML test coverage statistics). * CHANGES the HTTPS Distributor to HTML-encode Bridge Lines. Previously, a malicious Pluggable Transport Bridge could include in its PT arguments something like "evil=<script>[…]</script>" and if such a Bridge were to be distributed to a user, that user's web browser would execute the script (if Javacript was enabled). Other characters, including non-ASCII, control characters, double quotes, and backslashes, are also sanitised from Bridge Lines. Thanks to Robert Ransom for the patches. * CHANGES BridgeDB's module/package version numbers to be compliant with PEP440. * CHANGES the layout of BridgeDB's source code directories. Rather than storing BridgeDB's source in "lib/bridgedb/", it is now kept in "bridgedb/". Similarly, the directory containing BridgeDB's tests has been moved from "lib/bridgedb/test/" to "test/", which means that the tests are no longer installed when running `python setup.py install` or `make install`. * ADDS several improvements to the developer documentation at https://pythonhosted.org/bridgedb. * UPDATE English (en_US) translations. * UPDATE English (en) translations. * ADD Serbian (sr) translations. Thanks to obj.petit.a, Ivan Radeljic, and Milenko Doder. * UPDATE Arabic (ar) translations. Thanks to A. Hassan, debo debo, KACIMI LAMINE, and Nudroid A. * UPDATE Catalan (ca) translations. Thanks to laia_. * UPDATE Czech (cs) translations. Thanks to Tomas Palik and Vlastimil Burián. * UPDATE Danish (da) translations. Thanks to Mogelbjerg. * UPDATE German (de) translations. Thanks to jschfr, Junge Limba, and Toralf Förster. * UPDATE English (en_GB) translations. Thanks to Andi Chandler. * UPDATE Farsi (fa) translations. Thanks to some awesome anonymous person for helping out. * UPDATE Finish (fi) translations. Thanks to Riku Viitanen. * UPDATE French (fr) translations. Thanks to elouann, Trans-fr, and Towinet. * UPDATE French (fr_CA) translations. Thanks to Trans-fr. * UPDATE Croatian (hr_HR) translations. Thanks to some awesome anonymous person for helping out. * UPDATE Hungarian (hu) translations. Thanks to some awesome anonymous person for helping out. * UPDATE Indonesian (id) translations. Thanks to Anthony Santana, Astryd Viandila Dahlan, cholif yulian, constantius damar wicaksono, Dwi Cahyono, L1Nus, km242saya, and Zamani Karmana. * UPDATE Italian (it) translations. Thanks to Random_R. * UPDATE Japanese (ja) translations. Thanks to ABE Tsunehiko. * UPDATE Latvian (lv) translations. Thanks to Ojārs Balcers. * UPDATE Norwegian Bokmål (nb) translations. Thanks to Erik Matson and Kristian Andre Henriksen. * UPDATE Dutch (nl) translations. Thanks to Mart3000. * UPDATE Polish (pl) translations. Thanks to Karol Obartuch. * UPDATE Portuguese (pt) translations. Thanks to Bruno D. Rodrigues and MMSRS. * UPDATE Brazillian Portuguese (pt_BR) translations. Thanks to Communia. * UPDATE Romanian (ro) translations. Thanks to Ana, axel_89, and Di N. * UPDATE Russian (ru) translations. Thanks to Ivan. * UPDATE Slovak (sk_SK) translations. Thanks to StefanH. * UPDATE Albanian (sq) translations. Thanks to some awesome unknown anonymous person who didn't add their name to the list of translators. * UPDATE Swedish (sv) translations. Thanks to Peter Michanek. * UPDATE Turkish (tr) translations. Thanks to Bullgeschichte and Fomas. * UPDATE Ukranian (uk) translations. Thanks to Yasha. * UPDATE Chinese Mandarin (zh_CN) translations. Thanks to khi. * UPDATE Taiwanese Mandarin (zh_TW) translations. Thanks to x4r. -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Summary of meek's costs, October 2015
by David Fifield 29 Nov '15

29 Nov '15

Here's the summary of meek's CDN fees for October 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 July 2015 $732.01 + $837.08 + $0.00 = $1569.09 August 2015 $656.76 + $819.59 + $154.89 = $1631.24 September 2015 $617.08 + $710.75 + $490.58 = $1818.41 October 2015 $672.01 + $110.72 + $300.64 = $1083.37 -- total by CDN $7443.58 + $7987.32 + $946.11 = $16377.01 grand total https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… In October we had about 4,000 simultaneous users all month. There was an unfortunate outage of meek-amazon (not the result of censorship, just operations failure). Between 30 September and 9 October the bridge had an expired HTTPS certificate. [tor-talk] Outage of meek-amazon https://lists.torproject.org/pipermail/tor-talk/2015-October/039231.html https://lists.torproject.org/pipermail/tor-talk/2015-October/039234.html And then, as a side effect of installing a new certificate, the bridge's fingerprint changed, which caused Tor Browser to refuse to connect. It used to be that we didn't include fingerprints for the meek bridges, but now we do, so we didn't anticipate this error and didn't notice it quickly. Update the meek-amazon fingerprint to B9E7141C594AF25699E0079C1F0146F409495296 https://trac.torproject.org/projects/tor/ticket/17473 [tor-talk] Changed fingerprint for meek-amazon bridge (attn support) https://lists.torproject.org/pipermail/tor-talk/2015-November/039397.html Interestingly, the meek-amazon bridge still had about 400 simultaneous users (not as much as normal) during the time when the fingerprint didn't match. I would have expected it to go almost to zero. Maybe it's people using an old version of Tor Browser (from before March 2015) or some non–Tor Browser installation. Our grant for meek-azure ran out and now it costs money. Accordingly I've rate-limited it to limit costs. I set it to 1.1 MB/s on 2 October and to 0.8 MB/s on 30 October. [tor-talk] meek-azure now rate-limited https://lists.torproject.org/pipermail/tor-talk/2015-October/039169.html meek-google was also out for a few days around 30 October because I messed up the app upload and pointed it to the wrong bridge. If you want to set up your own bridge and CDN instance without rate limiting, I can help you do it. Here are some docs to look at: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-server… https://trac.torproject.org/projects/tor/wiki/doc/meek#GoogleAppEngine https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure == App Engine a.k.a. meek-google == Here is how the Google costs broke down: 2842 GB $341.06 6619 instance hours $330.95 Compared to the previous month: 2871 GB $344.53 5451 instance hours $272.55 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Usage of meek-amazon was quite low this month because of bridge outages having to do with an expired HTTPS certificate and a changed relay fingerprint. Asia Pacific (Singapore) 6M requests $8.24 36 GB $5.05 Asia Pacific (Sydney) 635K requests $0.79 1 GB $0.21 Asia Pacific (Tokyo) 1M requests $1.71 5 GB $0.71 EU (Ireland) 39M requests $46.81 130 GB $9.97 South America (Sao Paulo) 2M requests $4.98 5 GB $1.23 US East (Northern Virginia) 24M requests $24.36 86 GB $6.64 -- total 74M requests $86.89 266 GB $23.81 https://globe.torproject.org/#/bridge/F4AD82B2032EDEF6C02C5A529C42CFAFE5165… (Note new fingerprint.) == Azure a.k.a. meek-azure == Zone 1 1652 GB $202.51 Zone 2 586 GB $98.13 -- total 2238 GB $300.64 https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html https://lists.torproject.org/pipermail/tor-dev/2015-April/008596.html https://lists.torproject.org/pipermail/tor-dev/2015-May/008767.html https://lists.torproject.org/pipermail/tor-dev/2015-June/008932.html https://lists.torproject.org/pipermail/tor-dev/2015-July/009030.html https://lists.torproject.org/pipermail/tor-dev/2015-August/009213.html https://lists.torproject.org/pipermail/tor-dev/2015-September/009533.html https://lists.torproject.org/pipermail/tor-dev/2015-October/009672.html

2 2

does renewing ed25519 signing key hurt if done to often?
by nusenu 28 Nov '15

28 Nov '15

Hi, I'm wondering if it does any bad if ed25519 online keys are renewed (to) often (i.e. on every ansible-playbook run and the admin runs it 3 times in a row to get it to complete on all hosts). If key renewal causes all existing connections to die I'll try to workaround the problem and make tor --keygen idempotent (replace the key only if its expiry changed).

1 1