October 2011 - tor-dev - lists.torproject.org

Fwd: [guardian-dev] Orbot-1.0.6-Tor-0.2.3.6-alpha-RC2
by Nathan Freitas 29 Oct '11

29 Oct '11

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Nathan of Guardian <nathan(a)guardianproject.info> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Major update to Orbot is now available for testing on Android devices: https://github.com/guardianproject/Orbot/Orbot-1.0.6-Tor-0.2.3.6-alpha-RC2.… (sig: https://github.com/downloads/guardianproject/Orbot/Orbot-1.0.6-Tor-0.2.3.6-…) This includes work from GSathya of GSoC, as well as the new "make your phone a Tor Wifi hotspot" feature. code, commits, whatnot is here now: https://gitweb.torproject.org/orbot.git +n -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk6rpcgACgkQ0qzSA7N0y9IJaQD/avI5IVCV4+Zy9yaz/XbVGDrO ZFIcUVe27zWSa8c8X3cA/j05eJhwnoGAIPLsIQ0jaywd+HcqKQmSI8FHfRgLqgus =ToXu -----END PGP SIGNATURE----- _____________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

1 0

Survey on Tor Trac usage and how you manage your tasks
by Karsten Loesing 25 Oct '11

25 Oct '11

Hi everyone! At the last annual dev meeting in Waterloo we had a very productive discussion about managing the various channels of Tor communication: https://trac.torproject.org/projects/tor/wiki/org/meetings/2011TorAnnualDev… Related to that discussion, we should talk about how we use Tor's Trac system, or more generally how we manage our Tor tasks. We use Trac as issue tracker, wiki, and for project management. But it seems that everyone uses Trac slightly different and has their own expectations how other people use it. This can slow us down. In addition to that, some people may not know how Trac can solve their problems. Knowing how others use Trac might help them manage their tasks more quickly. Let's conduct a survey! The survey below consists of two parts: The first part focuses on Trac's features and whether you're using them or not. The second part is about managing your tasks in general, either with or without Trac. If you are a Tor developer or volunteer or think you have some input on the topic, please fill out this survey until Sunday, August 28, 2011 and send it either to this list or to me. I'll try to summarize what was said and send the survey results to this list, hopefully before the end of the month. Thanks! Karsten 1 Using Trac features 1.1 Which of the reports (stored ticket queries) do you use most often? 1.2 What are typical custom queries that you run? 1.3 How do you use milestones and roadmaps? 1.4 Are you subscribed to tor-bugs and/or tor-wiki-changes, and how do you use the mails sent to these lists? 1.5 Which wiki pages do you read/edit most often? 1.6 How do you search for wiki pages? 1.7 What are typical search terms that you use when using the search features? 1.8 Do you use keywords and the tags page, and if so, what are keywords that you typically use? 1.9 How relevant are the following ticket fields for you? 1.9.1 Reported by 1.9.2 Owned by 1.9.3 Priority 1.9.4 Milestone 1.9.5 Component 1.9.6 Version 1.9.7 Keywords 1.9.8 Cc 1.9.9 Parent ID 1.9.10 Points 1.9.11 Actual Points 1.10 How relevant are the following ticket statuses for you? 1.10.1 accepted 1.10.2 assigned 1.10.3 closed 1.10.4 needs_information 1.10.5 needs_review 1.10.6 new 1.10.7 reopened 1.11 What other features do you use in Trac? 1.12 What features are you missing in Trac? 1.13 What features would you want our Trac not to offer anymore, because they're making things only more confusing for you (and for people who are new to Tor)? 2 Solving typical software development tasks Note that the questions below don't just focus on Trac, but on any tools or communication media you use for solving a task. 2.1 How do you decide what to work on, both when fixing bugs or when implementing new features? 2.2 How do you keep track of what things you're supposed to do for sponsors and for when? 2.3 How do you memorize new ideas to work on when they come up? 2.4 How do you coordinate working together with someone on something? 2.5 How do you learn who you could work together with on something? 2.6 What other software development tasks do you have that may be supported by Trac or a Trac-like system?

15 35

Re: [tor-dev] tor-dev Digest, Vol 9, Issue 8
by Rob Jansen 15 Oct '11

15 Oct '11

On 10/14/2011 08:00 AM, tor-dev-request(a)lists.torproject.org wrote: > On Tue, Sep 27, 2011 at 4:20 PM, Rob Jansen<rob.g.jansen(a)nrl.navy.mil> wrote: >> > If you have the need to run Tor experiments, or are just interested in the >> > Software, please try it out. We would love any feedback or comments or >> > suggestions if you have them! > i've got more, but first off: > > - why secondary dependencies not in git and not opt-in? > e.g. downloading > http://shadow.cs.umn.edu/downloads/shadow-resources.tar.gz - if you > run fully offline build systems this default behavior breaks builds. > True, this is a good point. My original reason is that I thought the latency data we collected from PlanetLab was too large to put in git. Since then, my experience with git and its way of handling changes leads me to believe this isn't an issue after all. Also, it is unclear to me that resources should be versioned the same way that source code is. > - what about hw acceleration in performance estimates? > e.g. openssl dynamic engines in virtual CPU processing. > We incorporate CPU delays into Shadow by giving it a CDF distribution of real measurements of application and CPU throughput, and "delaying" the processing of events based on this distribution. You can model HW accel by skewing the distribution, or better yet creating a new one based on real measurements of an accelerated OpenSSL/Tor. > - is there a shadow-dev in addition to shadow-support?:) > Not yet. Since you asked, it will be up in a few days:) > >> > We are continuously working on improving the simulator, including more >> > efficient use of multiple CPU cores and a command-line interface to help >> > with installing Shadow and some of its dependencies. > https://github.com/shadow/shadow-cli also handy. > > thanks! Thanks for the comments, feel free to share your others. Rob

1 1

Running Real Tor Code Over Simulated Networks
by Rob Jansen 14 Oct '11

14 Oct '11

Hello, For the unaware, we have been working on the design and development of Shadow, a simulator capable of running real binaries over a simulated network, and a plug-in that runs real Tor. Shadow can simulate roughly 1000 Tor nodes in 10 GB of RAM and is easy to setup and use (no root required). You can generate realistic Tor topologies using a consensus, and test changes implemented in Tor extremely quickly. Earlier this year, I had an idea for a new algorithm on Sunday, thought about how it might work and discussed it with Nick [Hopper - my adviser] on Monday, implemented it in Tor and tested it on Tuesday and Wednesday, started running experiments and had results by Friday. Honestly. That fast. If you have the need to run Tor experiments, or are just interested in the Software, please try it out. We would love any feedback or comments or suggestions if you have them! We are continuously working on improving the simulator, including more efficient use of multiple CPU cores and a command-line interface to help with installing Shadow and some of its dependencies. (Because really, who wants to install dependencies?) More details on Shadow's design can be found in our technical report: http://www-users.cs.umn.edu/~jansen/papers/shadow-umntr11-020.pdf A release version that is somewhat stable is available on the Shadow webpage: http://shadow.cs.umn.edu/ Our code is public at https://github.com/shadow Best regards, Rob -- Rob G. Jansen U.S. Naval Research Laboratory rob.g.jansen(a)nrl.navy.mil 202.767.2389

2 1

pid_t and MSVC
by Gisle Vanem 11 Oct '11

11 Oct '11

The use of 'pid_t' confuses me a bit: In common/procmon.c (inside MS_WINDOWS), it's typedef'ed to 'int' unconditionally. And then in common/util.* (tor_terminate_process()) it is assumed to be defined in orconfig.h or somewhere else. It's not AFAICS. It is true that _getpid() returns an 'int', but the way Tor uses it seems wrong; the last argument to OpenProcess() takes a 'DWORD'. So 'pid_t' should be 'DWORD' IMHO. So maybe we should introduce a 'typedef DWORD tor_pid_t;' in orconfig.h? Btw. MingW does have 'pid_t' in it's <sys/types.h>. --gv

2 1

Tor download link
by Marco Bonetti 10 Oct '11

10 Oct '11

Hello all, I have noticed that the distribution directory: https://www.torproject.org/dist/ only contains source code for the latest stable and unstable version. This somehow breaks package distribution mechanism like SlackBuilds.org which do not host source code by themselves. I have already submitted an up to date SlackBuild: as soon it will be accepted, new Slackware users will be able again to build Tor again so it's not a ground breaking issue but nevertheless a bit annoying. So, is there a directory which hosts older but still accepted as valid version of Tor which I did not see or is a torproject.org policy to just keep latest versions online? Again, not a very important issue but it will make package maintenance easier if I could link to a source package which will not be removed when still valid. Thanks in advance, Marco -- Marco Bonetti Tor research and other stuff: http://sid77.slackware.it/ Slackintosh Linux Project Developer: http://workaround.ch/ Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/ My GnuPG key id: 0x0B60BC5F

3 4

Re: [tor-dev] Proposal 176: Proposed version-3 link handshake for Tor
by Roger Dingledine 05 Oct '11

05 Oct '11

On Mon, Jan 31, 2011 at 09:50:06PM -0500, Nick Mathewson wrote: > 1) We should make it easier to use self-signed certs, or maybe > even existing HTTPS certificates, for the server side > handshake, since most non-Tor SSL handshakes use either > self-signed certificates or or... CA-signed certificates? > 2) We should make it harder to probe for a Tor server. Right > now, you can just do a handshake with a server, > renegotiate, then see if it gives you a VERSIONS cell. > That's no good. Does this proposal address this goal in any way? I don't see why it's on the list. > 3) We should allow other changes in our use of TLS and in our > certificates so as to resist fingerprinting based on how > our certificates look. Or this goal. Or do we simply mean here that proposal 176's results should not prevent results from other proposals like 179? > And the cell-based part of the V3 handshake, in summary, is: > > C<->S: TLS handshake where S sends a "v3 certificate" > > In TLS: > > C->S: VERSIONS cell > S->C: VERSIONS cell, CERT cell, AUTH_CHALLENGE cell, NETINFO cell > > C->S: Optionally: CERT cell, AUTHENTICATE cell Would probably be clearer to append an explicit line here: C->S: NETINFO cell > The v3 requirements are easy to meet: any certificate designed to > resist fingerprinting will likely be self-signed, or if it's > signed by a CA, then the issuer will surely have more DN fields > set. Certificates that aren't trying to resist fingerprinting > can trivially become v3 by using a CN that doesn't end with .net, > or using a 1024-bit key. I assume you mean "or using a key longer than 1024 bits." > If the client implements this proposal, however, and the server > has shown it can understand the V3+ handshake protocol, the This is the first point where you use "V3+" where you had otherwise used "V3". Should the + just be implicit, or do you mean to imply something different when you say V3+ vs V3? I don't see how we can predict that a given behavior could imply V4 without knowing what V4 will be. > An AUTH_CHALLENGE cell is a variable-length cell with the following > fields: > Challenge [32 octets] On IRC you suggested that the AUTH_CHALLENGE cell might want to list the authtypes it knows how to parse. Thus if we bump the AuthType version, we may not need to bump the whole link version. > 3.4. Authenticating via Tor cells: Client authentication > > A client does not need to authenticate to the server. If it > does not wish to, it responds to the server's valid CERT cell by > sending NETINFO cell: once it has gotten a valid NETINFO cell > back, the client should consider the connection open, and the > server should consider the connection as opened by an > unauthenticated client. The word 'back' is misleading here, since it implies that the server waits to send its netinfo cell until it sees one from the client. > CID: A SHA256 hash of the client's RSA1024 identity key [32 octets] > SID: A SHA256 hash of the server's RSA1024 identity key [32 octets] > SLOG: A SHA256 hash of all bytes sent from the server to the client > as part of the negotiation up to and including the > AUTH_CHALLENGE cell; that is, the VERSIONS cell, > the CERT cell, and the AUTH_CHALLENGE cell. [32 octets] > CLOG: A SHA256 hash of all byte sent from the client to the > server as part of the negotiation so far; that is, the > VERSIONS cell and the CERT cell. [32 octets] > SCERT: A SHA256 hash of the server's TLS link > certificate. [32 octets] > TLSSECRETS: Either 32 zero octets, or a SHA256 HMAC, using > the TLS master secret as the secret key, of the following: > - client_random, as sent in the TLS Client Hello > - server_random, as sent in the TLS Server Hello > - the NUL terminated ASCII string: > "Tor V3 handshake TLS cross-certification" > [32 octets] > TIME: The time of day in seconds since the POSIX epoch. [8 octets] > NONCE: A 16 byte value, randomly chosen by the client [16 octets] In the server section you specify that the randomness needs to be strong. Does the omission of that specification for the client mean it doesn't need to be? :) (I'd hate for somebody to misinterpret 'nonce' as 'value that was not previously used', and implement it as a counter, which would do perfectly fine for the protocol but also reveal how many authenticate cells we've sent since the last time you saw one.) > SIG: A signature of a SHA256 hash of all the previous fields > using the client's "Authenticate" key as presented. (As > always in Tor, we use OAEP-MGF1 padding; see tor-spec.txt > section 0.3.) > [variable length] > > To check the AUTHENTICATE cell, a server checks that all fields > containing a hash contain the correct value, then verifies the > signature. The server MUST ignore any extra bytes after > the SHA256 hash. You mean extra bytes after the signature? > 4. Numbers to assign > > We need a version number for this link protocol. I've been > calling it "3". > > We need to reserve command numbers for CERT, AUTH_CHALLENGE, and > AUTHENTICATE. I suggest that in link protocol 3 and higher, we > reserve a separate range of commands for variable-length cells. Sounds good to me. > 6. Security argument > > These aren't crypto proofs, since I don't write those. They are > meant be reasonably convincing. They look plausible to me. > 8. Open questions: > > - May we cache which certificates we've already verified? It > might leak in timing whether we've connected with a given server > before, and how recently. Would this be much of a win anyway? Seems like more code for not much of a win. > - With which TLS libraries is it feasible to yoink client_random, > server_random, and the master secret? If the answer is "All > free C TLS libraries", great. If the answer is "OpenSSL only", > not so great. Good question. > - Should we do anything to check the timestamp in the AUTHENTICATE > cell? Does having the timestamp give us anything that having the nonce doesn't already provide? I pondered for a while that it might actually be bad to have the timestamp there, since its offset from 'real' time is a cookie that lets us track the user. But there are plenty of other ways that we can learn the client's time, like the NETINFO cell. > - Can we give some way for clients to signal "I want to use the > V3 protocol if possible, but I can't renegotiate, so don't give > me the V2"? Clients currently have a fair idea of server > versions, so they could potentially do the V3+ handshake with > servers that support it, and fall back to V1 otherwise. Given that corporations like Bluecoat sell censorship devices that censor our V2 handshake -- and we've seen them deployed in Syria -- but we know of no places that censor our V1 handshake, it would not be crazy to declare that V3-supporting clients all prefer V1 to V2. That said, bridges are a good example of a case where we don't know the server version, and also a prime use case here. One hack would be to change Tor versions that don't support V3 (like 0.2.2.x) so they don't support V2. *That* said, I think we shouldn't waste too much time on this topic. There aren't any Tors that can't renegotiate now (if we ignore Tor clients in Syria), so if we are forced to make some in the future before V3 is deployed, we could just make those Tors only support V1. > - What should servers that don't have TLS renegotiation do? For > now, I think they should just stick with V1. Eventually we can > deprecate the V2 handshake as we did with the V1 handshake. > When that happens, servers can be V3-only. Who are these servers you're thinking of? --Roger

3 4

Reminder: less than two months left for getting big features merged into 0.2.3.x
by Nick Mathewson 04 Oct '11

04 Oct '11

Hi, all! This is a reminder about the planned schedule for 0.2.3.x. See http://archives.seul.org/or/dev/Jul-2011/msg00030.html for the original announcment. December 1 is the deadline for getting large features and complicated bugfixes merged into 0.2.3.x. January 6 is the deadline for new features and marginal bugfixes. Please plan accordingly! cheers, -- Nick

3 2

سلام برنامه تور فارسی برای ایران
by Mohammad Mo 01 Oct '11

01 Oct '11

سلام برنامه تور فارسی برای ایران وسازگار با سرعت کم اینترنت داخلی می خاهم متشکرم mohammad_20101389(a)yahoo.com

2 2