Re: [tor-dev] next globe update feedback
On 11/8/13 2:59 AM, Matthew Finkel wrote: On Thu, Nov 07, 2013 at 03:33:23PM -0500, m...@rndm.de wrote: I also added relay family links. While working on this feature I noticed that the onionoo family field can return fingerprints of bridges. I modified the way the relay details route works and now it checks if the api returns a valid relay. If this isn't the case it checks for a bridge and redirects to its detail page. (for example TorLand2 has a bridge in its family members field and clicking on the fingerprint throws an error on atlas) If this behavior is wrong or something is missing just tell me. Well, that's one place I didn't think to look for leaking bridge fingerprints. At this point there is no way to retrieve a bridge's IP address and port number using its fingerprint, right? And, considering the default torrc does say: However, you should never include a bridge's fingerprint here, as it would break its concealability and potentionally reveal its IP/TCP address. I really don't know how else to prevent this. Onionoo could do extra processing to prevent leaking these bridges, but I'm not sure that's a good way to do it. Onionoo does not sanitize any information from relay or bridge descriptors. Onionoo processes publicly available information from metrics, so whatever is sensitive in there is already available to whoever wants to use it. Onionoo only makes it more convenient for people to use this information. Metrics does not sanitize relay descriptors, only bridge descriptors. Whatever people put in their relay configuration and that goes into relay descriptors will be made public. On another note, globe looks awesome! Thanks you! Very true. Thanks, Christian! All the best, Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy buffering
On Sun, Nov 17, 2013 at 07:33:12PM -0800, David Stainton wrote: Hi, I noticed that because the obfsproxy api can sometimes buffer and resend smaller chunks of data. My simple use of Nacl stream_crypto to wrap each incoming data buffers will not work... that is because the client and server must keep synchronized nonce counters for the decrypt/encrypt to work... and in this case the client may send one large buffer and the server may receive many smaller buffers... trying to decrypt them with different nonces will of course fail. https://github.com/david415/obfsproxy/tree/david-nacl-stream-withoutkeyexchange It seems like the solution is to write a super simple framing protocol... which is to say that I can first send a frame length; and on the receiving end simply read until frame length worth of data is consumed... and then apply the crypto_stream cipher on that frame with the correct corresponding nonce. Super-simple framing protocols often fall victim to attacks in which the adversary messes with the length in the frame header. See, for example, Plaintext Recovery Attacks Against SSH: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf So be careful here. - Ian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy buffering
Super-simple framing protocols often fall victim to attacks in which the adversary messes with the length in the frame header. See, for example, Plaintext Recovery Attacks Against SSH: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf So be careful here. - Ian Over Tor it won't be a problem because Tor is authenticated. Thanks for the paper... I do really love to read papers like this. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy buffering
It seems like the solution is to write a super simple framing protocol... which is to say that I can first send a frame length; and on the receiving end simply read until frame length worth of data is consumed... and then apply the crypto_stream cipher on that frame with the correct corresponding nonce. That sounds like a reasonable solution. ScrambleSuit also has its own protocol header, if that helps: https://gitweb.torproject.org/user/phw/scramblesuit.git/blob/HEAD:/message.py#l161 Cool. Thanks! I'll take a look. Also, I'm probably stating the obvious here, but you seem to be using a static key for encryption and decryption. That results in a many time pad, i.e., the same key is used for many plain texts. That's a problem because Tor's TLS handshake is predictable and a censor could observe that multiple independent SaltyStream connections share several bytes in their handshake. You might want to use a key derivation function, as also suggested by the NaCl doc: NaCl does not make any promises regarding the resistance of crypto_stream to related-key attacks. It is the caller's responsibility to use proper key-derivation functions. I wrote this as a sort of rough draft... It is meant to accept a key from the commandline... you know, for testing. So I specified default keys... but really this is just for testing. To be useful at all there'd have to be proper key generation like you are saying and key exchange... It's OK to use crypto_stream to encode multiple messages with the same key as long as the nonce is different each time : This means that an attacker cannot distinguish this function from a uniform random function. Consequently, if a series of messages is encrypted by crypto_stream_xor with a different nonce for each message, the ciphertexts are indistinguishable from uniform random strings of the same length. Cheers David ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy buffering
On Mon, Nov 18, 2013 at 10:47 AM, David Stainton dstainton...@gmail.com wrote: Super-simple framing protocols often fall victim to attacks in which the adversary messes with the length in the frame header. See, for example, Plaintext Recovery Attacks Against SSH: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf Over Tor it won't be a problem because Tor is authenticated. I think that's an oversimplistic way of looking at the problem, but you're mostly right. Suppose that your message framing is just len (4 bytes plaintext) | LEN bytes of cipher text including higher level MAC | ... If an active MITM flips bits in the length field, you will feed the wrong number of bytes to the decryptor and the MAC check will fail. Moreover, this is an *unrecoverable* failure condition: there's no way for you to get back in sync with the other end. You have to drop the connection, and the other side has to respond to a connection drop in a sensible fashion. (I wouldn't recommend trying to reconnect and retransmit the queue - rather, propagate the failure up to Tor.) But, because the length field is plaintext, there is no decryption oracle; the adversary can't trick you into decrypting something that's not a length field and treating the result as a length field. I think this is probably acceptable for obfsK, which is just supposed to be different from anything recognizable. If you want all-bytes-on-the-wire-indistinguishable-from-randomness, that is considerably harder -- a great deal of the complexity of the chopper of https://hacks.owlfolio.org/pubs/2012-stegotorus.pdf is in service of being able to encrypt the length field without exposing a decryption oracle. Note that I no longer think that design is sound, but it will still give you an idea of what it takes. zw ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Apple App Store Redux
* Ralf-Philipp Weinmann r...@coderpunks.org [2013:11:17 10:25 +0100]: Getting TBB into the App Store would definitely help increase its visibility on the OSX side. However, I am not really in favour of giving a US company a list of all users having downloaded TBB plus information whether or not they are upgraded to the most recent version... IMO this is a very persuasive reason not to put it there. I think I still have access to both. Let me pull the latest version of both agreements (iPhone and OSX developer) and attach them to #6540. Thank you! Have you spoken to Mozilla how they have obtained their code signing cert? I believe this is on Mike's TODO list since he talks to Mozilla people fairly frequently, but it may not be a high priority for him. Mike, let me know if you would prefer for me to take this on? signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Apple App Store Redux
* Fabio Pietrosanti (naif) li...@infosecurity.ch [2013:11:17 11:08 +0100]: I think, as already discussed here [1] and [2], that TBB *must* goes in all kind of application store. Please see Ralf's reply to me elsewhere in the thread -- do you still think this while taking into account what we know about US companies' cooperation the NSA/USG with regards to turning over user data? Feels a bit like leading lambs to slaughter. I'm not comfortable with Apple having access to that much user information, especially tied to real names and credit card numbers and stuff. We should try to increase adoption, yes, but not at the expense of our users' safety, and the calculus involved is more complex than what you have presented here. signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Apple App Store Redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 01:39 PM, Erinn Clark wrote: * Ralf-Philipp Weinmann r...@coderpunks.org [2013:11:17 10:25 +0100]: Getting TBB into the App Store would definitely help increase its visibility on the OSX side. However, I am not really in favour of giving a US company a list of all users having downloaded TBB plus information whether or not they are upgraded to the most recent version... IMO this is a very persuasive reason not to put it there. For what it is worth, this is what we effectively do by putting Orbot in the Google Play store. We heavily promote alternatives (direct APK download, F-droid repo, etc), but Google Play is where the majority of downloads come from. Now, mobile is different, because the behaviors of users looking to find and install software is quite different than on the web/desktop. In addition, considering the amount of atrocious free proxy software being peddled in Google Play, I feel I would be doing our intended audience a disservice by not offering a quality option like Orbot, where they are primarily looking to find solutions. +n -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSimVnAAoJEKgBGD5ps3qpbAYP/3XemdFRrhXOV5J1BUrKPbzP YyasI66Nirgo7XAzcjukCRYUBR2uF8tNhNyQW7EIL373CgCDKGWsAwebtyIa7ry1 V6jW31VVd0Iory9Vl/ZCTEpTXWKyfp/EhuLpUXZeeASi5H/R/qKQg+3j2/mO4j3h OpowQFQmm5Z2s6oJ09HFQZ/2UfBExHnxV0oPLmYUOQ3hftRoD/uxsSIrWSO9u+OW 6u6z0HKgyg/+vcm1QXV7ozYaGXboaZ00NuJjhsm1aNQYGbtnn/gpFQfYmiMW85Pr oM02pS0dk3RDk++9hyv8LAzdNxj/C2kUSvtL1xsgZMgReCC0rBJnBaHf3XESwkeG njouArjw3RG6r/QNtpY/9lWM+ZFJcDHjkUHXyym7aVUgg520TruVyLwHn4fmzXL5 6EJDQktnPySamaimf1uI3zGUSQJv/nhiU1XNSUnNCEnRsVnNLxHh2+7FRC/gVOIw XYGgQ0+Afk0sXlZRBB0yaARljWeWDSHhNARvvRSvAxnbtWm+/ltAa55m2CvA1Chg AZYNwTZDYyzJ3xnDf5jXSeAxAEj0+VFcVM8evEGNiFcguQwBxWG5rzrSm3gR5hqG dsTASZWa377NNVfNicMlnra+OAgJnPc1kFC3NPXMMlmLMsPwACN1GRd16HdxrDn1 u3gg39s2LoUQJZPOIWPe =x52u -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Apple App Store Redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 02:07 PM, Nathan Freitas wrote: Now, mobile is different, because the behaviors of users looking to find and install software is quite different than on the web/desktop. As a side note, for those interested, we are really investing in the next 3-6 months in a new project called Bazaar which is about decentralized but secure app sharing. https://dev.guardianproject.info/projects/bazaar/wiki This includes adding Tor support into the F-Droid open repo mobile client: https://guardianproject.info/2013/11/05/setting-up-your-own-app-store-with-f-droid/ and investigating DropBox-like syncing solutions that work well over Tor: https://guardianproject.info/2013/11/12/your-own-private-dropbox-with-free-software/ If all goes well, it will be fairly easy for people to socially share apps like Orbot in a device-to-device manner over Hidden Services, OTR chat sessions, wifi and bluetooth. Stay tuned! +n -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSime4AAoJEKgBGD5ps3qp2+QP/0LWlxW5p20OT4m1UKZFSEGL Cd92kX7ogfjFAIMc2x8BeMc0ic03lfziTLwao+mf3+IvIDnp4AJDyGwlNjyZ/pE2 t0PFioM/h24DTBkwHEd/oD0SUE9Idg8bJH66NadyA3aZLdh3vARFkddpjiVSVMnm K5m1w46HlD5EcBjMUt0LGyIYCzVncblqI2zkP6YCpt0F4oB8/lCaWZGLAap/Yhn0 eX+P5GOZjL3T3Vy5Cm7Zo44saPoClElSJ2lfJNmUXYe735IO0u6CkomQ8wlB/VpV ZlTrGd6xcB2g64jjkDUvcgWreKB/5jXJIWu0zi9V8GHZ5S9lSbvhfwoVlGGLWmh1 jUQGB9zsKQqNM6xMxoGsMcXXIKuHuqGW8wZxdff1HMp8ZhI9NVCcxXNdHT3kbduZ cT50co2j0Td4DifuZohKWSnXAkLtVVBKH9QN21x+qNmSjmNcMlkSfkUDQRQ+fJqL +zc77i1q/BZoK4Ht4C7l/Yk5RIhpn6H1wRaDr7OZetbbs/I322JZto3NUYZDmNNy 236G/5GmNnJEjQfymino6iRLipTPzr07eBI8FWChxhvWn1q9gs4Koo/yH8WVQ7EE vr5D2P2NTwdZFSch6PFybyKWA2AIzRevBiS0Fmojsni6w4cZ28V2WP5KonKXrh8V G1LSfFcwhhxBTj5lcmNF =gzhF -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Speeding Up Tor with SPDY
Dear all, Andrey Uzunov's Master's thesis on Speeding Up Tor with SPDY is now available at https://gnunet.org/content/speeding-tor-spdy My personal conclusions are that SPDY PUSH should not be used with Tor, and that modest performance gains with SPDY are attainable for typical websites. Aside from deployment considerations (how to detect exits supporting SPDY2HTTP translation), a major area for further work will be adding HTTP pipelining support to the SPDY2HTTP proxy to avoid performance regressions seen with some sites. For those that prefer watching over reading, we'll post the defense talk on https://gnunet.org/ once we've finished the conversion. Feedback is of course welcome. However, as Andrey is now finished with his thesis and looking for work (hire him!) -- and as I don't have any funding to support further work on this now -- it is unlikely that we'll be doing any further major implementation work on this in the near future. Naturally, the existing code is freely available (and does work, if one is willing to go through the pains to set it up properly). Happy hacking! Christian signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy buffering
yeah... you are right! Thanks for the clarification. I've been meaning to read the Stegotorus paper soon. Cheers! David On Mon, Nov 18, 2013 at 9:24 AM, Zack Weinberg za...@panix.com wrote: On Mon, Nov 18, 2013 at 10:47 AM, David Stainton dstainton...@gmail.com wrote: Super-simple framing protocols often fall victim to attacks in which the adversary messes with the length in the frame header. See, for example, Plaintext Recovery Attacks Against SSH: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf Over Tor it won't be a problem because Tor is authenticated. I think that's an oversimplistic way of looking at the problem, but you're mostly right. Suppose that your message framing is just len (4 bytes plaintext) | LEN bytes of cipher text including higher level MAC | ... If an active MITM flips bits in the length field, you will feed the wrong number of bytes to the decryptor and the MAC check will fail. Moreover, this is an *unrecoverable* failure condition: there's no way for you to get back in sync with the other end. You have to drop the connection, and the other side has to respond to a connection drop in a sensible fashion. (I wouldn't recommend trying to reconnect and retransmit the queue - rather, propagate the failure up to Tor.) But, because the length field is plaintext, there is no decryption oracle; the adversary can't trick you into decrypting something that's not a length field and treating the result as a length field. I think this is probably acceptable for obfsK, which is just supposed to be different from anything recognizable. If you want all-bytes-on-the-wire-indistinguishable-from-randomness, that is considerably harder -- a great deal of the complexity of the chopper of https://hacks.owlfolio.org/pubs/2012-stegotorus.pdf is in service of being able to encrypt the length field without exposing a decryption oracle. Note that I no longer think that design is sound, but it will still give you an idea of what it takes. zw ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Development Calendar
Hello humans, I know that meetings and scheduling are a pain. That sucks. Here's a calendar of our regular meetings, which might make it easier: https://www.google.com/calendar/embed?src=1gf7r9dh4bcv0vc926ipq5177g%40group.calendar.google.comctz=America/Los_Angeles I hope that helps a bit. Here are some thoughts. It's a Google calendar. Yeah, about that. Calendars are hard, and I couldn't find anything free and open that seemed as easy and convenient as Google calendar. If you know of something FLOSS that's as easy and convenient, you should tell me, and help me move it over. In the mean time, you don't need a Google account to use it, and you can read it on the web or with an iCal feed. Complaints and suggestions welcome. Access/collaboration. I think you need a Google account to editing things. If you have a Google account and you want to edit this thing, drop me a line with a blurb and a Google account adress. I'll add you. If you don't have a Google account, fear not too hard. If you email me, I'll add something to the calendar for you. Here are things you should include in your email: * title for the event/meeting; * timezone, start, and end times; * location, IRC channel, phone access procedure, or whatever; * repeat schedule; * any content or description for the body; and * anything else you think is important. Updates. This calendar should remain accurate, especially for meetings which I plan or am at. I use it as *my* primary calendar of public Tor meetings, so it'll always represent my current view of the universe. Anything else? -Tom ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Development of an HTTP PT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/11/13 14:22, dardok wrote: Hi, I've been reading about Selenium web-browser driver thing and I consider that is not very handy to do what an HTTP PT client side needs, that is to forge HTTP requests and embbed the TOR traffic into these HTTP requests. It is more oriented to emulated a web user interaction with a real browser (such as firefox, chrome, opera, ie, ...) and the interaction and testing of web apps from these browsers. Also I cannot see how to handle the responses from the server-side using this thing. Few functions seem to be interesting regarding HTTP protocol handling and manipulation, as I said before most of the functions present are related with the user interaction. The Python version can be installed easily: pip install selenium The already implemented functions can be read on this file: /usr/share/pyshared/selenium/selenium.py I didn't find any useful function to allow a HTTP PT (client side) embed the TOR traffic into HTTP requests (maybe some cookie function related) and extract the information sent by the HTTP PT server side (maybe some get_body_text() or get_text() funtion). So I am ready to consider that this option is not be useful to implement a HTTP PT client side. Anyway, I would like to discuss this point with someone interested in this topic. Hey dardok, I am not an expert with any of these technologies at all, but perhaps you could look into this? https://addons.mozilla.org/en-us/firefox/addon/mozrepl/ It's an extension you install that then lets you telnet-connect to it and control firefox - which means you could do that from a PT. (There might be an even cleaner interface for programmable access, telnet is just what's advertised on the front page.) https://github.com/bard/mozrepl/wiki/Tutorial This shows an example on how to visit a website (the remote bridge maybe) and get information out of the resulting page. X - -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSirUsAAoJEIYN7zuPZQt5yGcQAJbQjkL2AXOwuGD5T4Zluop2 fF3PQW3MmUPmazlC7YmzNzjIvGEuBzkG4qc7wmCjo+rHuJqkDADMNlomdp9zxbjQ ziRntZS7b87skkZ+dXg+TK2z30zJlwcJc0SW5XnWo+v45GgxYhJ2UFGP0fxpYBI0 ZScFXXp2TIEkvwbqsewseW0K9w3/rYUv2wQova+izeVyqVkPlzg0B5zhpav2jbWq c0TqRDGZsY9oBIdh+GLiTO1V1/NZXFTNkfS1iLJhqqJYeosOWiuGQVOzc2w/7yN3 VxIG1dldbsIgjci59cc1/FgqdrdTdLwwBcp9HexRI8jrLLwbDBpY61OgchTBhlWf EnrsIZZCIAZzAcPGqwsBTFGXxVcTjwtEokPZdDORcrBHqv3DNKKgvRcT+aIX+/AH dTinyRaaOh1c5F+6wuddDqd1sgLxdaiuZRNmqmGa4gX7ZXxs+SwlB+9nVWyv6r+e ZT6vxinKrjPeC4vCRIpRISsi1T6bogeugsX9+iE43f1vh2HrTL+AuxStvFKCy55L fXVhItmvI6VbyI5XpRsj+YuLLmpRB8+j7/W6Jg5Gc1/uFbwpIH+mxBKbUV9hE47F FOmq0qIftAhGOQAFXjdczooHSJ1AZeiVkFh6gW/6lbmnjga9NH8eVMIuGPjvA8yk 3JWGDkyUUToIMSN6WYGS =tMSt -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
