tor-dev June 2017

tor-dev@lists.torproject.org

32 participants
27 discussions

When to exit 0 on error
by f55jwk4f＠vfemail.net 25 Jun '17

25 Jun '17

I noticed tor sometimes exits 0 on error, specifically in monitor_owning_controller_process in src/or/control.c: if (owning_controller_process_monitor == NULL) { log_err(LD_BUG, "Couldn't create process-termination monitor for " "owning controller: %s. Exiting.", msg); owning_controller_process_spec = NULL; tor_cleanup(); exit(0); } and in try_locking in main.c: r = try_locking(options, 0); if (r<0) { log_err(LD_GENERAL, "No, it's still there. Exiting."); exit(0); } When to exit 0 on error?

3 5

Problems on torrc.d-style configuration directories
by iry 22 Jun '17

22 Jun '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone! I met some troubles when testing the new torrc.d-style configuration directories feature (https://trac.torproject.org/projects/tor/ticket/1922). Could anyone share some ideas on the problem, please? I will be really appreciated. The following is what I did: 1. add the following line to /etc/apt/sources.list.d/torproject.list: deb http://deb.torproject.org/torproject.org tor-nightly-master-jessie main 2. update Tor to nightly version: sudo apt-get update 3. tor --version: Tor version 0.3.1.3-alpha-dev (git-a73d0fe9a87df762+b433dff). 4. sudo mkdir /etc/tor/services-available 5. sudo cp anon-connection-wizard.torrc /etc/tor/services-available/ 6. sudo mkdir /etc/tor/services-enable 7. sudo ln -s /etc/tor/services-available/anon-connection-wizard.torrc /etc/tor/services-enable/anon-connection-wizard.torrc 8. reload tor 9. since bridges are used in the anon-connection-wizard.torrc, when we use arm to check the connections, tor should connect to one of the bridges, if torrc.d style configuration worked. However, it didn't work. I also tried to remove the /etc/tor/torrc, and tor could not find a torrc file anymore. The latest related discussion on the ticket is as follows: > Weasel and I (aka Hans) sketched out how we would use it in the > Debian package, closely following the Apache pattern but with > naming that is more appropriate in Tor: > > /etc/tor/torrc:: %include /etc/tor/services-enabled/*.torrc > %include /etc/tor/instances-enabled/*.torrc > > These dirs are present for the actual snippet files: > /etc/tor/services-available /etc/tor/instances-available > > These dirs include relative symlinks to *-available: > /etc/tor/services-enabled /etc/tor/instances-enabled > > For example: /etc/tor/services-enabled/sparkleshare.torrc --> > ../services-available/sparkleshare.torrc > > The sparkleshare package would include: > > /etc/tor/services-available/sparkleshare.torrc > > The davical package would include: > > /etc/tor/services-available/davical.torrc So I assumed it still worked. Could anyone please help me point out what I have done wrong? Or could anyone please point me to some docs about the new feature? I can see the source code of core Tor and write some docs on this, if this will be helpful, btw :) I really appreciate your help! Thank you! Best, iry -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZRvsbAAoJEKFLTbxtzdU86OkP/REdnsdcJJHoGyTdyXYoqJ6n NgW3cKlEGjCZF5bxIQ+lIG6q85j3EfflPDov97VrVyCE8xr6TFG0dDs/sE4rPE/h GjYhBzM1WC5o55vyvdehTh80wl3/hSj/LehCJLOpBKAjoxuzeDHtyrkd3LG22y8i mi93wgfxBuEbqvstDVipWfJt/5JbBLtXS/QainQqFwwFHRxJpIZcSgvWR5UAXAyS IQLW7m91lwl9W/irQvhM8d4nnk0ciTGMPKoyEt3FWHs9jP9ewKvIvWlxJVYZEefW LlLHMVzbyqWZWnkLkCBNyBfZZ0Rk16YFrUuMkTUH83LO/kBSlWFOj3idN5gYwda/ aanJhtopLH1u1nP10TqF6c4e6Bu6tfCOUh8sdOp8s7iB7MJHvaPU3lJM1vDk55u1 +fSxcDOm7NuN7xrJ3elUKS+oeOU8Ah4h43L/9lJgrIZ6zdIdI1f0E4QXlIWbKIbf dkQJrG760R/6jG6JMnbiOFPwoFelLna1hX6USpbnVEfhh33n3t/t5EpK5kH/q2m9 /lCkMcBpa5XXVquGaeCCQ+2X4wQ31wlhka12GADtVkq3SohOnfKzRauJYN8OcHZH eNZlDMbO8j3y9IHEdM+mhT8a7XnnZokFINSjmjnOnAQdk8A8QjB5V/TIZQB1uJwd 1uUyayVwl9SQHy3P6yuH =SLHC -----END PGP SIGNATURE-----

3 2

[release] metrics-lib 1.9.0
by iwakeh 21 Jun '17

21 Jun '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! Another planned release of metrics-lib is available: https://dist.torproject.org/descriptor/1.9.0/ The last release preparing the non-backwards compatible changes to come in version 2.0.0. The top three changes: * Simplify DescriptorReader by returning Descriptor instances rather than DescriptorFile instances containing Descriptors, and add a File reference to Descriptor. * Introduce a new UnparseableDescriptor to be returned by DescriptorParser and DescriptorReader if a descriptor cannot be parsed. * Let DescriptorParser return an Iterable instead of a List, which prepares parsing large descriptor files descriptor by descriptor. For more details see the changelog [1]. Please direct comments and questions to the metrics-team mailing list [2]. Cheers, iwakeh [1] https://gitweb.torproject.org/metrics-lib.git/plain/CHANGELOG.md?id=descrip… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZSnx7AAoJEPeEx9Sa/gviQ80QAK9m1muFju1dFqdPM6k6R76z O5XyYWUndNcWQhvZ8wYNM1UjAWalhRnuPBVBFp1wkBtywOnH7YWAerXwtK8s/t2s 3QSmR9eMPSjmDKD07QzRxaiwSmW276qUFvkRt71EGTCI0Cz4PF5RnBCuhUxbjtQa c38k6v2l7ZfYpfMPLhuPgtuLZCFDIOXAp48q1xCReHAltsOEskOh8zUarDF9+Ivr BD0o8Wc4GSEl7rQcVTEz+iaheYWJOV5C02oMSBPltdCxP7ug0y+OiNlucRe29OeG 7dUfDF1PrufCQY1Bs1Q5/ny07xpW5ARG07goalcRz2KhJCUkj/fVUAK+kOqN+s2t NrzVSgkMLyp7NEEKwZ/ZdEZQ/hv14ksLA0L3P8ru1pvGSa/RPV+LFwu4AzAvfWHJ m3JNcfJwM0CpWZPtQFjSYlseYh9Ogr9VAFENV4F+8YwgCUGnX02BSFV+B0T0AVw4 okwzY4W8jjaSjBDkp+lNE+0VEq3We5vSXKJTaHXV4Eic9kXxNEs7jqsbY2DsA0gp 4/JNSziXCmTCchajEKUDFUyBGhrbQ153klff8kyC/OkZ8Z6mben8Y8isSgC9Qydc li1anXWlXMklf6wj0cGQCP4Ovi07rUcMrx/6gTngyIQ5xOmGTUHbE3y0T1w+VTw0 G+MpWFQxiGWnVoZG20vj =NFWS -----END PGP SIGNATURE-----

1 0

Tor master branch is now 0.3.2.x
by Nick Mathewson 19 Jun '17

19 Jun '17

Hi! Quick heads-up: development on the 0.3.1.x series is now in the maint-0.3.1 branch. The master branch is now for the 0.3.2.x series. So if you're fixing a bug in 0.3.1, base your patch on maint-0.3.1 (or some appropriate earlier maint-x branch) ... and use master for new features. Confused? See doc/HACKING/CodingStandards.md for info on how we use git. cheers, -- Nick

1 0

Are we planning to use the "package" mechanism?
by Nick Mathewson 19 Jun '17

19 Jun '17

With proposal 227 in 0.2.6.3-alpha, we added a way for authorities to vote on e.g. the latest versions of the torbrowser package. It appears we aren't actually using that, though. Are we planning to use it in the future? -- Nick

4 3

Extending Tor stats to cover anon OSs?
by bancfc＠openmailbox.org 18 Jun '17

18 Jun '17

@TPO devs Since you do a great job safely collecting useful stats on the network, would you be open to adding a self-identifying anonOS distro option to the protocol? Would this be OK or is it mission creep? On the flip side it would be much more accurate than anything we can do to estimate active user base. Some ideas: *The distro name options could either be hard-coded values (for example TAILS, Whonix...) or a custom one chosen by downstream maintainers. *Distro maintainers would enable it for Tor clients via torrc.d

2 1

[release] metrics-lib/DescripTor 1.8.2 minor bugfix
by iwakeh 16 Jun '17

16 Jun '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! Oh, well, another bugfix release of metrics-lib/DescripTor is available: https://dist.torproject.org/descriptor/1.8.2/ This release fixes a problem introduced in 1.8.0; more detail can be found in the changelog [1]. The error didn't lead to data loss as it was discovered timely. Affected instances of Onionoo and CollecTor (in the realm of torproject.org) are being updated at the moment. Please direct comments and questions to the metrics-team mailing list [2]. Cheers, iwakeh [1] https://gitweb.torproject.org/metrics-lib.git/plain/CHANGELOG.md?id=0917016… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZQ/1kAAoJEPeEx9Sa/gviPtYP+QGo4cIdMo9ev8W7E/2SRdC7 gcfEOUZE1RCapm6IkFHboslgb5saEFE952wAhFomWunC9df1TByKTLVPiJsVmOf+ Q7WbQh0zZF1W9BkgwIFGCGLhfm2kuLFwXeNHEJ2h73+aKlOvvKv1Lz13e+VCfzLK jWqsygqVBE3rPloJOOF8CBWWIL0OOzLbWWcp1sUouFUVX1kDpXZZoZ8BsOD3pPH4 oyqyhNbbRwqvGqvt/38RDra80QK2vUtwxi6rxYTildWFRF0l/VLqJEjhgzZBE4z+ kZkc6elnd8Y7F2rlKQY6sHQbDDRbAzcnIsanBkBM8+TzAQVV9crRnoCsuewk93bg K4p2VDqwc9p6ehotnSJ74dCV0ValNSkqRZyawrJi9xViDS6i3yaaswbMog4lzmh/ sMKjMwLYVD3GiV0uIOlz/okyuJBi1DCbV6LgQF5DkFvlhX7eqPQXXSLYeDkYtLcJ +8PZ0fXg3uJjja1I8yrAaaoyh0VRtWGkl0xNMLCY9vLSA6uazWMsk36kME8iODt+ hmvQ2Nml6DylrumhORaOI8jb2Ezy5ME4OkCRbGxTrKCYJ0DN64LGZsumoKOxKqfl m1L4gqIw1UDwL0vGE330rk+ndIoRRKr5F9/I5f0pAClHG4D63UUXNGFniIfb2SLy erda0PO7N8KJ7zKOn/nq =zB9B -----END PGP SIGNATURE-----

1 0

Summer 2017 Internship to Create a Bridge Bandwidth Scanner
by isis agora lovecruft 16 Jun '17

16 Jun '17

Hello all! I have made a brief post on our blog to announce an exciting intership opportunity we have available! https://blog.torproject.org/blog/summer-2017-internship-create-bridge-bandw… Best, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

4 7

The limits of timing obfuscation in obfs4
by David Fifield 12 Jun '17

12 Jun '17

Web page with graphics: https://people.torproject.org/~dcf/obfs4-timing/ I was experimenting with ways to better obfuscate the timing signature of Tor-in-obfs4, while staying compatible with the obfs4 specification. I tried to make a constant bitrate mode that sends 500 bytes every 100 ms, in which the size and timing of obfs4 packets is independent of the TLS packets underneath. It turns out that obfs4 mostly makes this possible, with one exception: a gap in the client traffic while the client waits for the server's handshake response, during which time the client cannot send anything because it doesn't yet know the shared key. Currently, the implementation of obfs4 sends data only when the underlying process (i.e., tor) has something to send. When tor is quiet, obfs4 is quiet; and when tor wants to send a packet, obfs4 sends a packet without delay. obfs4 does add a random amount of padding to its packets, which slightly alters the packet size signature but not the timing signature. Even the modes that add short interpacket delays (iat-mode=1 and iat-mode=2) only really have an effect on bulk upload/download—they don't have much of an effect on the initial handshake. See the first three rows of the attached graphic—the timing of the first dozen or so packets hardly varies across the three modes. This design, where obfs4 only sends packets when driven by tor, is an implementation choice and isn't inherent in the protocol. obfs4's framing structure [spec §5] allows for frames that contain only padding: +------------+----------+--------+--------------+------------+------------+ | 2 bytes | 16 bytes | 1 byte | 2 bytes | (optional) | (optional) | | Frame len. | Tag | Type | Payload len. | Payload | Padding | +------------+----------+--------+--------------+------------+------------+ \_ Obfs. _/ \___________ NaCl secretbox (Poly1305/XSalsa20) ___________/ obfs4 could send padding frames (at whatever size and rate) during the times when tor is quiet. The current implementation, in pseudocode, works like this (transports/obfs4/obfs4.go obfs4Conn.Write): on recv(data) from tor: send(frame(data)) If it instead worked like this, then obfs4 could choose its own packet scheduling, independent of tor's: on recv(data) from tor: enqueue data on send_buffer func give_me_a_frame(): # never blocks if send_buffer is not empty: dequeue data from send buffer return frame(data) else: return frame(padding) in a separate thread: buf = [] while true: while length(buf) < 500: buf = buf + give_me_a_frame() chunk = buf[:500] buf = buf[500:] send(chunk) sleep(100 ms) The key idea is that give_me_a_frame never blocks: if it doesn't have any application data immediately available, it returns a padding frame instead. The independent sending thread calls give_me_a_frame as often as necessary and obeys its own schedule. Note also that the boundaries of chunks sent by the sending thread are independent of frame boundaries. Yawning points me to this code in basket2 that uses the same idea of independently sending padding according to a schedule: https://git.schwanenlied.me/yawning/basket2/src/72f203e133c90a26f68f0cd33b0… I attach a proof-of-concept patch for obfs4proxy that makes it operate in a constant bitrate mode. You can see its timing signature in the fourth row of the attached graphic. With this proof of concept, I'm not trying to claim that a constant bitrate is good for performance or for censorship resistance. It's just an example of shaping obfs4's traffic pattern in a way that is independent of the underlying stream. The fifth row of the graphic shows a more complicated sine wave pattern—it could be anything. You will however notice an oddity in the fourth and fifth rows of the graphic, a gap in the stream of client packets. This is what I alluded to in the first paragraph, where after the client has sent its client handshake but before it has received the server handshake, the client doesn't yet know the shared key. Because every frame sent after the handshake needs to begin with a tag that depends on the shared key, the client cannot send anything, not even padding, until it receives the server's reponse. During this time, the give_me_a_frame function has no choice but to block. k = ephemeral key p = random amount of padding m = MAC signifying end of padding a = authentication tag d = data frames The obfs4 client handshake looks like this [spec §4]: k | p | m The server doesn't reply until it has verified the client's MAC, which proves that the client knows the bridge's out-of-band secret (this is how obfs4 resists active probing). The server handshake reply is similar, with the addition of an authentication tag: k | a | p | m (different values than in the client handshake) This means that no matter how you schedule packet sending, the traffic will always have this form, with a ...... gap where the client is waiting for the server's handshake to come back: client kpppppm......ddddddddddddddddddddddddddd server .......kapppmddddddddddddddddddddddddddd There isn't a way to completely remove the client gap in obfs4 and still follow the protocol. A future protocol could perhaps remove it (I say perhaps because I haven't thought about the crypto implications) by changing the client's handshake to have a second round of padding, which it could send while waiting for the server to reply: k | p | m1 | p | m2 [spec] https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4…

1 0

.onion name resolution with Blockstack
by Jude Nelson 11 Jun '17

11 Jun '17

Hello, I have written a PoC for using Blockstack names to resolve hidden services. Blockstack is a portable decentralized naming system that currently runs on top of the Bitcoin blockchain. Similar to systems like Namecoin, each Blockstack node retains a 100% replica of all name state, including mappings between globally-unique human-readable Blockstack names and the .onion addresses they resolve to. The code and tutorial is hosted here: https://github.com/ jcnelson/blockstack-tor. It works by using the Python stem package to rewrite the target address of a stream from a Blockstack name to a .onion address (similar to how Jesse Victors' OnioNS system works). We plan to add support to the stdin/stdout protocol in Prop279 as well. Best, Jude Nelson -- *JUDE NELSON* *ENGINEERING PARTNER @BlockstackLabs*

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev June 2017