tor-dev July 2015

tor-dev@lists.torproject.org

60 participants
48 discussions

Tor Browser/Tor Applications Team Meeting temporarily moved to Tuesday 18:00 UTC
by Mike Perry 26 Jul '15

26 Jul '15

The Tor Browser team meeting will be temporarily moved this week to Tuesday (July 28th) at 18:00 UTC, due to scheduling conflicts for Georg and me. Because of an additional conflict with the Tor Patch Workshop, we will likely be using #tor-project on irc.oftc.net instead of #tor-dev, as well. We're also expanding the meeting in general to open it up to anyone who is working on user-facing Tor client applications (such as Tor Birdy, Tor Messenger, Ricochet, GetTor, Satori, etc). If you work on something user-facing and want to discuss UI/UX, censorship circumvention configuration, or any related topics, please join us! The meeting format is described here: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html -- Mike Perry

1 0

Proposal 249: Allow CREATE cells with >505 bytes of handshake data
by Nick Mathewson 23 Jul '15

23 Jul '15

Filename: 249-large-create-cells.txt Title: Allow CREATE cells with >505 bytes of handshake data Authors: Nick Mathewson Created: 23 July 15 Status: Draft 1. Summary There have been multiple proposals over the last year or so for adding post-quantum cryptography to Tor's circuit extension handshakes. (See for example https://eprint.iacr.org/2015/008 or https://eprint.iacr.org/2015/287 .) These proposals share the property that the request and reply for a handshake message do not fit in a single RELAY cell. In this proposal I describe a new CREATE2V cell for handshakes that don't fit in a 505-byte CREATE2 cell's HDATA section, and a means for fragmenting these CREATE2V cells across multiple EXTEND2 cells. I also discuss replies, migration, and DoS-mitigation strategies. 2. CREATE2V and CREATED2V First, we add two variable-width cell types, CREATE2V and CREATED2V. These cell formats are nearly the same as CREATE2 and CREATED2. (Here specified using Trunnel.) struct create2v_cell_body { /* Handshake type */ u16 htype; /* Length of handshake data */ u16 hlen; /* Handshake data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; struct created2v_cell_body { /* Handshake replay length */ u16 hlen; /* Handshake reply data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; The 'ignored' fields, which extend to the end of the variable-length cells, are reserved. Initiators MAY set them to any length, but MUST fill them with zero-valued bytes. Responders MUST ignore them, regardless of what they contain. When a CREATE2V cell is generated in response to a set of EXTEND2 cells, these fields are set by the relay that receives the EXTEND2 cells. (The purpose of the 'ignored' fields here is future-proofing and padding.) 3. Fragmented EXTEND2 cells Without changing the current EXTEND2 cell format, we change its semantics: If the 'HLEN' field in an EXTEND2 cell describes a handshake data section that would be too long to fit in the EXTEND2 cell's payload, the handshake data of the EXTEND2 cell is to be continued in one or more subsequent EXTEND2 cells. These subsequent cells MUST have zero link specifiers, handshake type 0xFFFF, and handshake data length field set to zero. Similarly, if the 'HLEN' field in an EXTENDED2 cell would be too long to fit into the EXTENDED2 cell's payload, the handshake reply data of the EXTENDED2 cell is to be continued in one or more subsequent EXTENDED2 cells. These subsequent cells must have the handshake data length field set to zero. These cells must be sent on the circuit with no intervening cells. If any intervening cells are received, the receiver SHOULD destroy the circuit. 4. Example So for example, if we are a client, and we need to send a 2000-byte handshake to extend a circuit from relay X to relay Y, we might send cells as follows: EXTEND2 { nspec = 2; { node ID for Y, taking 22 bytes. } { node address for Y, taking 8 bytes } htype = {whatever the handshake type is.} hlen = 2000 hdata = { the first 462 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the final 62 bytes of the handshake } } Upon receiving this last cell, the relay X would send a create2v cell to Y, containing the entire handshake. 5. Migration We can and should implement the EXTEND2 fragmentation feature before we implement anything that uses it. If we can get it widely deployed before it's needed, we can use the new handshake types whenever both of the involved relays support this proposal. Clients MUST NOT sent fragmented EXTEND2 cells to relays that don't support them, since this would cause them to close the circuit. Relays MAY send CREATE2V and CREATED2V cells to relays that don't support them, since unrecognized cell types are ignored. 6. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell bodies for incoming cells until the entire CREATE2V/CREATED2V body has arrived. To avoid memory-related denial-of-service attacks, the buffers allocated for this data need to be counted against the total data usage of the circuit. Appendix A. A rejected idea for migration In section 5 above, I gave up on the idea of allowing relay A to extend to relay B with a large CREATE cell when relay A does not support this proposal. There are other ways to do this, but they are impressively kludgey. For example, we could have a fake CREATE cell for new handshake types that always elicits a "yes, keep going!" CREATED cell. Then the client could send the rest of the handshake and receive the rest of the CREATED cell as RELAY cells inside the circuit. This design would add an extra round-trip to circuit extension whenever it was used, however, and would violate a number of Tor's assumptions about circuits (e.g., by having half-created circuits, where authentication hasn't actually been performed). So I'm guessing we shouldn't do that.

1 0

[Patch] or/config.c for MSVC
by Gisle Vanem 23 Jul '15

23 Jul '15

This gcc-centric macro in or/config.c doesn't work well in MSVC v16/18: #define COMPLAIN(args...) \ STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END I suggest it should be patched like this: --- a/config.c 2015-05-06 22:22:09 +0000 +++ b/config.c 2015-05-06 23:15:57 +0000 @@ -2571,8 +2571,8 @@ #define REJECT(arg) \ STMT_BEGIN *msg = tor_strdup(arg); return -1; STMT_END -#define COMPLAIN(args...) \ - STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END +#define COMPLAIN(args, ...) \ + STMT_BEGIN log_warn(LD_CONFIG, args, ## __VA_ARGS__); STMT_END /** Log a warning message iff <b>filepath</b> is not absolute. * Warning message must contain option name <b>option</b> and ------- All recent compilers supports '__VA_ARGS__'? -- --gv

3 5

☎ Second Computer Graphics, Multimedia and Image Processing - 2015 Malaysia
by Conference Alert 23 Jul '15

23 Jul '15

The Second International Conference on Computer Graphics, Multimedia and Image Processing (CGMIP2015) Universitas Siswa Bangsa Internasional Jakarta, Indonesia October 29-31, 2015 http://sdiwc.net/conferences/cgmip2015/ cgmip15(a)sdiwc.net ---------------------------------------------- CALL FOR PAPERS, WORKSHOP and SPECIAL SESSIONS ---------------------------------------------- Research topics not limited to: - 3D imaging - Case studies and emerging technologies - Color and texture - Computational geometry - Computer art and entertainment (including games) - Case studies - Classification and clustering techniques - Compression methods - Computer animation - Curves and meshes - e-Learning applications and computer graphics - Emerging technologies - Emerging display technologies - Face recognition, face detection, and gesture recognition - Fractal geometry and applications - Graphics algorithms and applications - Graph theory in image processing and vision - Human-computer interfaces - Image compression, coding, and encryption - Image feature extraction - Image geometry and multi-view geometry - Immersive virtual reality - Interactive digital media - Simulation and virtual reality - Software tools for virtual reality - Surface modeling - Virtual environments - Virtual laboratories - Virtual reality, visualization, and education - Visualization All registered papers will be included in SDIWC Digital Library, and in the proceedings of the conference. All submitted papers will be reviewed by a minimum of two reviewers. The published proceedings will be indexed in ResearchBib, in addition, they will be reviewed for POSSIBLE inclusion within the INSPEC, EI, DBLP, Microsoft Academic Research, ResearchGate, and Google Scholar Databases. Important Dates =============== Submission Deadline: September 29, 2015 Notification of Acceptance: 2-4 weeks from the submission date Camera Ready Submission: October 19, 2015 Registration Deadline: October 19, 2015 Conference Dates: October 29-31, 2015

1 0

Fwd: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00
by hellekin 22 Jul '15

22 Jul '15

Dear Tor developers, would it be possible to add https://torproject.org/spec page, including anchors for the various specifications: #tor-protocol, #tor-rendezvous, etc. pointing to the repository, to accommodate the General Area Review Team's comments, enable future stable reference to Tor specs, and move on? That would be very, very simple to implement, and very, very useful as a temporary fix since I don't see the Tor project nor the IETF releasing Tor specs RFCs before the CAB forum's deadline is reached within four months. Thank you, == hk -------- Forwarded Message -------- Subject: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00 Date: Sat, 18 Jul 2015 05:25:25 -0400 From: Joel M. Halpern <jmh(a)joelhalpern.com> To: A. Jean Mahoney <mahoney(a)nostrum.com>, General Area Review Team <gen-art(a)ietf.org>, dnsop(a)ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dnsop-onion-tld-00 The .onion Special-Use Domain Name Reviewer: Joel Halpern Review Date: 18-July-2015 IETF LC End Date: 11-August-2015 IESG Telechat date: N/A Summary: This document is nearly ready for publication as a Proposed Standard RFC Major issues: It seems to this reviewer that at least the definition of how to use these names, reference tor-rendezvous, needs to be a normative reference. It appears likely that tor-address also ought to be a normative reference. Minor issues: It is not clear that a github reference without version identification is sufficiently stable for a normative reference from an RFC. Nits/editorial comments: _______________________________________________ DNSOP mailing list DNSOP(a)ietf.org https://www.ietf.org/mailman/listinfo/dnsop

3 10

Proposal 248: Remove all RSA identity keys
by Nick Mathewson 22 Jul '15

22 Jul '15

Filename: 248-removing-rsa-identities.txt Title: Remove all RSA identity keys Authors: Nick Mathewson Created: 15 August 2015 Status: Draft 1. Summary With 0.2.7.2-alpha, all relays will have Ed25519 identity keys. Old identity keys are 1024-bit RSA, which should not really be considered adequate. In proposal 220, we describe a migration path to start using Ed25519 keys. This proposal describes an additional migration path, for finally removing our old Ed25519 keys. See also proposal 245, which describes a migration path away from the old TAP RSA1024-based circuit extension protocol. 1.1. Steps of migration Phase 1. Prepare for routers that do not advertise their RSA identities, by teaching clients and relays and other dependent software how to handle them. Reject such routers at the authority level. Phase 2. Once all supported routers and clients are updated to phase 1, we can accept routers at the authority level which lack RSA keys. Phase 3. Once all authorities accept routers without RSA keys, we can finally remove RSA keys from relays. 2. Accepting descriptors without RSA identities We make the following changes to the descriptor format: If an ed25519 key and signature are present, then these elements may be omitted: "fignerprint", "signing-key", "router-signature". They must either be all present or all absent. If they are all absent, then the router has no RSA identity key. Authorities MUST NOT accept routers descriptors of this form in phase 1. 3. Accepting handshakes without RSA identities When performing a new version of our link handshake, only the Ed25519 key and certificates and authentication need to be performed. If the link handshake is performed this way, it is accepted as authenticating the route with an ed25519 key but no RSA key. A circuit extension EXTEND2 cell may contain an Ed25519 identity but not an RSA identity. In this case, the relay should connect the circuit to any connection with the correct ed25519 identity, regardless of RSA identity. If an EXTEND2 cell contains an RSA identity fingerprint, however, its the relay receiving it should not connect to any relay that has a different RSA identity or that has no identity, even if the Ed25519 identity does match. 4. UI updates In phase 1 we can update our UIs to refer to all relays that have Ed25519 keys by their Ed25519 keys. We can update our configuration and control port interfaces so that they accept Ed keys as well as RSA keys. During phase 1, we should warn about identifying any dual-identity relays by their Ed identity alone. For backward compatibility, we should consider a default that refers to referring to Ed25519 relays by the first 160 bits of their key. This would allow many controller-based tools to work transparently with the new key types. 5. Changes to external tools This is the big one. We need a relatively comprehensive list of tools we can break with the above changes. Anything that refers to relays by SHA1(RSA1024_id) will need to be able to remember and use an Ed25519 key instead. 5. Testing Before going forward with phase 2 and phase 3, we need to verify that we did phase 1 correctly. To do so, we should create a small temporary testing network, and verify that it works correctly as we make the phase 2 and phase 3 changes.

6 6

BOINC-based Tor wrapper
by Serg 21 Jul '15

21 Jul '15

Greetings to all developers! What do you think? BOINC - The Berkeley Open Infrastructure for Network Computing. https://boinc.berkeley.edu/ Technical wiki: https://boinc.berkeley.edu/trac/wiki/ProjectMain BOINC -> VirtualBox -> operating system with running Tor relay. Real working solutions? Yes: http://atlasathome.cern.ch/ http://lhcathome2.cern.ch/vLHCathome/ Platform diversity in Tor network may be solved by preparing images with different operating systems. The power of the Tor network may grow very quickly. Fastes reaction to Security vulnerabilities. All client will upgrade Tor images by administrator command. (all images should be signed ofcourse. It is the BOINC principle). You are doing a great job. Thank you! -- Best regards, Sergey

4 6

[Measurement Team] Next IRC meeting happens tomorrow, Jul 22, 14:00 UTC in #tor-project
by Karsten Loesing 21 Jul '15

21 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [I hope this message is not considered noise by people on this list, but we haven't yet decided where these announcements should be sent. Until we have, I'm planning to send these messages to this list and tag them with [Measurement Team], so that people can filter these messages if they absolutely don't care. Thanks for understanding.] Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team tomorrow on Wednesday, July 22, 2015, 14:00 UTC in #tor-project http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150722T14 Two weeks ago we started with introductions, and last week we created a list of measurement-related products and started writing fact sheets for some of them. Logs are available here: http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-08-14.06.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-15-14.00.log… This week I suggest the following agenda: - Introductions, 5 min (only if someone didn't introduce themselves yet) - Problems, 5-10 min: did anything else come up since last week - Products, 5 min: what are we doing with fact sheets - Priorities, 30 min: should we focus more on a certain aspect of measurements in the Tor network, while temporarily suspending or even permanently dropping other aspects? - Misc, 5 min: anything else you come up with Regarding the Priorities item, I'd want us to do another collaborative round involving a pad where we temporarily assume that no single Tor measurement-related tool exists or ever existed and where we brainstorm what tools we should build to measure (passively collect, actively probe, sanitize, archive, pre-process, feed back, aggregate, visualize) things in the Tor network. Maybe we can conclude that brainstorming session by deriving some suggestions for prioritizing our work, given the fact that some of the tools already exist. Hope that sounds interesting to you, but please remember that this discussion will happen tomorrow, not on this mailing list. If you want to participate, please join us at the meeting! Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVrjlvAAoJEJD5dJfVqbCrJp4IAMiq9Wp4N+ZEjaMdnXPPkMJS 5ItvmsxPxPZkhckrJafZtayE+3x+xfIZG44shgps53DKACxrtDxGdVruZRuA8o3f FGGLZ/YXQj7JJBiVGDn/vIXCfC4fuZSU5K4QYZeG9nDdspKl6HiB/xyavcF76mZw bQNyLU1870On1iQc7Ka9lP8+wO5WyfkJl0jspEs2GrRNMxK68hHakG8rFMVuE9z8 BQnqV113TQtSGJcpoWkfMeNQo0vf/BgbWVgE5/FA9x27WqQtS06oRfwxVMhgGYoW KNWVHyw0R7AG/1WEG/DTR8B/2M7iYVUmr4BrIjaaBo7GLYhySvo/z90fSiFz4Jg= =x3uM -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] [tor-commits] [tor/master] Remove the HidServDirV2 and VoteOnHidServDirectoriesV2 options
by Roger Dingledine 21 Jul '15

21 Jul '15

Isis: I'd like to highlight this change for you, since it means that the bridge authority's networkstatus files are now going to have HSDir flags on the bridge status lines. I don't know if this is going to be a problem for any of your parsing code in any way (hopefully not), but I figured now's a great time to let you know it's coming. --Roger On Thu, Jul 16, 2015 at 07:47:05PM +0000, nickm(a)torproject.org wrote: > --- a/src/or/networkstatus.c > +++ b/src/or/networkstatus.c > @@ -1678,7 +1678,7 @@ networkstatus_getinfo_by_purpose(const char *purpose_string, time_t now) > if (bridge_auth && ri->purpose == ROUTER_PURPOSE_BRIDGE) > dirserv_set_router_is_running(ri, now); > /* then generate and write out status lines for each of them */ > - set_routerstatus_from_routerinfo(&rs, node, ri, now, 0, 0); > + set_routerstatus_from_routerinfo(&rs, node, ri, now, 0); > smartlist_add(statuses, networkstatus_getinfo_helper_single(&rs)); > } SMARTLIST_FOREACH_END(ri);

2 2

Per-transport bridge bandwidth and bridge counts
by David Fifield 21 Jul '15

21 Jul '15

I made some graphs that show the count and total bandwidth of all bridges, broken down by transport. https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11/pt-bandwi… https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11/pt-count.… The top part of the graph is non-default bridges, and the bottom is default bridges (the ones that ship with Tor Browser). Note the varying vertical scales. Source code and data are here: https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11.tar.gz https://people.torproject.org/~dcf/graphs/pt-bandwidth-2015-07-11/pt-bandwi… I have a question about getting bandwidth numbers. What I want is something like available bandwidth capacity; i.e., how much headroom transports have given their level of use. I think that the bandwidth numbers I'm using are partially conflated with usage. Notice how parts of pt-count.png are flat while pt-bandwidth.png has a weekly pattern. The bandwidth number I'm using is the "w Bandwidth=" line from a bridge-network-status document. It looks like this: r starman qgM+62FgGytzEtibYqqiPcPtijQ mdOOBxVOTpw8loBezhSDZxLIcXs 2015-07-03 21:39:31 10.174.163.60 9002 0 s Fast Guard Running Stable Valid w Bandwidth=2646 p reject 1-65535 dir-spec.txt says: An estimate of the bandwidth of this relay, in an arbitrary unit (currently kilobytes per second). Used to weight router selection. See section 3.4.2 for details on how the value of Bandwidth is determined in a consensus." Section 3.4.2 says: When we speak of a router's bandwidth in this section, we mean either its measured bandwidth, or its advertised bandwidth.... The bandwidth in a "w" line should be taken as the best estimate of the router's actual capacity that the authority has. For now, this should be the lesser of the observed bandwidth and bandwidth rate limit from the server descriptor. It is given in kilobytes per second, and capped at some arbitrary value (currently 10 MB/s). I don't know where observed bandwidth comes from. Is there some kind of external test that measures it, or does it come from measuring user traffic? Another option for getting bandwidth is the "bandwidth" line in a bridge-server-descriptor document. It looks like this: bandwidth 1073741824 1073741824 2646895 The three fields are bandwidth-avg bandwidth-burst bandwidth-observed. dir-spec.txt says: Estimated bandwidth for this router, in bytes per second. The "average" bandwidth is the volume per second that the OR is willing to sustain over long periods; the "burst" bandwidth is the volume that the OR is willing to sustain in very short intervals. The "observed" value is an estimate of the capacity this relay can handle. The relay remembers the max bandwidth sustained output over any ten second period in the past day, and another sustained input. The "observed" value is the lesser of these two numbers. So it seems that bandwidth-observed is not what we want, because it's derived from current usage. bandwidth-avg and bandwidth-burst aren't useful because they are operator-controlled and often left at the default of 1 GB/s. Yet another option is the speed of serving consensuses, the "dirreq-v3-tunneled-dl" line in a bridge-extra-info document: dirreq-v3-tunneled-dl complete=13624,timeout=1456,running=4,min=1938,d1=21008,d2=43181,q1=53397,d3=63519,d4=88911,md=117048,d6=146982,d7=180109,q3=199979,d8=223313,d9=298860,max=1558627 You can take the "md=" field, for example, to get median B/s for serving consensuses.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev July 2015