- tor-dev - lists.torproject.org

Some initial analysis on the new "Triple Handshake Attack" and Tor
by Nick Mathewson 07 Mar '14

07 Mar '14

Hi, all. It looks like there was a new attack on the TLS protocol this morning. I think it doesn't affect Tor. But I should walk you through my reasoning to see if you agree. I. The Triple Handshake attack. Go read https://www.imperialviolet.org/2014/03/03/triplehandshake.html and then read https://secure-resumption.com/ . They explain the attack more carefully than I can do here. Do *not* believe the part that says "renegotiation plus client certs" == doom until you have read the next part of this message. II. The results of Triple Handshake on the v2 link protocol Up until Tor 0.2.3, the preferred way for two servers to initiate a connection with one another was the "v2 link protocol", which uses both client certificates and renegotiation. Fortunately, we do not support session renegotiation in Tor. So I believe we're in the clear there. III. Implications for the v3 link protocol As part of the V3 link protocol, the client (C) may authenticate to a server (S) by sending a signed authentication statement saying, among other things, "Here's your identity key $S, here's a hash of the link certificate you used, here's my identity key $C, here's a hash of everything we've said to each other, here's the challenge message you just gave me, and I'm binding this assertion to this TLS connection using the master secret $foo". This all gets signed with the client's key $C. (Note that the "client" in this case is another Tor server. Regular users don't authenticate at all.) Now, when we made that protocol [see proposal 176], we assumed that master secrets were unique to a single TLS connection. That assumption isn't true: the enabling part of the "Triple Handshake" attack is that the attacker (A) can arrange it so that C is connected to A, A is connected to S, and the TLS connections between A and S will share the same master secret. Fortunately, I don't think this assumption can't be used to attack the v3 link protocol, since before the client will sent any such signed authentication statement, it insists on getting authentication from the server, in the form of a certificate chain leading from the server's identity key $S to the the key used for the TLS connection. So the client won't send a message containing the identity key "$S" to A, since A can't do a TLS handshake that is signed with any key that is signed with "$"S. Also, we built some redundancy into our design. From proposal 176: Even if the protocol didn't contain the TLSSECRET component, the server could [trust] the client's authentication, but it's a little trickier. The server knows that it is not getting a replayed AUTHENTICATE cell, since the cell authenticates (among other stuff) the server's AUTH_CHALLENGE cell, which it has never used before. The server knows that it is not getting a MITM'd AUTHENTICATE cell, since the cell includes a hash of the server's link certificate, which nobody else should have been able to use in a successful TLS negotiation. Because the link certificate hash is part of the signed message, the attacker A can't actually get the client to give it a message that the server S will accept, even if the client *did* send the message before checking the server's entire certificate chain. IV. Conclusions 1. Looks like we dodged another protocol bullet here. 2a. We should alter tor-spec.txt to make it clear that disabling TLS session resumption is even more necessary for security than we had thought. 2b. We should make it clear in tor spec that the client MUST NOT send an AUTHENTICATE cell before checking the CERTS cell and authenticating the server. 3. We should be sure to retire the v2 handshake nice and fast once 0.2.2 is unsupported. Renegotiation is an ugly corner of TLS that we should count ourselves glad to stumble out of. 4. We should look for more things to shove into the AUTHENTICATE cells in future versions of our protocol. The server certificate hash is a good start, but perhaps we can find more things to add. 5. We should revisit proposals to have Tor server <-> server communication use the v1 link protocol again. (That's the one where both sides present a certificate chain in their TLS handshake. We moved away from it because of protocol fingerprinting issues, before we'd hit upon pluggable transports as a better means for protocol obfuscation.) Due to our messed-up use of ciphersuites for signalling, we will have some tricky times designing this compatibly with existing Tors. But it might be our best long-term option if we can make it work. (IIRC Robert Ransom was advocating this.) V. Acknowledgements Thanks to Adam Langley for explaining some of the issues in this attack to me. Thanks to Steven Murdoch, Nicholas Hopper, and Adam Langley for reviewing an earlier draft of this mail. (At least one of them only had time for a cursory look, so please don't blame them for any mistakes here.)

4 5

GSoC - Profile UDP transport protocols
by Danilo Carvalho 06 Mar '14

06 Mar '14

Hello I am interested in profiling the UDP transport protocols, I think using a different underlying protocol could significantly improve Tor's performance and I would like to be part of that. At first, I thought that the project consisted of profiling existing udp transport code. However, I could not find existing implementation of the protocols described in the pdf[1] or the bug tracker[2]. The newest reference to the project was Murdoch's blog post, but even that's 3 year dated, and I couldn't find any followup. So, is changing Tor to udp still a thing? I see that the ecosystem now is far more complex than it was 3 years ago, and a change of the underlying protocol would be much cumbersome to implement across all the applications that currently interact with the Tor network. Another issue, is this project suitable for a GSoC project? I believe that only implementation and testing of the designs proposed in the pdf[1] would take longer than a summer. To finish it up, if this project is still kicking, could some pointers to it be given to me? I'd like to start working on my GSoC proposal asap. Cheers, Danilo (knorr) [1] https://research.torproject.org/techreports/datagram-comparison-2011-11-07.… [2]https://trac.torproject.org/projects/tor/ticket/1855 [3]https://blog.torproject.org/blog/moving-tor-datagram-transport

2 1

GSOC Proposal - Orbot and Orfox
by Amogh Pradeep 06 Mar '14

06 Mar '14

Hi all, I, Amogh Pradeep, of International Institute of Information Technology, Hyderabad, India, plan to participate in Google Summer of Code this time. Here a link to my proposal(just a mock up), https://github.com/amoghbl1/Orfox/blob/master/GSOC.txt please take a look at it and feel free to give me a few pointers. A short introduction of me and what I have been working on- As I like to develop on Android, I work with the guardian project on mainly Orbot and recently on Orfox too. I hope to continue working on Orbot throughout the summer and therefore wish to do my project on the same. Please refer to the proposal for further information. Best, Amogh Pradeep, Developer, Student.

1 0

globe compass integration
by Christian 05 Mar '14

05 Mar '14

Hi, in the last couple of days I thought about a topic for a gsoc application. After getting ideas from Karsten and Sathya, I started making a rough roadmap of things that I want to do for globe, in the next couple of months (and maybe use it as a idea for a gsoc topic). - add new onionoo features to globe - add compass functionality + open compass tickets to globe - improve/add help documentation The central point would be to add compass functionality to globe. This has the advantage that the user can use the same application to search for relay/bridge details and do queries with grouped results. This could be accomplished by changing the UI and modify advanced search filters, add options for grouping and grouped search results. Another suggestion was to add a group detail page that displays aggregated data for multiple details. Currently compass pulls all onionoo relay details and queries them locally. Karsten suggested that globe could use the same method and load the onionoo data every hour or so and do the currently supported search and compass functionality on it. The idea is that globe could store the dump in a db (e.g. mongodb) and use its features for searching, grouping and aggregating data. This would be a major rewrite away from calling the Onionoo-API, to querying the locally available dump. I would like to know, if you think that integrating Compass into globe would be a good idea? Do you think that the compass integration would be a reasonable project for the gsoc? Do you have other ideas on how to improve globe? Thanks, Christian

4 3

Tor HS DHT Research
by Gareth Owen 05 Mar '14

05 Mar '14

Dear all Sorry if this is the wrong list (please tell me if it is). I'm undertaking research into the tor HS DHT and have a couple of questions. I know at present, a node must be on for 25 hours to participate in the DHT; however, periodically I wish to make small code changes to Tor and restart the node (aka fairly instantly/within minutes) but this causes me to lose the HSDir flag. So my questions are: 1) Is there anyway to restart Tor without losing the HSDir flag? 2) Is uptime self reporting - e.g. is a node's self reported uptime trusted or is it obtained elsewhere - I couldn't find the answer in the code. I guess what I'm getting at, is can I fake the uptime to get the HSDir flag? Best Gareth --- Dr Gareth Owen School of Computing University of Portsmouth

2 2

Coordination of censorship analysis tool
by sarnicki＠student.agh.edu.pl 05 Mar '14

05 Mar '14

Hi everyone, could you provide some information about your progress on the project? I am interested in developing the tool, but I don't want to duplicate your work. Thanks, Piotr

2 2

[RELEASE] Torsocks 2.0.0-rc4
by David Goulet 04 Mar '14

04 Mar '14

Hi everyone! After a big code review from Nick and help from a lot of people contributing and testing, this is the release candidate 4 for the new torsocks. Hopefully this is the last stretched before pushing this effort upstream but for that we need help with code/documentation review (again) and of course more and more testing! Multiple Signed-off on the code would be great so please go at it, ask questions, contribute! and let's make this new Torsocks awesomer! :) Some pointers on critical part of the code. --> src/lib/connect.c and close.c --> src/lib/getaddrinfo.c and gethostbyname.c --> src/lib/torsocks.c Also see the configuration file that has changed. --> doc/torsocks.conf If you are on OS X or/and BSD, please help make it work on those platforms. It's quite easy to break compatibility thus help make sure we didn't break it up :). https://github.com/dgoulet/torsocks.git Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc4.tar.gz Big thanks to all! David

5 7

(no subject)
by Samual Carman 04 Mar '14

04 Mar '14

-- hello i have some questioner regarding helping the development of tor contact me off list if possible thank yuo the wyer

1 0

Search Engine for Hidden services
by Prakash kumar 03 Mar '14

03 Mar '14

Sir I am Prakash kumar from G. B. Pant Engineering College, Delhi, India.I am a 2nd year computer science and engineering student. I want to work on the idea "search engine for hidden services". I have a basic knowledge of how search engines work. I want to know which language we will use for this project. And also what is the next step from here? Please guide me. github: github.com/prakash09 facebook:https://www.facebook.com/prakashkumar09 Thank you Regards, Prakash Kumar

1 0

IRC meeting on Fri, Mar 7, 17:00 UTC to discuss TIMB's next external milestone
by Karsten Loesing 03 Mar '14

03 Mar '14

Hi everyone, we're going to have an IRC meeting to discuss next steps for the Tor Instant Messaging Bundle (TIMB): Friday, March 7, at 17:00 UTC in #tor-dev on OFTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140307T17 The main topic will be the upcoming external milestone on March 31, 2014 and what we hope to have achieved by then. We'll also talk about (ab-)using Trac as project management system for this project. If people want to read up on what this is all about, here's the current wiki page for this project: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorO/TIMB Talk to you on Friday! Volunteers welcome! All the best, Karsten

1 0