- tor-dev - lists.torproject.org

More tor browser sandboxing fun.
by Yawning Angel 22 Sep '16

22 Sep '16

Hi, Note: * Don't use this unless you are capable of debugging it. * Don't use this if you need strong security (though the author believes it is an improvement over unsandboxed Tor Browser, and the previous sandboxing attempts). * Don't re-package it, it's not ready for that. In addition to stewing in my infinite self-loathing, I made a serious attempt at sandboxing Tor Browser again. It works, is kind of neat, and isn't totally horrible, so I'm showing what's available. Where: https://git.schwanenlied.me/yawning/sandboxed-tor-browser This builds a lightweight launcher process that will: * Handle installing/updating Tor Browser, while being rather paranoid about having a good trust root (hard copies of PGP keys, the update service's cert chain, and the MAR signing key are included and enforced). * Run the updater in a sandboxed environment without network access. * Run Tor Browser in a sandboxed enviornment with the Tor SocksPort being the only way to get beyond the host. There's a bunch of caveats, and some functionality that's intentionally broken, and certain annoyances that require a Tor Browser patch or two to fix, but it appears to work fairly well. The README.md file has more detailed documentation on how it works, the sandbox environment, and the various caveats. -- Yawning Angel

3 5

More changes to CollecTor's sanitized bridge descriptors: sanitized TCP ports, tarballs per descriptor type
by Karsten Loesing 19 Sep '16

19 Sep '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, lots of changes to CollecTor's sanitized bridge descriptors these weeks. A few weeks ago there was the switch from Tonga to Bifroest change: https://lists.torproject.org/pipermail/tor-dev/2016-August/011336.html This message is about two unrelated changes that may impact whoever uses CollecTor's sanitized bridge descriptors. From the change log: - Replace TCP ports with hashes in @type bridge-network-status 1.1 and @type bridge-server-descriptor 1.2. - Split up bridge descriptor tarballs into one tarball per month and descriptor type: bridge-statuses-YYYY-MM.tar.xz, bridge-server-descriptors-YYYY-MM.tar.xz and bridge-extra-infos-YYYY-MM.tar.xz. You can find more details on the CollecTor page: https://collector.torproject.org/#bridge-descriptors Sorry for any inconvenience caused by this! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJX4APZAAoJEC3ESO/4X7XBZ70H/i854yW5aaAld294w/SRXG+f 3GzQYMs6CEikTcN8g5ZgYXyIYV1Bf+SuwfrZCwoLiKl8AqUY4gAxhj9ZbldkcFdu u3cGDJDM5qVmghCoIfpdq8BsqXpfk8PnyYhHSc8rmZaMG8hReKMUsKNO1Mp7BQHT a62n9PIV3CnZal43f5o3y/XssK/qY+CVlDtsnHzB1fEYap7txszgC9yXMlMeCuOn +eyDEkWo+EVQP2OLle+uvKLow7ywgXAsI7IwUQtU4l588cUlWv9UNkC6NYV4ydf0 8EwPqdGe7ecDvj/jsu9ZuK6LnZwmZChYep9nGTK1xC6LDDghRS9d6mnOnStCo14= =tv4B -----END PGP SIGNATURE-----

1 0

Please consider allowing /48 for VirtualAddrNetworkIPv6
by Alex Elsayed 17 Sep '16

17 Sep '16

Hi, I'm using Tor in transparent mode, and I'm running into a rather inconvenient behavior. VirtualAddrNetworkIPv6 refuses to parse unless the network address given is a /40 or broader. However, IPv6 ULA, which makes it very easy to give Tor its own subnet no-strings-attached, strictly grants a /48 prefix. As a result, I am faced with a choice between deeply suboptimal options: 1.) Use VirtualAddrNetworkIPv4, as I've done in the past. This results in _fewer_ addresses being available to Tor than an IPv6 /48, which I feel illustrates the issues with requiring a /40 quite clearly. 2.) Squat on some portion of the IPv6 address space I don't actually own. This is entirely unpalatable

3 5

OnionView : A GUI to view circuits & streams
by Kevin Steen 16 Sep '16

16 Sep '16

I wanted a way to watch the streams being created while using TorBrowser, so I've created a Python Tk GUI to show the circuits and their associated streams: https://github.com/skyguy/onionview Each circuit is shown with the relays' country codes and nicknames. Streams are listed below the circuit they're attached to, showing the domain name and resolved IP. The view scrolls automatically when a circuit or stream is first shown. It's quite simple, without any bells and whistles yet, but quite useful to see what's going on while waiting for a webpage to display, so I thought I'd put it out there in case someone else finds it useful. OnionView uses the excellent Stem library, so make sure you have that installed. It works with Python 2 and 3. All feedback and advice welcome! -Kevin

3 3

Reg:https-everywhere
by AKASH DAS 15 Sep '16

15 Sep '16

Respected all, Can I ask my doubts regarding https-everywhere and any bugs issue in this mailing list as I already posted one bug but I didn't get any reply regarding that error. So any help would be very helpful to me. -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity*

2 1

"old style" hidden services after Prop224
by Razvan Dragomirescu 14 Sep '16

14 Sep '16

Hello everyone, I've pretty much completed a proof of concept of my SIM4Things project (an IP6 overlay for the Internet of Things running on top of Tor with persistent secure cryptographic identities tied to physical SIM cards). I've developed against the current hidden service infrastructure and it appears to work like a charm, but I'm a bit worried about Prop224. That will break both the OnionBalance-like service re-registration that I'm using _and_ the OnionCat HS to IP6 mapping. I know that efforts are in place to upgrade the two in view of Prop224 but I'm wondering if there's any good reason to drop support for "old style" hidden services once Prop224 is fully deployed. What does everyone think? My vote would obviously be to keep it around, even if it's no longer the default. Do you see any security implications in doing so? Is there any hard reason to drop the existing model altogether at some point and if so, what is the plan for transition? My hidden services would be very low traffic (Internet of Things, sensor measurements, etc) but hard to upgrade in the field. Also, by design, we have no control over the endpoints once deployed (only their owner can access them), so we cannot force an upgrade, we can just suggest it to the owner and come up with a procedure for them to do so. Any ideas? Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

6 15

Tor path selection upon failure
by Liu, Zhuotao 14 Sep '16

14 Sep '16

Hi Folks, There have been some technical reports about how to deal with the problem when a botnet uses Tor as its primary C&C channel. In this case, the CPU of some relays is exhausted, causing circuit creation failure. I am wondering currently how a client reacts when its circuit creation fails? Does the client simply resends create cells to the relays on the original path or it will re-select a new path instead? Thanks

2 2

[Patch] common/util_bug.h
by Gisle Vanem 13 Sep '16

13 Sep '16

The 'IF_BUG_ONCE__' for non-gcc is wrong. A simple patch: --- a/util_bug.h 2016-09-13 10:44:59 +++ b/util_bug.h 2016-09-08 20:24:45 @@ -117,7 +117,7 @@ #else #define IF_BUG_ONCE__(cond,var) \ static int var = 0; \ - if (PREDICT_UNLIKELY(cond)) ? \ + if (PREDICT_UNLIKELY(cond) ? \ (var ? 1 : \ (var=1, \ tor_bug_occurred_(SHORT_FILE__, __LINE__, __func__, \ -- --gv

2 1

Tor path selection upon failure
by Liu, Zhuotao 13 Sep '16

13 Sep '16

Hi Folks, There have been some technical reports about how to deal with the problem when a botnet uses Tor as its primary C&C channel. In this case, the CPU of some relays is exhausted, causing circuit creation failure. I am wondering currently how a client reacts when its circuit creation fails? Does the client simply resend another create cell or it will re-select new path instead? Thanks

2 1

How to query HS hostname from control port
by Jesse V 10 Sep '16

10 Sep '16

Hi everyone, TL;DR: Please let me know how to fetch the hostname of my hidden service from Tor's control port. Say I have configured torrc to set up a hidden/onion service. By default, it's set up in /var/lib/tor/hidden_service, a directory which isn't world-readable. My software can authenticate into Tor's control port, but it needs to know the hostname/address of the service. It can't read the hidden_service/hostname file directly, and so far I haven't figured out how to query Tor for that information. As a last resort, I suppose I could copy /var/lib/tor/hidden_service/hostname to a directory that the software can read, but I'd like to avoid that if possible. I have hunted through https://gitweb.torproject.org/torspec.git/tree/control-spec.txt without too much success. The closest I have come is "GETCONF HiddenServiceOptions" but I suspect that the option is under GETINFO instead. However, the documentation mostly describes how to query information about other onion services. I need to know about my service though, if that's possible. Please advise. -- Jesse V I look forward to seeing everyone again in July at Minneapolis. :)

5 14

Hmac
by Flipchan 10 Sep '16

10 Sep '16

Hi all, so i spook with a friend of mine yesterday and we where chating about encryption and i told him that i use scrypt for password hashing. He told that hmac was alot better. Does anyone know any Good whitepapers on hmac? Any Good python lib? Does anyone use it ? Take care -- Sincerly Flipchan

3 2

Dirauth setting for PathsNeededToBuildCircuits
by Jesse V 09 Sep '16

09 Sep '16

Tor clients can only build circuits once they know enough about the network. This "know enough" threshold is determined by the PathsNeededToBuildCircuits setting. From reading Tor's manual, it seems that a setting of X tells Tor clients to wait until they have enough descriptors/microdescriptors such that they have X percentage of consensus weight. By default PathsNeededToBuildCircuits is determined by the directory authorities. I'm curious, how is PathsNeededToBuildCircuits set? I don't see that value in the microdescriptor documents, it doesn't seem to be documented in tor-spec, and I don't see much about it online, but maybe I missed something. What is the typical value? I see that 0.95 is the cutoff, but how high will prevent a client from bootstrapping? -- Jesse V

2 1

Bored C programmers? I've got some warnings for you....
by Nick Mathewson 08 Sep '16

08 Sep '16

Hi, all! I've just turned on some code [1] that makes all of the "bug" warnings that occur during the unit tests get logged to console. Previously, all warnings from the unit tests were off by default. Now there are a lot of warnings from the unit tests! For each one, we should either: 1) Decide that the warning message wouldn't actually reflect a bug in Tor, and change it. 2) Decide that there's a bug in the unit tests (or elsewhere) and fix it. 3) Decide that _in this case_, the unit tests are correctly testing code that *would* indicate a real bug in Tor. In this case, we should use the functions in log_test_helpers.c to temporarily suppress the log messages, and make sure that this message (and only this message!) is logged. This is going to be a fair bit of work, but with any luck, we can actually fix it all before the next 029 alpha comes out, and improve our confidence in our unit tests. [1] https://trac.torproject.org/projects/tor/ticket/20042 cheers, -- Nick

2 2

Post-quantum proposals #269 and #270
by lukep＠tutanota.com 08 Sep '16

08 Sep '16

Great to see the community making progress with post-quantum handshakes. But I'm wondering what's going to happen with Proposals #269 and #270. #269 seems to allow any post-quantum algorithm to be used in the hybrid with NTRUEncrypt and NewHope being specified as two options (presumably other options like SIDH or Mceliece could also be used). #270 is more specific, a hybrid of x25519 and NewHope. NewHope seems to be in the lead but do we want to rule others - so a flexible proposal like #269 might be better. #269 and #270 look as if they would not be compatible with each other so what's the process for deciding between them? Also see https://eprint.iacr.org/2016/717.pdf, a comparison of attacks on NTRU. It doesn't break NTRU but it does break (some versions of) YASHE which is a FHE scheme based on NTRUEncrypt. In the conclusion it recommends transforming NTRU-like algorithms into ring-LWE like algorithms, and dismissing the former since they are known to be weaker. I still think a flexible protocol rather than all eggs in the NewHope basket is a Good Thing. -- lukep

4 6

Pluggable transport idea: TLS session resumption
by David Fifield 08 Sep '16

08 Sep '16

Here's an idea for a new pluggable transport. It's just a TLS tunnel, but with a twist that allows the server's certificate to be omitted, depriving the censor of many classification features, such as whether the certificate is signed by a CA, the certificate's lifetime, and whether the commonName matches the server's IP address. I got the idea from ShadowsocksR: https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md#2%E6%B7%B7%… The trick that makes it work is RFC 5077 session tickets. How it's supposed to work is, the client makes a TLS connection as usual, and the server sends back a session ticket before beginning the flow of application data. The session ticket is just a random blob from the client's point of view; from the server's point of view it's an authenticated ciphertext that encodes session parameters such as the ciphersuite and master secret. The next time the client connects to the same server, it sends the session ticket along with its ClientHello and the server can skip sending its certificate. Here's a simple way to adapt session tickets for circumvention. The client *always* sends a session ticket when making a connection, even the very first time. The ticket doesn't come from a previous communication with the server; the client generates the ticket itself. The ticket could for instance be a random string--the censor wouldn't be able to distinguish--but we can also use those bits for other purposes. When the server receives the ClientHello, it *pretends* that the ticket was a valid one, and finishes the handshake using hardcoded session parameters, just statically configuring what it would have encoded into a session ticket. The protocol as just described would be vulnerable to active probing; the censor could test for servers by sending them garbage session tickets and seeing how they respond. But that's easy to fix. We can, for example, let the client and server have a shared secret, and have the server treat the session ticket as the client part of an obfs4 handshake--which conveniently resembles a random blob. If the session ticket doesn't pass obfs4 authentication, then the TLS server can respond as it naturally would if a client sent an invalid session ticket; i.e., issue a new ticket and do a full handshake (then send dummy data, I guess). The server can also honor its own legitimately issued tickets, but still send dummy data in response. Only clients who know the shared secret will be able to access the proxy functionality of the server. In order to block such a transport, the censor will have to look at features other than the server certificate. It could, for example: * block all session tickets (dunno how costly that would be) * statefully track which tickets servers have issued, and block connections that use an unknown ticket. * track the fraction of connections that use session tickets on each TLS server. * active-probe the server in order to get a certificate, and then look at certificate features. We'd have to do some research to find out the distribution of session ticket sizes in the wild. (RFC 5077 recommends a specific format: https://tools.ietf.org/html/rfc5077#section-4.) I didn't think of this idea; it comes from ShadowsocksR and its tls1.2_ticket_auth plugin. https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md#2%E6%B7%B7%… The documentation is in Chinese. Here is what Google Translate says in English: Analog TLS1.2 handshake at client has a session ticket situation is connected. Currently complete analog implementation, software testing through capture perfectly disguised as TLS1.2. Because there is no ticket so send certificates and other complicated steps, so the firewall can not make a judgment based on the certificate. At the same time it comes with the ability of certain anti-replay attacks. In case of a replay attack is searched end log in to the service, you can grep "replay attack" search, you can use this plug-in found in your area there is no line of interference for TLS. TLS relatively powerless firewall, anti-blocking ability than other plug-ins should be strong, but may also encounter a lot of interference, but the agreement itself will check out any interference, then disconnect encounter interference, to avoid long waits, so that customers end browser or reconnect themselves. This plug-in is compatible with the original agreement (the server is configured to require tls1.2_ticket_auth_compatible), one more than the original protocol handshake causes the connection will take longer, use C # client open automatically reconnect when performed better than the other plug-ins. Support for custom parameters, parameters SNI, it sends the host name field, this function is very similar to the TOR meet widget, for example, is set to cloudfront.net disguised as a cloud server requests, you can use a comma separate multiple host such as a.com, b.net, c.org (C # supports only), then it will randomly use. Note that error settings for this parameter may cause the connection to be disconnected even IP is blocked, such as how to set clear then please leave it blank. Recommended customized parameter settings to cloudflare.com or cloudfront.net. This is how a normal ticketless handshake looks (https://tools.ietf.org/html/rfc5246#section-7.3) ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data This is how the ticket-using transport would look: (https://tools.ietf.org/html/rfc5077#section-3.1) ClientHello (SessionTicket extension) --------> ServerHello NewSessionTicket [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data

2 1

Error in javascript:ISSUE#6761
by AKASH DAS 05 Sep '16

05 Sep '16

There is an error in the javascript syntax in https-anywhere which the test bypasses. I have issued it in the github link https://github.com/EFForg/https-everywhere/issues/6761. On Mon, Sep 5, 2016 at 10:49 PM, AKASH DAS <akash.d14(a)iiits.in> wrote: > If I have to make any patch in the code, do I have to submit it in this > mailing list or https-everywhere's mailing list? Just a doubt > > On Mon, Sep 5, 2016 at 10:35 PM, David Fifield <david(a)bamsoftware.com> > wrote: > >> On Mon, Sep 05, 2016 at 10:28:26PM +0530, AKASH DAS wrote: >> > Can I know the issues that are currently in https everywhere. >> >> I don't know if this is what you're looking for, but here are some open >> bug tracker tickets. >> >> https://trac.torproject.org/projects/tor/query?status=!close >> d&component=HTTPS+Everywhere%2FEFF-HTTPS+Everywhere >> https://trac.torproject.org/projects/tor/query?status=!close >> d&component=HTTPS+Everywhere%2FHTTPS+Everywhere%3A+Chrome >> > > > > -- > > *Akash Das* > > *Student Systems Admin* > > *Indian Institute Of Information Technology* > > *Sricity* > -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity*

1 0

HTTPS Everywhere
by AKASH DAS 05 Sep '16

05 Sep '16

Respected all, Can I know the issues that are currently in https everywhere. -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity*

3 4

Re: [tor-dev] [tor-talk] Onion Service introduction point selection
by George Kadianakis 03 Sep '16

03 Sep '16

Muhammad Hammad Mazhar <mmazhar(a)uiowa.edu> writes: > [ text/plain ] > I am looking into Tor onion services as part of my research, and am interested in how an Onion Service selects its introduction points, in particular where in source code does it do so. I am aware of rendservice.c in the source code, but any pointers are welcome. > > Please move this mail to the requisite list if required. > You were very close! Please see function rendservice.c:rend_consider_services_intro_points() and related code. [Moved to [tor-dev] from [tor-talk])

1 0

onionoo: poor reverse DNS results
by nusenu 02 Sep '16

02 Sep '16

Hi Karsten, some time ago I reported onionoo's poor reverse DNS results https://trac.torproject.org/projects/tor/ticket/18342 and it didn't change since then. As of 2016-07-02 08:00 (tpo instance) 3144 out of 8473 (~37%) still have no reverse DNS result (=IP address). Do you have an idea whether this will improve sometime before 2016-09-01? thanks, nusenu btw: Thanks for working around the maxmind AS problem with reverting to the May version.

2 2

txtorcon 0.16.1
by meejah 01 Sep '16

01 Sep '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very happy to announce txtorcon 0.16.1 which adds a couple minor features to help support using Foolscap and Tahoe-LAFS over Tor. * issue 172: give TorProcessProtocol a .quit method * issue 181: enable SOCKS5-over-unix-sockets for TorClientEndpoint (thanks to "dawuud"). Also adds TLS support over SOCKS5. You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.16.1 https://github.com/meejah/txtorcon/releases/tag/v0.16.1 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.16.1.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.16.1.tar.gz.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 d551837025bb9f4fdded58cd11025c6e42924b6eb20dcb2a49f182b3fd85f377 dist/txtorcon-0.16.1.tar.gz e89a785f64f3544b19f7b1e6cebdbd6914475e0c60f508d9f0b6ce4a840769a7 dist/txtorcon-0.16.1-py2-none-any.whl EOF thanks, meejah p.s. There is no 0.16.0 because I tagged the wrong thing and noticed when pushing to PyPI. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXx3TOAAoJEMJgKAMSgGmn7AEIAN5BQNqisxefMyKnHA8BCSZW UJpXPagnftg33HF2v4ZG/2yQUh8sYMqEn/OI99g8yA++bZmG9H0lJixg0zs6V2XV bX63zJ7d9lr+uu3D+crQNnmofcoUbLRX+Z7n5SWhgGtlsVqemIJton/cuedtnrXm 1E5VdjhxYIZ/2Qv0gTz7ZBYw0Hmkr24qwVufdblQHDov2SdM0kknInWqxFqVMLQd /p0+PTEF6SMdemHFkOJ73sCbINg6qLB4cErKaFY14U2cnS3Y1pZLhlEKFTzbd8TU SWtg1b9pn5s4Euq5ruYhNNIqVtQz/lrq0/ZQ+NKiLZ/L2rtw9xFY0nF1KhFTgLc= =IMj2 -----END PGP SIGNATURE-----

1 0

Bifroest's sanitized bridge descriptors available from CollecTor in 48 hours from now
by Karsten Loesing 31 Aug '16

31 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, if you're not using CollecTor's sanitized bridge descriptors for anything, you can safely ignore this message. As you may know, there are currently two bridge directory authorities in the Tor network, Tonga and Bifroest, and Tonga will go away some time this weekend. You can fetch sanitized versions of Tonga's bridge descriptors here: https://collector.torproject.org/recent/bridge-descriptors/ We're also now ready to provide sanitized versions of Bifroest's bridge descriptors. The only differences to Tonga's descriptors are: - Statuses will have Bifroest's fingerprint in their file name rather than Tonga's. Example: https://people.torproject.org/~karsten/volatile/20160829-164232-1D8F3A91C37… - There will be two "concurrent" statuses published by Tonga and Bifroest this week, containing two distinct sets of bridges. I'm holding back Bifroest's descriptors from CollecTor for another 48 hours or so to give you time to prepare for this change. After all, you might have written your code under the assumption that there's just a single bridge authority, and the above change might confuse your code and break it. Everything will be on CollecTor in 48 hours from now. All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXxHytAAoJEC3ESO/4X7XBMfAIAKXADVnMGK5rYmbZN5ymF2M8 IbFc/6VWV+CoUdss868Dp5/Y3huE6SgFXCe3A+R+jCg5Od8rIiWKEfNvVeLEXpU1 DtuYNAq3vlhVhHTOdWmCz2uRVeWNddb12RDa+H55QtGHC4JC8HP9PRSN+lLj5fBr YBuKvLAWfMOsfdAqVJwHmmhtORPag7wL2NWmmk/y4j9JCzQ//NmUv3CMdIQm+j98 pM5jwI6ogiec2f/Nbij3eSJHCAhHKuL5TKR6E+//TE/s4ZGBKDPxkw+w/PdQrViC A3RgDVm7sqrjKkm2jWHVEuTa36QdzBgpV6vH1tEmTrHTz7Epre3MVFwKR607LBM= =gXT3 -----END PGP SIGNATURE-----

1 1

metrics-lib/DescripTor 1.4.0 is released
by Karsten Loesing 31 Aug '16

31 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, we just released metrics-lib/DescripTor 1.4.0: https://dist.torproject.org/descriptor/1.4.0/ - From the change log: # Changes in version 1.4.0 - 2016-08-31 * Major changes - Add the Simple Logging Facade for Java (slf4j) for logging support rather than printing warnings to stderr. Applications must provide slf4j-api-1.7.7.jar or higher as dependency and can optionally provide a compatible logging framework of their choice (java.util.logging, logback, log4j). * Medium changes - Add an alpha version of a DescriptorCollector implementation that is not enabled by default and that uses CollecTor's index.json file to determine which descriptor files to fetch. Applications can enable this implementation by providing gson-2.2.4.jar or higher as dependency and setting property descriptor.collector to org.torproject.descriptor.index.DescriptorIndexCollector. * Minor changes - Include resource files in src/*/resources/ in the release tarball. - Move executable, source, and javadoc jar to generated/dist/. Happy descriptoring! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXxp6UAAoJEC3ESO/4X7XBUF8IAMuIPxoCkt9FR6LolUmuyk3I +eElyry5r8jUGDiBOxx0TWrYxr6ZrvxOD6lxzvG0a/nfAF+cdELJyNE+1+GiTku2 rgM/1NcxqGq6yBzxMFOZXPv1VG35LmpFtQUnxZR5Ij8x/p3SweMlbHUAVShSQZT2 tuRi32YCBZyH8XgD65XAak0SZ7co7aMZOORsixymFYW2oRYOxOkARX4sA4AfA4ED Nkqwa4fhX3b4uIshbzpifXm0ACkAxEUwewLS/g6vkKcn0a0tS6DC3mDrzIOAvF8v VTLghyZKbuWWuGZAlLEDhyHmo3/Afy6ETb1cFy/lvJUVnu/W8P4sbRnQrfvVJ/s= =Ugsq -----END PGP SIGNATURE-----

1 0

Requiring p lines in consensuses
by Sebastian Hahn 31 Aug '16

31 Aug '16

Hi there, Karsten and I have been working on metrics-related tasks and one thing that's got a potential to cause us pain going forward is that of "p"-lines in consensuses. Tor has added them with consensus method 5 but only declared them to be optional. In practice, every consensus ever produced that used method 5 or later has added these lines, and I'd like to require them to be included going forward. The reason is that without looking at the consensus method, there's an ambiguity wrt exits: A missing line either means "reject 1-65535" (method 5 or later) or "no information" (anything before that). I believe this should cause no compatibility issues and wouldn't require a new consensus method. Is there some reason against doing this now? Cheers Sebastian

1 0

Alternative Implementations of Tor
by Alexander Færøy 29 Aug '16

29 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Over the past year I've been hacking, on and off, on an implementation of Tor in the Erlang programming language. The project started out after I met Linus Nordberg at the Erlang User Conference in the summer of 2015 - -- a couple of weeks before the CCC Camp in Germany. Linus and I discussed what it would take to get a very basic implementation of a Tor relay up and running in Erlang. The project has been named Talla, which is still open for change -- especially if it collides with an already established project within the wider Tor development community. I was unable to find any name clashes myself, but I may very well have overlooked something. The parts of Talla that is implemented in "pure" Erlang is going to be licensed under a two-clause BSD license. Talla also contains a "module" which is using Tor's ed25519 ref10 implementation (Thanks to Yawning for a great amount of help there) -- that module is licensed under the same license as Tor itself. I'm now at the point where things are slowly starting to take form. The important pieces of the code have so far been kept available only to a tiny group of close friends that I trust not to share the code until I, and possibly other people, considers that the code is stable enough for the wilderness of the wider internet. There is, to my knowledge, currently only one implementation of Tor that is actively in use on the production network, which is the C implementation. I'm aware of a Haskell implementation made by Galois, which to me mostly seemed like it was designed to be building blocks for writing more specialized clients and doing research with the Tor network. Last time I looked, the Haskell implementation's main function was doing a DNS lookup through a circuit within the Tor network and then quitting. I was also told there had been an implementation in Go that have had activity on the production network, but that project was abandoned by its maintainer. In general I'm a bit uncertain about the "best practices" of dealing with a third party Tor implementation, which Talla is. I'm writing this email to receive suggestions, comments, and possibly creative ideas about the following: 1. What is the general criteria set from the Tor project's perspective on when it is acceptable to make alternative Tor implementations available to the general public? I'm currently testing Talla using Chutney with a mixture of NTOR and pre-NTOR Tor daemons running (inspired by one of the configuration files in the Chutney repository, which referred to a 'tor-old' binary). My current plan is to stabilize Talla further until my gut feeling is that I can try to announce a single, middle, relay to the production Tor network. This relay will, of course, have a platform-string set to something easily identifiable like "Talla 0.0.1 (...)" and the contact-string set to a valid method of reaching out to me with, in its announced server descriptor. I will closely monitor that things are going as I expect and probably turn it off shortly after the test, when I have seen that my code isn't too "crashy" -- this will most likely be repeated a number of times until I'm satisfied with the results. Could I do more to ensure that the people caring for the network as a whole wont fear me pressing the start-button here? 2. I will not do any classical releases (as in packagable .tar.gz) until I'm past the point where my gut feelings are telling me that my code is reasonably stable for the production network of Tor. I will, in a very visible location, request that no distribution developers makes any packages of the code until there is a release. I think this is already the norm, but I guess being explicit won't hurt. 3. I will write, also in a visible location, a warning that the code is not production ready and that people should probably stick to running a Tor relay using the official Tor daemon and point to the installation instructions on torproject.org. 4. Not have any installation documentation and hope that Erlang is still an esoteric enough language to make people pass by without trying :-) 5. Talla will not have any references to the directory authorities that are currently used for the Tor production network. This means that anyone who is interested in running Talla will have to explicitly set the directory authority servers in Talla's configuration file. This will allow people who want to toy around with it together with Chutney to be easily able to do that. Why am I asking all these questions now, when I could just wait until Talla is ready? In two weeks there will be a smaller hacker camp in Denmark, named BornHack, where I was planning on giving a talk on the development of Talla, the design of the Erlang application, some of the many refactoring periods there have been, general information about how Tor works, and the testing of Talla. At the same time of the presentation I want to make all of the code for Talla available for the audience and public to see even though it at this point is not ready for "production usage" on the public Tor network. I hope this email will also allow us to discuss the wider concept of a network where there exists multiple implementations and the consequences of that. It might be there are other people hacking on a Tor implementation in their favourite language :-) I'm also on IRC as 'ahf' if anybody wants to talk about things regarding Talla that is outside of the scope of this email. Thanks you! Cheers, Alex. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXtHtlAAoJEPm8L+IrCM6PNl4P/08HCGnEpLADudaul9KX4bzL OqcygCP6AXpFUZdUqsD+hgPRgi97NYaNZas/hWimQyye3OfLw4EH29lukGiBrIZu Fp+bT2CAsan8Nn+Vb3rH0em1PPOyXYJ/qhYrXex/CPk5kY7CIatbwau9AgwylAKs 8G3wz364EQaAwq5v4BVTieenFxtNXfnjwtlPkNhtJUgRDwrj16v2IqwN1C6nIq2p E86Vok4ToWKwfzIshf2wESSGWHZ+K9bpZs+e1GnSkY4VgwpKE1Swp/8IhIlxa843 KO4EknByZIWqZrEORCd43nok88hW8tpbnuoMCE5HGMJzw/KTwQrSiS794cAnyhYt 6yokEUO3JdwRuJxLPzmLZc8tBniBaKuGfRbqC7XAurJkgq+UgLukgYWnlyvHlap+ RZaNpMqFQf8grMHWGd6ffxYzAcIc+935XN4D54Ua17seIpDHnKGKS04ZmKwBeCxy myafcqSxJsNrqYEN40QrtYdgU0zv74S75uU/DHAHcOcaPyAy5yHGAqAdOeGvtpV5 6/VAQDwbOPncfIntoU8FUjKcpKJBn5csltuknwDiWKFYLfAVqVawMYO2Ef12hDul 7SuqOksSL2Yx59m/0Bu8i0QARxZBw8x8TzuQ7RJkNmDeTR17ugDOIaBKV1Se9fgS JaHsOgLd/G0T7S4PT5vQ =IeQJ -----END PGP SIGNATURE----- -- Alexander Færøy

4 3

Some information about Tor relays
by Liu, Zhuotao 26 Aug '16

26 Aug '16

Hi Folks, This is Sky from University of Illinois. Currently we are working on research project related with Tor. To help us to better design and evaluation our proposal, we need some information about the Tor relays that is currently unavailable from the Atlas. Thus, if someone who operates Tor relays could provide us such information, your help will be greatly appreciated. :) We hope to have an estimate about computation capacity of Tor relays. For instance, how many circuits a relay can maintain when its CPU is driven to about 100%? On average, how many circuits are maintained by a busy guard and what the CPU utilization is. These kinds of information would be really helpful. Further, in Sep 2013, Tor saw a spike in its clients. https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients The suspicion is that a botnet used Tor as its C&C channel. Is there any data about the relay utilization during that time? For instance, how many more circuits a relay had to maintain during that time? Thanks a lot for your help. :)

4 7