June 2013 - tor-dev - lists.torproject.org

XMPP Pluggable Transport
by Alex Eftimiades 25 Jun '13

25 Jun '13

I have been working on creating an XMPP pluggable transport for Tor for a couple of weeks now, and someone suggested I send an email to this mailing list for suggestions. At this point, my priorities are ordered as follows: 1. Speed--I can watch low quality youtube videos on a bad internet connection, but there is a lot of down time while it buffers (not an unbearable amount of time, but enough to be annoying). This has been a big problem for a while, and I could really use some suggestions on how to speed it up. 2. Full GTalk compatibility. It seems you need to be on a recipient's contact list to send a message to them (at least without supplying a resource). However, I currently use messages to send connection requests to JIDs with unknown resources. Then when they reply, their resource is saved in a table. This technique works fine for everything but GTalk, which of course is by far the fastest of the chat servers I have tested. 3. Error handling--I need to make sure I take everything into account. I do not have anything that can reestablish connections if one computer disconnects from the chat server and reconnects. In fact, if it acquires new resources (which is what happens on GTalk), the other computers will be stuck sending messages to a JID with the wrong resource. I am pretty sure I can come up with some ways of dealing with this. Right now, looking for potential problems is just as important as pointing out solutions to more obvious ones. 4. Security. I know security is important, but the nature of the program just does not seem to admit many security threats. There are really just three that I can see: - The server can be told to connect to any ip:port by a client. - The server and client exchange their Python interpreter's sys.maxsize values (which could lead to profiling a computer's OS). The former can be fixed with a whiltelist and the latter is not even necessary (I just have not gotten around to tweaking that out of the protocol yet). - DoS. This would be relatively easy to take into account by limiting the number of connections a bot is willing to accept. Then the chat server itself will limit the amount of data sent from any one JID (for better or worse). If you think you are able/willing to help, read on for a summery of the concept and protocol below. Even if you are not well versed in XMPP protocols (I myself am learning as I go), just helping to test the program would be a big help. Thanks, Alex Eftimiades A brief summery of how the program works can be found here: https://trac.torproject.org/projects/tor/ticket/9022#comment:42 , and is reproduced below: ---------------------------------------------<Summery of concept > --------------------------------------------------------------------------------------------------- When using hexchat, the data is sent to a local TCP socket running hexchat (call it hexchat1). Hexchat1 then reads the data (thereby stripping it of its TCP header) and passes it over a chat server to another hexchat program (call it hexchat2) that sends the data to the appropriate ip:port (giving it a new TCP header in the process). The client thinks it is sending the data to hexchat1, and the server thinks it is receiving data from hexchat2, but the data itself is never changed. It might be broken into smaller chunks or combined into bigger chunks, and it might be delivered at unpredictable rates, but it is never altered. ---------------------------------------------</Summery of concept > --------------------------------------------------------------------------------------------------- A more detailed overview of the protocol can be found in the protocol- spec here, though I will summarize it: ---------------------------------------------<Summery of protocol > --------------------------------------------------------------------------------------------------- When the program is started, it is told what JID(s) to use to connect to a chat server, and possibly the following optional parameters: 1. An ip:port to listen on. 2. A JID. Connection requests will be sent to this JID when a connection is is made to the ip:port specified in (1). 3. Another ip:port. This is the ip:port the bot connected from the JID in (2) should connect to. Note that any bot can connect to any ip:port that client asks for. This could be a 127.0.0.1 address, or a remote address (but will probably be the former). I plan to add a feature in which you can provide a list of acceptable ip:ports to connect to and refuse to connect to anything else (for security). However, that is not a priority at the moment. When a connection is made, the server and client exchange all JIDs they are using to connect to the chat server so they can each rotate through JIDs to send messages from and JIDs to send messages to. With the exception of initial connections, all messages are sent as IQ stanzas. When data is sent, it is base 64 encoded and sent with an ID number that is incremented each time a message is sent. When data is received, the id is checked against the id of the last message that resulted in writing data to a socket. The difference between these two ids is used as an index in a buffer. Then, messages are read from the buffer and sent to the appropriate socket. When a socket closes, a disconnect message is sent. Like when sending messages, an id stanza is included. When a disconnect message is received, the bot checks if there are any entries in the appropriate socket's message buffer. If not, it closes the socket and deletes it from the routing table. If there are messages in the buffer, the disconnect message is added to the buffer at the appropriate index as a string "disconnect" as though it were normal data. When a "disconnect" string is found in the buffer, the socket is closed and deleted from the bot's routing table. ---------------------------------------------</Summery of protocol > ---------------------------------------------------------------------------------------------------

2 2

Re: [tor-dev] Gitian builds in VirtualBox with Vagrant
by Arlo Breault 24 Jun '13

24 Jun '13

> So this is a wrapper to install+launch a VirtualBox Ubuntu VM to use > Gitian in LXC mode? Sounds good! > > Exactly. Just codifies what it took to get it running in a VM. > > Hopefully by Monday I will have tagged TBB 3.0a2, and we will begin > building it. If your build matches (or comes close), I will merge this > stuff for 3.0a3. > > Note that I am about to commit some changes to mkbundle-*.sh, so be > sure to rebase your github branch for your build (which you will also > need to do anyways to pick up the latest 'versions' file tags). > > Ok. I'll keep my eye out for 3.0a2

1 0

[Stegotorus] Fundamental problem with ack/retransmission mechanism
by vmonmoonshine＠gmail.com 24 Jun '13

24 Jun '13

Hello Zack, In testing the retransmission algorithm, I encounter situations that the ack/retransmission algorithm is unable to resolve by design. It happens when the header of a packet gets deliver but the middle part gets dropped. For example in the following scenario Server sends packet 1 len 4k packet 1 gets lost Server sends packet 2 len 64k the last 60kb of packet 2 gets lost client receives packet 2 partially (4k) and waits for the 60k to come. client sends ack to the server saying that packet one is lost server retransmits pack 1 client consider packet 1 as a part of packet 2, and thinks that now it has 8k of packet 2 client again sends ack to the server saying that packet one is lost server retransmits pack 1 client thinks now it has 12K of packet 2 client again sends ack to the server saying that packet one is lost server retransmits pack 1 client thinks now it has 16k of packet 2 etc Soon the transmit queue on the client side will get filled up by the ack packets, cause the client won't realize its mistake before it receives 64k of garbage and be able to compute the mac. Hence the server and the clients will remain in this deadlock for ever. Originally, Stegotorus was dropping any circuit with full transmit queue. But this was causing lots of problem because lots of time the client lags behind the server for a while to process all the packet and sends ack. If ack/retransmit by design wasn't meant to recover from partial packet lost and was only a defense for complete packet lost, then the dropper proxy isn't doing a good job simulating the intended threat model. Otherwise, if the ack/retransmit was meant to withstand partial packet drop, then we need to redesign it so it doesn't get trapped in such a deadlock. Maybe we should have a timer so the circuits with full transmit queue gets a grace period before getting dropped. This is not specific to chop protocol. I'm wondering how TCP is dealing with such a situation. Thanks, Vmon

4 6

Standalone flash proxy
by Arlo Breault 21 Jun '13

21 Jun '13

https://trac.torproject.org/projects/tor/ticket/7944 Hello, I wrote a little wrapper to provide a headless flash proxy. It requires node.js >= v0.8.x To install and run, > npm install -g flashproxy # adds the flashproxy bin to your path > flashproxy Or you can, > git clone -b nodejs https://github.com/arlolra/flashproxy.git > cd flashproxy/proxy > npm install > npm start I'm looking for testers. Most of the time the facilitator won't return any clients. That's expected. Feedback appreciated. Thanks, Arlo

2 1

Discussion on the crypto migration plan of the identity keys of Hidden Services
by George Kadianakis 19 Jun '13

19 Jun '13

Greetings, I'm supposed to write a Tor proposal for the migration of the long-term identity keys of Hidden Services. When I began writing the proposal, I realized that some of my choices might not be appreciated by Hidden Service operators, and that starting a discussion thread might be a good idea before writing the proposal. The problem with the current long-term HS identity keys is that they are RSA-1024 keys which are considered weak, and they need to be upgraded to a cryptosystem with higher security properties. One of the main issues with this operation, is whether Hidden Services will be accessible using their *old* identity keys even after the migration. That is, when we change the identity keys of a Hidden Service, its onion also changes (since the onion is the truncated hash of its public key). This will be quite problematic for Hidden Services that have a well-established onion address. There are basically two ways to do this: a) After the transition, Hidden Services can be visited _only_ on their _new_ onion addresses. This is quite brutal, but it's the most secure and unambiguous option (might also be easier to implement and deploy). This change can be enforced both on the client-side, by rejecting any old RSA-1024 HS keys, and on the server-side, by only publishing the new keys in HS descriptors. To make the transition easier, we could prepare a tool that generates a new identity keypair before the flag day, so that Hidden Service operators can learn their future onion address beforehand and announce it to their users. b) After the transition, Hidden Services can use both old and new onion addresses. This might result in a more harmonious transition, where Hidden Services advertise their new onion address to users that visit them in their old address. .oO(It would also be interesting to do a redirection on the Tor protocol layer ("I got this descriptor by querying for the old onion address, but it also contains a new onion address. I should probably use the new one."), but I don't think it's possible to redirect the user without knowledge of the application-layer protocol (e.g. 302 for HTTP). Still, a Tor log message might be helpful.) The cons of this approach is that supporting both addresses might make the HS protocol more complicated and painful to implement, and it might also result in some Hidden Services never moving to the new onion addresses since clients can still visit them using the old insecure ones. This approach has a stricter variant, where the old addresses can only be used during a transitionary period (a few months?). After that, clients _have_ to use the new addresses. Of course, this means that we will have to do two flag days, coordinate Tor releases, and other no fun stuff. I'm probably moving towards the latter option because the former will make many people unhappy. Thoughts? (This is not a thread to select the cryptosystem we are going to use. It will derail the discussion, and we might also need to select a specific type of cryptosystem in the end (e.g. a discrete-log-based system) so that schemes like https://trac.torproject.org/projects/tor/ticket/8106 can be possible.).

16 29

Running Atlas Application
by abhiram 18 Jun '13

18 Jun '13

Hello, I am trying to get the Atlas application to run. After installing the required python packages, I keep getting this error. Traceback (most recent call last): File "run.py", line 34, in <module> from tornado.util import b, bytes_type, import_object, ObjectDict ImportError: cannot import name b Its seems like a version problem with tornado. If so, what version should I be using. I am running python 2.7.3 and tornado 3.0.3. Thanks -- Abhiram Chintangal Graduate Student Florida State University Computer Science Department (850) 980-4954

2 2

Re: [tor-dev] [liberationtech] Help test the new Tor Browser!
by Bernard Tyers - ei8fdb 17 Jun '13

17 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Congratulations Tor Project. Well done to Mike Perry and all the contributors. I've tested it on Mac OS X 10.6.8 and Debian 6.0 Squeeze and I had no technical issues on either. First launch (using clear Internet connection) took approx 40-50 seconds on each. (Debian was running as a VM on a Macbook Pro) The biggest usability hurdle for Tor (IMO) was having the browser launching separately to the Tor application. I've tested with users and this was a huge confusion for them. It wasn't a browser as *they* understand one. Now it is. First prong of the attack: this is how privacy enhancing software should behave - the exact same as all other software. Now Tor is even better. Second prong of the attack. Run more exit nodes. - From the quick run through I did, here are some(possibly minor) suggestions: 1. The installed application icon is as follows http://diymobileusabilitytesting.net/bernard/skitches/tbb-3.0alpha1-icon1-2… However when the application is opened, the application icon is this http://diymobileusabilitytesting.net/bernard/skitches/tbb-3.0alpha1-icon2-2… It may be confusing for someone who was not familiar with the different icons used by the TP. 2. The copy displayed during the initial install ("Before the Tor Browser Bundle tries to connect to the Tor network, you need to provide information about this computer's Internet connection) could possibly be reworded to give some context as to *why* it is being asked for. (Possibly reposition the copy to above the connection steps) Alternatively, is it possible for the install to run these two tests and determine to correct outcome? Ie. 1. Run some "tests" to determine if the Internet connection is clear of obstacles, then 2. Run some "tests" to check if the Internet connection is censored/filtered. Based on the outcome of these tests, Tor could then configure the connection as necessary. I could see this step being confusing for users not familiar with their Internet connection. 3. It would be interesting to see the numbers of users who actually follow the "Test Tor Network Settings" link. Once the TBB has installed and displays the "Congratulations! This browser is configured to use Tor." page, are users guaranteed to be connected to the Tor network? If so is there any need for the Test Tor Network..." link? Is it possible to display that information on the startpage? It is also very nice that the user preferences have been altered to be more privacy enhancing (History, etc). Congratulations to all involved. It is great work. Bernard On 17 Jun 2013, at 17:02, Michael Carbone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Congratulations Tor devs! Serious kudos -- this is exactly the > direction TBB needs to go. > > A couple minor things: the order of the addons in the toolbar seems > arbitrary (particularly the location of the Tor button, NoScript, and > HTTPS Everywhere). I'm sure it's not, but at minimum it might be good > in the about:tor splash page to have an arrow pointing to the location > of the TorButton in the toolbar if folks need to change settings. > Also, the search button image in about:tor is pixelated. > > This is a huge step forward in UX, very exciting! > > Michael > > On 06/17/2013 09:45 AM, Jacob Appelbaum wrote: >> Hi, >> >> I'm really excited to say that Tor Browser has had some really >> important changes. Mike Perry has really outdone himself - from >> deterministic builds that allow us to verify that he is honest to >> actually having serious usability improvements. I really mean it - >> the new TBB is actually awesome. It is blazing fast, it no longer >> has the sometimes confusing Vidalia UI, it is now fast to start, it >> now has a really nice splash screen, it has a setup wizard - you >> name it - nearly everything that people found difficult has been >> removed, replaced or improved. Hooray for Mike Perry and all that >> helped him! >> >> Here is Mike's email: >> >> https://lists.torproject.org/pipermail/tor-talk/2013-June/028440.html >> >> Here is the place to download it: >> >> https://people.torproject.org/~mikeperry/tbb-3.0alpha1-builds/official/ >> >> Please test it and please please tell us how we might improve it! - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRv4OOAAoJENsz1IO7MIrrCcQH/iic0Jy+xpAfFTXs29cxuQV2 Lcw/Im2uxxxwapQGK3+7hGWkfynwG+O/CvyN/RaFbCx6a2GywS8D++SAhSEpCVyL GMA6Vx8ZqiJ5KoqQkQ2Y2ENCMLkGIxgD374+bfSkHS5wkSmBesV2/DMva96PxO9e KZT9qZve/OwlXgsCKA0Z1CuHxPpxrbC9htNpRSJ31GUjNv+jZc6OIhDdAEbayx2W IBlgtsrb+glRe5gl1cRaBej3fnn6/zFoVoOMTQhwQEQr6xo8bvQUEcyNsHjMS6gW J6c3hSGcMmUnesvYCOv/x5BXGvC0FQBHHpk4+jh3zNeU3VAik59BLiVQ7e1PCL0= =ad2Q -----END PGP SIGNATURE-----

1 0

difference between cached-descriptors and cached-consensus
by moataz ahmed 16 Jun '13

16 Jun '13

I have one question please what is the difference between cached-descriptors and cached-consensus Best Regards Moataz Ahmed,

2 1

Torsocks locking design
by David Goulet 16 Jun '13

16 Jun '13

Hi everyone, I'm posting here the small design document I've made for the Torsocks locking mechanism. I'm looking for reviews, comments, improvements, ... well anything useful! :). (Even English mistakes since it's not my primary language). Future changes will be pushed here if any are needed after this thread is done with. https://github.com/dgoulet/torsocks/blob/rewrite/doc/proposals/01-Thread-sa… Thanks people! David

2 2

TBB check sums
by Linus Nordberg 15 Jun '13

15 Jun '13

Hi, I've built TBB's using the new and shiny gitian thing. Thank you Mike Perry for putting lots of effort into this! I'm at commit f4869b0b (tor-browser-bundle.git). Check sums below. --8<---------------cut here---------------start------------->8--- user@host:~/usr/src/tor-browser-bundle/gitian$ sha256sum TorBrowserBundle-3.0-alpha-1-osx32_* tor-browser-linux* torbrowser-install-3.0-alpha-1_* 1f3265462f267c30bf9bf8a8ac41904f03166f49ce78ed1c88e16915bf644313 TorBrowserBundle-3.0-alpha-1-osx32_de.zip f588f5ffebea4fce1ecac7d4c694b94afd202e0d82fbf6a19e153c8e9c8e8f12 TorBrowserBundle-3.0-alpha-1-osx32_en-US.zip d7067a2eae9b1899e854aa1083653b452ed33137139ed94807651c208b17da33 TorBrowserBundle-3.0-alpha-1-osx32_es-ES.zip 372d9790ca6be27f617afb97ad7923d46f8b823935375ce3262abd09af6038ab TorBrowserBundle-3.0-alpha-1-osx32_fa.zip dfd614b35d00a2ac9f5d5196bd4f0064fc53a43e909e32cbc847b42121463c85 TorBrowserBundle-3.0-alpha-1-osx32_fr.zip 735bd35612a756e28d011d61c5d682be4305d33db8f48b6e8721ff40c0784e7b TorBrowserBundle-3.0-alpha-1-osx32_it.zip cf38210e03a64bec93e94a8c28bb9b3e3462f4588d816515a10a22ef39126392 TorBrowserBundle-3.0-alpha-1-osx32_ko.zip fe3f355972b5712d9084ddb3f6926bf86910a4e0613d701523d35ae1a8591d00 TorBrowserBundle-3.0-alpha-1-osx32_nl.zip 81bd77b6e446aa2eb0cf1969dbad80923ebc26fcf55f3153fb1f2fcf4a554cae TorBrowserBundle-3.0-alpha-1-osx32_pl.zip 008e1eeb8ecd6f7f0e8543943eba1d40764a7b33edff06ccf4cf87de5ac74424 TorBrowserBundle-3.0-alpha-1-osx32_pt-PT.zip df47cd6c8167e7a610df586d69c0e6e7368c904e0e42ff0186c2831932338db1 TorBrowserBundle-3.0-alpha-1-osx32_ru.zip c9af80e798824ce1154cbf32ef1ba30f1a6e7b7e682e285dc69a2aaeada7bfa2 TorBrowserBundle-3.0-alpha-1-osx32_vi.zip ae47dd903c7683db89d769b8fb26cc0df8ebede424af09aa1108d773a808bf11 TorBrowserBundle-3.0-alpha-1-osx32_zh-CN.zip c6de2a39100be02f806a820196d87c565225cfbd637754f23206463eab1b96d5 tor-browser-linux32-3.0-alpha-1_de.tar.xz d28f7e708f01fb522e4a13d987859ace98cbe0f18ec3de71391c0fd3a82a527a tor-browser-linux32-3.0-alpha-1_en-US.tar.xz 74ac8e1b3d86148d3f94fdc5c21636859b07339bec00da68bf5a15a12b4b3b45 tor-browser-linux32-3.0-alpha-1_es-ES.tar.xz e4d575f89de04c955981923e467e879cdf5f6c2ac36a0d984058d0f16bdc3cd7 tor-browser-linux32-3.0-alpha-1_fa.tar.xz 5a39818f665906b2542568329c0f859264057b9c8df21d78b0f2b34d8bdfd35e tor-browser-linux32-3.0-alpha-1_fr.tar.xz 7f59ac51056e0d933027c57b032dc4896bca61d0f464bb28f3eff1dc46c1d58c tor-browser-linux32-3.0-alpha-1_it.tar.xz f9fc3d164f79e44fd1d43d15f59ccd56175d7d18a413b18ac1abe15adbc34662 tor-browser-linux32-3.0-alpha-1_ko.tar.xz 52d9401edc032d833500bafed3e7ae277365429c6e1d9293dfa6a88132a4b0b2 tor-browser-linux32-3.0-alpha-1_nl.tar.xz 52218f2d8f0d7192ed832087ef2fa1a6cb013117e887467965875c04752d7b6f tor-browser-linux32-3.0-alpha-1_pl.tar.xz dc201b5e9c9cac0883924b8558d3f317c10136107bded636722762030316acbe tor-browser-linux32-3.0-alpha-1_pt-PT.tar.xz 4be1e6b43d55bc3ef1d4d5db360ec6b9981d6ea7e5be7c19b9d8ed81e4f72b77 tor-browser-linux32-3.0-alpha-1_ru.tar.xz 057aebd3ad07d6edd661c314102459fb97377074a06b7e68035b00be4ab948ed tor-browser-linux32-3.0-alpha-1_vi.tar.xz f79c46aa4f52000faffe32ed1a8e10b82c481861fcd131bed2eeccb5078c1df2 tor-browser-linux32-3.0-alpha-1_zh-CN.tar.xz 763a96564571c364f73c1046465c6745b2bb150f914ab2740639d779da2529cb tor-browser-linux64-3.0-alpha-1_de.tar.xz 5e5dd31612df58f2cfb870e4169c48b2578b4eb0beaee6c391189ba82e4584d5 tor-browser-linux64-3.0-alpha-1_en-US.tar.xz abc771efa43b62d3f7055528913622e1c657acb20dbdfcfebabcf25b16f20a4b tor-browser-linux64-3.0-alpha-1_es-ES.tar.xz fe9a7905073089870d7f19857d9bc1e1d7e508ea283519ddb9abd24d6b6a0d6f tor-browser-linux64-3.0-alpha-1_fa.tar.xz bc2849260e716c5e4cab7e7e157f6cf2bbea93533c5692f466bce964bff25677 tor-browser-linux64-3.0-alpha-1_fr.tar.xz 6564a05774a602557af3eb3ffbedbb542c0d966a69ee8997be56eb1ab0a02c0c tor-browser-linux64-3.0-alpha-1_it.tar.xz d92f5d527e7aa48cbe500b84e8d1c69da0a716329f2b3203fdd2d5aacb8e5856 tor-browser-linux64-3.0-alpha-1_ko.tar.xz 81dddc65e0534902d7c1a7f39f4235e9d11e449d75647555c1ca4c04625eea63 tor-browser-linux64-3.0-alpha-1_nl.tar.xz 5b678842584503a6ddd6e40c7759ff14b0d87ca9f1a6721b2c6a10355ef97e35 tor-browser-linux64-3.0-alpha-1_pl.tar.xz 3df16ccf393169d8057d11ec4d85cb2940ddfb7f65c37c2607870f9c16b28efa tor-browser-linux64-3.0-alpha-1_pt-PT.tar.xz 371777984b02897f25b6515b61db22b9fbfa0c78d253d19fc5aade754a26c74b tor-browser-linux64-3.0-alpha-1_ru.tar.xz cfc4118a8345a8226c4638ad4719a7b12e5d3efd7faf5d8575fd2b341d510956 tor-browser-linux64-3.0-alpha-1_vi.tar.xz a49a8906e0f3013e2e02c41b68bde961d25100c1a27a8a497f5cd2bcb8764c27 tor-browser-linux64-3.0-alpha-1_zh-CN.tar.xz 951ae9027cb398e7721f9fff2af357c032316b64738bf7867035dc4697da8f3a torbrowser-install-3.0-alpha-1_de.exe c0d17168b2e2c8d9d8762da62f207d3660494cb0fe4879217db0c2902a553abb torbrowser-install-3.0-alpha-1_en-US.exe ab219b4f862aa86fedeadfde723158c5c2d4d84514d91b9fa6012d3b90c95646 torbrowser-install-3.0-alpha-1_es-ES.exe f8047706446d1dc112768edd01f1af246b1b57408b307d19996b39ffeaaba452 torbrowser-install-3.0-alpha-1_fa.exe 22e2b4d76df62185f3d011bf061cb75b173a0171c8198f21baff66ccde2905e2 torbrowser-install-3.0-alpha-1_fr.exe 370aea69718e443d3ede77d772ebb1ec2a0517e3d8b9f68573fa70dd9871a208 torbrowser-install-3.0-alpha-1_it.exe ad2032d82862177fd9e07a0aa9b65720a6f4817322760de44db9fcd84d016f50 torbrowser-install-3.0-alpha-1_ko.exe 29c72de44e65a6f5f0ee83ba79e5db13d430e2d7dda244528d16f540ad1db21f torbrowser-install-3.0-alpha-1_nl.exe bd524c8dce296db2c1f9c09b024886faffc28bf4407526b2f310fdf66459faed torbrowser-install-3.0-alpha-1_pl.exe 178f87dad198a565b13a419e5d10eabd760e09feb9e892d5d0baf6259fed3f58 torbrowser-install-3.0-alpha-1_pt-PT.exe d803200c16e17f8165463e416d5d043d1edcd9a564b9734f7c83feed8c2d55d1 torbrowser-install-3.0-alpha-1_ru.exe f623e459eb4579a6de1e2014cfdfcd2059b78d16fafb6d8e3873ab26d0e8bda0 torbrowser-install-3.0-alpha-1_vi.exe c888e325784048067698b59c9db0798fba23a83b53cc645ad6d83f7b1abf3f57 torbrowser-install-3.0-alpha-1_zh-CN.exe --8<---------------cut here---------------end--------------->8---

2 1