tor-dev

tor-dev@lists.torproject.org

3581 discussions

Proposals should have reviews. Let's make sure that happens. Here's a schedule.
by Nick Mathewson 29 Jan '16

29 Jan '16

So, one of the longstanding problems with Tor's (change) proposal system has been that proposals sit around for a long time without sufficient discussion or approval. When they're about to be implemented, we do an informal "hey did anybody look at that?" check, but that's not really good enough. Here's what I've been thinking of doing, as discussed at the tor dev IRC meeting yesterday. 1. Everybody who will review proposals* should nominate one or two proposals currently in state "Open" or "Draft". People should nominate proposals that they themselves didn't write. 2. I'll schedule review & discussion sessions, about one per week, trying to hit times where interested people can make it. Everybody who will review proposals* should try to show up if they can, having read the proposal or proposals under discussion for that week. Then we talk about the proposal(s)! 3. We'll try to move nominated proposals towards "Accepted" or "Rejected", improving them as necessary. * I'm not going to be too elitist here, but: If you show up and contribute usefully to discussions, I will prioritize your nominations more than I will prioritize nominations from people who don't contribute so much. This is a draft process, so we'll try to see after a month or two (possibly at the next face-to-face dev meeting?) how it's going. Here's the schedule I have in mind for the first meeting, based on proposals already nominated at the IRC dev meeting. I'm going to go a bit aggressively for the first couple of weeks, so that we can get a sense of how this process works out. Everything is subject to change. We'll be putting notes online from these meetings. Tuesday January 19: 11am Eastern (1600 UTC) Guard node proposals! We'll be talking about these proposals: Prop#259: New Guard Selection Behaviour [DRAFT] Prop#241: Resisting guard-turnover attacks [DRAFT] Prop#247: Defending Against Guard Discovery Attacks using Vanguards [DRAFT] Friday January 22: 11 am Eastern (1600 UTC) Prop#251: Padding for netflow record resolution reduction [DRAFT] Monday January 25: 8pm Eastern (0100 UTC on Tuesday Jan 26) Prop#250: Random Number Generation During Tor Voting [DRAFT] Friday January 29: 8:30 am eastern (1330 UTC) Prop#252: Single Onion Services [DRAFT] Prop#260: Rendezvous Single Onion Services [DRAFT] Prop#246: Merging Hidden Service Directories and Introduction Points [OPEN] Also nominated are: Prop#264: Putting version numbers on the Tor subprotocols [OPEN] Prop#257: Refactoring authorities and taking parts offline [DRAFT] Prop#258: Denial-of-service resistance for directory authorities [OPEN] -- Nick

8 15

Fwd: [guardian-dev] RC-7 is out - try to repro? Re: towards reproducible Orbot
by Nathan Freitas 28 Jan '16

28 Jan '16

With this release and updates to our build process, we are close to having Orbot be reproducible. Otherwise, this should be the last RC for v15.1, and it now includes built-in Obfs4, Obfs3, Scramblesuit bridges from TBB, plus a few new ones from Nima. This will make it much easier for users in places who need bridges to be able to use them without taking an extra step. ----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: [guardian-dev] RC-7 is out - try to repro? Re: towards reproducible Orbot Date: Thu, 28 Jan 2016 10:12:59 -0500 On Wed, Jan 27, 2016, at 10:10 AM, Hans-Christoph Steiner wrote: > >>>>> Then anyone will be able to run this to verify the build: > >>>>> > >>>>> git checkout 15.1.0-RC-4 > >>>>> ./make-release-build > >>>>> ./compare-to-official-release ~/Downloads/Orbot-v15.1.0-RC-4.apk \ > >>>>> bin/Orbot-v15.1.0-RC-4.apk I've just posted RC7 built from make-release-build. I haven't attempted to run the compare script yet, so if someone out there wants to try, that would be great. My bet is that I didn't do something right, and it won't match, but I would love to be proven wrong! APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-7.apk Sig: https://guardianproject.info/releases/Orbot-v15.1.0-RC-7.apk.asc /** 15.1.0-RC-7 / 27-January-2016 / 91225ab053d0ffec4a414be461ee41e6465446bd **/ * fd45fa3 enable TransProxy and DNSPort by default without root - some users run their own iptables transproxy scripts with AFWall and n /** 15.1.0-RC-6 / 27-January-2016 / a8dbdacbcb2412bb08c4a665145371c3ac4abef1 **/ Fixes to enable/attempt reproducible builds for this release * 226d92e make-release-build: env vars need to be first on the command line * 20c16ae ignore more files generated by the build * 9883a89 faketime is only needed when building, not when cleaning * eaa2dde explicitly indicate we are building armeabi * 1b76c36 add make calls for both armeabi and x86 with clean * 75eb36e remove lib binaries * 3be93a0 only build for x86 and armeabi ...and one small UI bug: 1839b8f add-in missing "break" for Meek Google -- Nathan of Guardian nathan(a)guardianproject.info _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscribe(a)lists.mayfirst.org

2 1

Getting people started on guard selection algorithms [prop259]
by George Kadianakis 28 Jan '16

28 Jan '16

Hello Nick, isis and Mike! It seems like some Thoughtworks folks (from here on referred to as FRITO [0]) are interested in helping us with Tor hidden services development for 4 weeks or so. They start early next week! :) They were looking for a coding project that is tractable within a month given a team of four people. Also, it should be fun, interesting and be related to hidden services. One of the projects we discussed and found potentially fitting was proposal 259: https://gitweb.torproject.org/torspec.git/tree/proposals/259-guard-selectio… It is my undertanding that the next steps here involve implementing the various proposed algorithms and evaluating how they cope in some simulated scenarios. Nick and Isis started working on this in Python here: https://github.com/isislovecruft/guardsim You can find the scenarios that need to be tested here: https://github.com/isislovecruft/guardsim/blob/master/doc/stuff-to-test.txt This project seems quite suitable for the FRITO crew :) The idea here is that after we decide which one is the best algorithm to use, we would implement it for little-t-tor in C. The best algorithm is the one that achieves the greatest reachability and security tradeoff. The algorithm should also be designed in such a way that fits into the tor asynchronous networking API. It would be amazing if FRITO could help us here as well, but maybe we can start up with the Python simulation and see if they like the project! Isis and Nick, are you currently working on the guardsim code? Would you be OK if it was taken over by FRITO? Any advice for them? Also, is there a ticket we should be using for this project? If not, I will make one ASAP. Cheers! [0]: FRITO is derived from their names: Fan, Reinaldo, Ivan, Tania and Ola. They are all CCed. PS: We recently did a reading group about prop259 and a few other proposals that you might find interesting. The minutes can be found here: https://lists.torproject.org/pipermail/tor-dev/2016-January/010265.html and the raw logs here: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-19-16.03.log.html

2 1

Tor not affected by recent openssl security advisories
by Nick Mathewson 28 Jan '16

28 Jan '16

Somebody always asks whether Tor is affected by each OpenSSL advisory, so I'm sending this mail in order to get a URL to send people to. :) Here are today's advisories: https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html With respect to the first ( "DH small subgroups (CVE-2016-0701)" ), Tor is not affected because we set the SSL_OP_SINGLE_DH_USE() option. We started setting this option back in Tor 0.1.1.9-alpha, back in 2005. With respect to the second ( "SSLv2 doesn't block disabled ciphers (CVE-2015-3197)" ), Tor is not affected because we disable SSLv2 by setting SSL_OP_NO_SSLv2. We started setting this option in Tor 0.0.2pre8, back in 2003. Of course, other applications that you use over Tor may be affected, even though Tor is not; please remember to upgrade them as patches become available. best wishes, -- Nick

3 3

Proposal 247: Alternate Path Lengths
by Mike Perry 27 Jan '16

27 Jan '16

While discussing proposal 247 with George yesterday, we realized that we still get security benefit from additional ephemeral hops beyond the vanguards themselves. Recall the high-level 247 path design is: C - L - M - S -- S - M - L - H Where: C = Client L = Long lived Layer1 guard M = Medium lifespan Layer2 guard S = Short lifespan Layer3 guard H = Hidden Service (or hsdir) E = Ephemeral Hop (used below) I = Intro Point (used below) R = Rend Point (used below) The benefit to just one more hop is easiest to see in the Introduction Point case, where George and I reasoned that it probably is a good idea to pick an intro point that is not the same as the Layer3 (S) set, otherwise the hidden service is effectively publishing its Layer3 guards in its descriptor, and using those same nodes to connect to rendezvous points. Clients probably also do not want the multi-visit linkability of using their layer3 vanguards to directly connect to an HS intro point. This means the intro circuit becomes: C - L - M - S - E -- I - S - M - L - H Similarly, in the rend case, hidden services probably do not want to expose their Layer3 (S) guards quite so easily to a client's chosen Rendezvous Point, and again, the client probably does not want to use their Layer3 (S) guards as its Rendezvous point, to avoid visit linkability. This means we again have 8 hops for rends: C - L - M - S - R -- E - S - M - L - H Unfortunately, this is starting to get ridiculous. While there are clear security benefits here, I think 8 hops is definitely at the point where we can forget about voice and other interactive traffic behaving reasonably. So what could we cut, if we wanted to? Well, going back to the Prop247 threat model, we want the adversary to perform at least two attacks: a Sybil and one or mode node compromise attacks. So maybe we can (in some cases, or optionally?) eliminate the M nodes from the path. Since the linkability risks may be acceptable for some applications, maybe we can also optionally allow clients or servers to omit the ephemeral hop. This basically gives us three options for path lengths. Let's consider each path type: Hsdir post/fetch: 1. C - L - M - S - E - H 2. C - L - S - E - H 3. C - L - S - H Intro: 1. C - L - M - S - E -- I - S - M - L - H 2. C - L - S - E -- I - S - L - H *3. C - L - S -- I&S - L - H (* IP Intersection attack!) Rend: 1. C - L - M - S - R -- E - S - M - L - H 2. C - L - S - R -- E - S - L - H 3. C - L - R&S -- S - L - H Looking at these, we can see that we sacrifice the middle guards in the second option, which will come at the cost of one less compromise attack (but still the need to compromise the long-lived guard). We also lose the unlinkability in the third option, and this actually bites us in Intro 3: the hidden service L guard can perform a long-term intersection attack, watching for published intro points and matching that to the circuits that H makes to them. So that path length probably should not be used. But what about the others? Especially that Rend case? I really like the security properties of the full 8 hop paths, but it seems to me that for highly-interactive applications, we can provide the option for users to give up some of the unlinkability in exchange for that 4 hop circuit, which might actually allow for e2e hidden service voice and video to have a shot at working. Are there any risks with paths this short for that case? Does it make sense to provide users with these different path length and latency options? I'm thinking that the service could list its preferred path length in its hsdesc, and the client could override that as it chooses (either for more or less security). Is that dangerous? We were already considering letting users choose their guard set sizes. Why not path lengths also (or instead)? -- Mike Perry

3 8

Notes from 3rd Tor proposal reading group [prop250]
by George Kadianakis 27 Jan '16

27 Jan '16

Hello there, yesterday we held another reading group on #tor-dev to discuss proposal 250 (Random Number Generation During Tor Voting). You can find the logs here: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-26-15.58.log.html Here are some code and spec changes that we need to do after discussion with Nick: Code & spec changes: - Remove ed25519 keys from code and spec. - SHA256 -> Keccak - "SUGGESTION: On 3.1.1, wouldn't it just be easier to sort the R_b in ascending order and use them in HASHED_REVEALS?" - "Why does REVEAL put the TS first and COMMIT puts it last? (Still on 4.1.1)" Spec changes: - Specify TIMESTAMP better in spec - Fix base32 commits in proposal - Specify what happens during SRV generation when there is no previous_SRV - Remove the XXX in 3.1.1 since it's taken care of - Document the phase determination logic better. - Remove MUST paragraph from 3.1.2

1 0

Proposal xxx: Filtering malicious rendezvous points at hidden service server side
by s7r 26 Jan '16

26 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Inspired by asn, dgoulet and Mike Perry discussing alternate path lengths for proposal 247, I wrote a proposal that could fit in nicely with proposal 247, maybe even allow us to make the 3rd hop wild (random) so we don't have to worry about HSDirs + HSDir fetch/post circuits and introduction points + introduction points circuits linking short term layer 3 guards. Please find the proposal attached as well as inline for comments. Looking forward for reviews. If I've structured it wrong or something I apologize in advance - will do better next time. Filename: xxx-malicious-rendezvous-point-filter.txt Title: Filtering malicious rendezvous points at hidden service server side Authors: s7r [ 0x837FA52C81265B11 ] Created: 23 January 2016 Status: Draft 0. Definitions client = an user running Tor as a client, which connects to a hidden service. hidden service server = the Tor instance hosting the hidden service. rendezvous point = the relay which acts as the rendezvous meeting point in a circuit between a hidden service client and a hidden service server. 1. Motivation A hidden service circuit (rendezvous circuit) is always initiated by the client so the relay which should act as the rendezvous meeting point is selected by the client. We assume that any client can be an attacker and will try to make the hidden service server connect to a malicious rendezvous point under his control. The attacker is also a Sybil (holds an unknown % of the bandwidth in the Tor network). By making the hidden service server build many circuits to his evil rendezvous points, the attacker gets a high probability that the hidden service server will eventually pick his evil relays in a circuit, so the attacker will trivially perform a successful hidden service guard discovery attack or, with more luck, discover the real location of the hidden service server. The hidden service server can only defend itself by building a 3 hop circuit to the rendezvous point, but in practice this is not always enough. 2. Logic for filtering malicious rendezvous points To be able to make fair assumptions about which rendezvous point might be malicious or not we are going to use the probability theory and statistics, precisely the binominal distribution equation [0]. In simple words, we count and keep track of how many rendezvous circuits a hidden service server built and to which rendezvous points. Then, based on the weight (middle probability fraction) of each rendezvous point, we determine if one was insanely overpicked by clients. Think of this like: Alice plays a game with Bob in which Bob has the success probability to draw a certain number n%. In practice however, he shows a success rate of more than (n*2)% (2 times bigger), Alice assumes Bob is not playing nice and will refuse to play with him for the next 24 hours or so. Fast example: A hidden service server built 100 rendezvous circuits in the last 24 hours, out of which in 7 of them the rendezvous point was a relay with the middle probability fraction of 0.5%. We assume that rendezvous point is malicious and refuse to build rendezvous circuits to it for the next 24 hours. 3. Equations and formulas 3.1 Probability of different clients genuinely picking the same rendezvous point n = total number of established rendezvous circuits. k = number of clients that could have genuinely picked the same rendezvous point. p = probability of picking that rendezvous point per client (middle probability fraction of the relay) divided to 100. H = Probability mass function expanded. C = The result of the equation, the value we need to determine multiplied with 100 to have the percent value. Formulas: H = n! / k!^(n - k)! C = H * p^k * (1 - p)^n - k Example: n = 100 k = 9 p = 0.5% / 100 = 0.005 H = 100! / 9!^91! = 20023492720 C = 20023492720 * 0.000000000000000000001953125 * 0.63372, ~ 0.00000000002478376524710625 * 100, ~ 0.000000002478376524710625% 3.2 Expected number of clients to pick the same rendezvous point n = Total number of established rendezvous circuits. p = Probability of picking that rendezvous point per client (middle probability fraction of the relay) divided to 100. We multiply this with 2 intentionally so we will allow 2 times more circuits than we would expect based on this formula - this should reduce the error margin enough. C = The result of the equation, the value we need to determine. Formula: C = n * p Example: n = 100 p = 0.5% / 100 = 0.005 * 2 = 0.01 C = 100 * 0.01 = 1 4. Implementation and variables We keep track in the persistent state of a hidden service server of the total number of built rendezvous circuits as well as a counter for number of rendezvous circuits per rendezvous point. Variables: REND_FILTER_MONITOR_PERIOD = count and track the rendezvous circuits built within this latest period. We set it to 24 hours. REND_FILTER_BAN_PERIOD = for how long we are going to ban a malicious rendezvous point. We set it to 24 hours. REND_FILTER_TOLERANCE = how many circuits we allow per rendezvous point regardless of its middle probability fraction. We set it to 4. REND_FILTER_BAN_ACTIVATION = when we should ban a malicious rendezvous point. To determine this, we are going to get from REND_FILTER_MONITOR_PERIOD the total number of established rendezvous circuits as well as the number of established rendezvous circuits with a given rendezvous point and apply the formula from 3.2 with approximation to the next whole number (example: 5.01 = 6; 5.99 = 6). Example: A hidden service server built 100 circuits in the last 24 hours out of which 5 to a rendezvous point with the middle probability fraction 1% (p = 0.02), so the expected number of circuits we expect is 2, but allow up to maximum 4 (if REND_FILTER_TOLERANCE > REND_FILTER_BAN_ACTIVATION, REND_FILTER_TOLERANCE prevails). In this case we consider this too much of a coincidence and ban this rendezvous point for the next 24 hours. We keep this ban in our persistent state with a timestamp so we'll know when it expires. 5. Ban malicious rendezvous points just for rendezvous circuits, not for anything else If we treat as relay as a malicious rendezvous point for a given time period, this only means we are not building circuits with it as the rendezvous point, but we don't exclude it for other purpose circuits, regardless which are those other purpose circuits. We may use them in our exit circuits, consensus fetch circuits, as HSDirs and HSDir fetch / post circuits, as Introduction Points or Introduction Point circuits. 6. Non zero probability to assign the malicious rendezvous point flag to an innocent relay This is indeed a non-zero value and it can be computed with the formula from 3.1, but it's a value so close to zero that we think it's totally worth it. Even if accidentally (low chances) an innocent relay will be banned, this will be something local to the hidden service server. It won't affect that relay at all, nor how other client or hidden service servers treat that relay. It has nothing to do with the network wide consensus as well. A honest client will always retry with a different rendezvous point, so honest clients should not experience reachability issues. 7. Rendezvous points that aren't included in hidden service server's consensus Clients and hidden service servers might have different consensuses. This means that a hidden service server can be genuinely asked to build a rendezvous circuit to a rendezvous point for which it has no middle probability fraction because it's not included in that consensus. We should allow REND_FILTER_TOLERANCE number of circuits to the rendezvous points for which we have no weights at all and if that rendezvous point appears in a later consensus within the REND_FILTER_MONITOR_PERIOD update its middle probability fraction value to ensure the filter will activate and work properly once REND_FILTER_TOLERANCE threshold was reached. 8. Security implications for maintaining such records in the persistent state of a hidden service server An attacker which compromises the location of a hidden service server will access this additional information: total number of rendezvous circuits built within the last REND_FILTER_MONITOR_PERIOD and to which rendezvous points these circuits were. This tradeoff should be worth it as well, since if the location of a hidden service server is compromised it is game over anyway, and this additional information shouldn't be so important to the attacker, except maybe for better determining the popularity of that hidden service (this can be determined many other ways, like the logs from the application running behind the hidden service, network counter, datacenter/ISP level counters and logs, etc.). To avoid co-location linkability between different hidden services, we should keep rendezvous circuits records and counters individually for each hidden service. The logic is designed to adjust by itself dynamically, based on the popularity and usage of a hidden service. If it's a high profile hidden service, experiencing 10000 connections per 24 hours, the REND_FILTER_BAN_ACTIVATION will increase for every rendezvous point. 9. Default option, with possibility to turn off for testing environments and experiments We add a new torrc option named HiddenServiceRendFilter 0|1 and set it to 1 by default. It can be turned off by setting it to 0, if this will be desired in some testing environments or experiments. 10. Other considerations, limitations and compatibility with other existing proposals This proposal won't disable an attacker entirely, but it will make it much harder and more expensive, given that the attacker will have to run more malicious relays to act as rendezvous points, increasing the capacity of the Tor network overall and directly the costs of the attack. Also, the attacker will have to grow the popularity of a hidden service so that he can establish more rendezvous circuits using the same rendezvous points. This will at least be kind of hard if other genuine clients pick the same rendezvous points and get noisy to the hidden service operator (much more traffic, same number or slightly more users on his service). This proposal is compatible with all the other hidden service related proposals to date. For tools like OnionBalance, each backend / fallback Tor instance included in the master hidden service descriptor will just transparently and individually maintain their own tracking vales and ban list. With proposal 260 - Rendezvous Single Onion Services this should be disabled since it makes no sense. Set HiddenServiceRendFilter 0 in a RSOS type hidden service. This proposal should be quite helpful once we implement enough padding between relays, where an attacker might have to own the entire path in order to distinguish dummy traffic from real traffic. This proposal should fit in nicely with proposal 247 - Vanguards and could make it safe to leave the 3rd hop wild (no layer 3 short term guards) and use only layer 2 medium term guards + layer 1 long term guard since an attacker will be able to establish less circuits to his malicious rendezvous point, thus drastically decreasing the chances of the hidden service server to also pick his malicious relay as 3rd hop to the malicious rendezvous point (layer 2 guards discovery). [0]: https://en.wikipedia.org/wiki/Binomial_distribution -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWo/K4AAoJEIN/pSyBJlsRAnMIAKFDDFm0DICrog1JecmrO82y N7dJf6tDURjGkUTr5i+mf91S4gTvxYigkT/tWTPH2E65XQGl2qLXo4d1+vgfaJmf H7QxUFy2kt+oFV03pg7SsF1KlMLaIVjlPMC17hPjAL8wnLMPkTICUn+VqWVYqmq+ w4uFPncm42mhkd3EwRq3HCrwq4O7PasWfSBYXmAuIJl6CWDkZqBI+UUj56dqQG6c zpWUMIZpfaMQzEJ438VhpVpiN19Ep5hIV5dJfz4MJ9eyhyas487nRXYyirEWqBs0 VXUsb/m/wgHICLjLukNYJ/+NZUk+Y5mIhL756HIiYUlL8UK85MaJhbozvjhqLnw= =tMjA -----END PGP SIGNATURE-----

5 13

Fwd: Orbot v15.1.0-RC-4
by Nathan Freitas 26 Jan '16

26 Jan '16

Orbot update with new built-in bridges (currently using the TBB default list, randomly shuffled!) and some other small fixes for the user interface, reproducible builds, and VPN feature. ----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15.1.0-RC-4 Date: Mon, 25 Jan 2016 22:48:01 -0500 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Fixes based on feedback from our RC-2 release.... this will be up on Play and F-Droid shortly, and from the link below right now. /** 15.1.0-RC-4 / 25-January-2016 / 80491ea95bd62346bf3f3a579d3302dbd84f4ca9 **/ APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk SIG: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk.asc Improve Bridge selection to support built-in default bridges * c235e3e tweak the string about bridges a little bit * 2a72814 choose up to 2 bridges from default list randomly * 1dbe5ea make bridge allocation shuffle randomly to distribute load inspired by this work: https://trac.torproject.org/projects/tor/tic * cf1a644 add support for loading default bridges from asset file VPN mode now uses Google's DNS (tunneled through Tor) as default * 9af00fe change VPN mode DNS to use Google's 8.8.8.8 Other UI fixes * ba83559 this should be kbps in fact * ab8709d add orfox icon to replace orweb * 6eb0a93 improvements to Locale changing in app * 0669add re-add appcompat, update to latest, move to Android 23 to build - this is required for latest appcompat, and to address the bu * c05d8e7 remove appcompat, and just support support-v4 Fix our stpcpy implementation to ensure no buffer overruns * 4913b0c better implementation of stpcpy for pre-Android 21 NDK Make the build process better and more reproduceable * 735b298 make-release-build: remove faketime from `ant release` * 461e35d make-release-build: freeze time when running ndk-build * 5c86b5c make-release-build: make sure ndk-build can be found * 58d53ea make-release-build: use strip-nondeterminism to get reproducible build * 5ce1f5f make-release-build: make sure tag signers exist before verifying tags * 72eab39 build jtorctl directly, using a symlink to point to its source code * a6ac016 use symlinks to provide alternate folders for Hebrew and Indonesian * 5fb4e9b update ndk-builds to NDK 4.8 toolchain - -- Nathan of Guardian nathan(a)guardianproject.info - -- Nathan of Guardian nathan(a)guardianproject.info -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.3.4 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJWpuxcCRCoARg+abN6qQAABa8P/2AlGCzBOBWhb4rVTvfE 64af8Pw031oJyyFDvtlUeETS1Ct95Zz7prP41ywhItPi/6eLCTwkbcbDA+Zl xDK6eSy6NhyMgh2qrC3US45HvQGjSCA7496IM5T3lL71wEL71sxAIaPh2abP 1akDEiXiJTnRUqFGui0aQkt0rJKQ0GShqJXmDM6qvuMCoiJSJ/ehc6Rnkyam 3/m4j5+IZ5JNpPKPDFjmW5cNFSDr+11SSdWlzjC9QfE8Ebo0rceMgpFASqH+ alzl6dB7y2rA+QeQcFQfwTlckKELq/cNofruV4UYmEIIlt/3dPZkIoIPlxBT i/ozTkmSPyEUurnxmAJQMVhergN/0WzGOWST5ceLABjjuVsoVrCZ7ai4eKiX M2zHxPQdjeLnc1HG5IXYLQcABJ9j9ol84oIH4VfcMPBCSjb205S42ChBx8Tm 9LGSSkn1i7JmVR2BaXaxmhbgoU5X+abumy3fH2uwDS5WCMDAExVw43sb8qM9 pGbDxK/wYd4aBaYZQK9VO7nA48eiv7yIw7uoKOhA7JFOnLg8he0DcngikCIx VNEqaO231Kgj1kN8Uc8+ombelRxb++997gnWfqE2ZHsEt3BpRpSAephJMJyq pxOeW/0tQL860oObACLjIp9xZ5FecZPWB4QqDEBRdOtT4MsgjDRP/Wty8Rzt UF2G =9Fk9 -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Release: obfs4proxy-0.0.6
by Nathan Freitas 25 Jan '16

25 Jan '16

On Mon, Jan 25, 2016, at 09:38 AM, Yawning Angel wrote: > benefit is that it is a lot easier to package than meek-client + the > external helper, and this can probably save binary size on things > like Android. Yes, I've been waiting for this. It is especially useful since we will be including both ARM and x86 builds shortly, so the size of PT storage in the app is already going to double. Thanks for the continued hard work on this. +n

1 0

Release: obfs4proxy-0.0.6
by Yawning Angel 25 Jan '16

25 Jan '16

Hello all, I just tagged obfs4proxy-0.0.6. There aren't many significant changes, and the internal changes primarily affect the client side initialization, so those of you that are perfectly content with obfs4proxy-0.0.5 can continue to use the existing version without issue. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6… Changes in version 0.0.6 - 2016-01-25: - Delay transport factory initialization till after logging has been initialized. - Add a meek client implementation (WARNING: Does not support using a helper to normalize TLS signatures). The brave people that want to use it can do so as the "meek_lite" transport, with identical bridge lines to the real meek-client. This means "It's blatantly obvious that you're using a HTTPS client written in Go because the ClientHello is rather distinctive". The benefit is that it is a lot easier to package than meek-client + the external helper, and this can probably save binary size on things like Android. An example bridge line would be: Bridge meek_lite 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com It has received moderate testing when I was on a business trip, and appears to function as intended, given the design constraints. There are minor internal API changes (which caused issues delaying the release) motivated by "meek's behavior is unlike most other transports" but I expect such things to be straight forward to those that actually hack on the code. Thanks to the person on Github for filing a pull request which saved me time debugging. Regards, -- Yawning Angel

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev