tor-dev September 2011

tor-dev@lists.torproject.org

25 participants
24 discussions

Thandy and what's next
by Tomas Touceda 13 May '12

13 May '12

Hello everyone, Thandy, for those who haven't heard about it by now, in few words is a package system for Tor packages and the like. One of the biggest problems we have right now is keeping users' Tor up to date, so we are trying to make time to get this going. (For more detailed information about Thandy check [1], specially the doc/ and specs/ directories) A couple of months ago, nickm and erinn worked in writing the package format spec (see [2] for more details), and now I'm going to start working as fast as I can (which may be slow) in implementing this last spec and get a working Thandy. On the more technical side, the idea is to implement this in Python as a first approach. In terms of distribution, Python isn't the best choice for platforms like Windows, but right now porting Thandy to another language isn't among the top priorities. This will probably be merged with the alpha track of releases we are making, so this can have as much testing as it can before going to stable. [1] https://gitweb.torproject.org/thandy.git/tree [2] https://gitweb.torproject.org/erinn/thandy.git/blob/934300a7c4c6c0493bedaf0… Cheers, -- Tomas Touceda Gentoo Developer - Qt, Scheme, Lisp

4 4

Proposal 186: Multiple addresses for one OR or bridge
by Nick Mathewson 17 Jan '12

17 Jan '12

Filename: 186-multiple-orports.txt Title: Multiple addresses for one OR or bridge Author: Nick Mathewson Created: 19-Sep-2011 Supersedes: 118 Status: Draft Overview: This document is a proposal for servers to advertise multiple address/port combinations for their ORPort. It supersedes proposal 118. Motivation: Sometimes servers want to support multiple ports for incoming connections, either in order to support multiple address families (ie, to add IPv6 support), to better use multiple interfaces, or to support a variety of FascistFirewallPorts settings. This is easy to set up now, but there's no way to advertise it to clients. Configuring additional addresses and ports: In consonance with our changes to the (Socks|Trans|NATD|DNS)Port options made in 0.2.3.x for proposal 171, I make a corresponding change to allow multiple SocksPort options and deprecate SocksListenAddress. The new syntax will be: "SocksPort" PortDescription Options? Options = "NoAdvertise" | "NoListen" | "AllAddrs" | "IPV4Only" | "IPV6Only" PortDescription = PORTLIST | ADDRESS ":" PORTLIST | Hostname ":" PORTLIST (PORTLIST and ADDRESS are defined below.) The 'NoAdvertise' option performs the function of the old SocksListenAddress option. If it is set, we bind a port, but don't put it in our descriptor. The 'NoListen' option tells Tor to advertise an address, but not bind to it. The operator needs to use some other mechanism to ensure that ports are redirected to ports that _are_ listened on. The 'AllAddrs' option tells Tor that if no address is given in the PortDescription part, we should bind/advertise every one of our publicly visible unicast addresses; and that if a hostname address is given in the PortDescription, we should bind/advertise every publicly visible unicast address that the hostname resolves to. (Q: Should this be on by default?) The 'IPv4Only' and 'IPv6Only' options tell Tor to interpret such situations as applying only to IPv4 addresses or to IPv6 addresses. As with the client *Port options, only the old format or the new format are allowed: either a single numeric socksport and zero or more sockslistenaddress options, or a set of one or more SocksPorts in the new extended format. In current operating systems (unless we get into crazy nonportable tricks) we need to use one socket for every address:port that Tor bind on. As a sanity check, we can limit the number of such sockets we use to, say, 64. If you want to bind lots more address:port combinations, you'll want to do it at the firewall/routing level. Example: We want to bind on 0.0.0.0:9001 SocksPort 9001 Example: Our firewall is redirecting ports 80, 443, and 7000-8000 on all hosts in x.244.2.0/24 onto our port 2929. SocksPort 2929 no-advertise SocksPort x.244.2.0/24:80,443,7000-8000 no-listen Example: We have a dynamic DNS provider that maps tornode.example.com to our current external IPv4 and IPv6 addresses. Our firewall forwards port 443 on those address to our port 1337. SocksPort 1337 no-advertise alladdrs SocksPort tornode.example.com:443 no-bind alladdrs Self-testing: Right now, Tor nodes need to check every port that they advertise before they declare themselves reachable. If a Tor has a lot of advertised ports, that could be prohibitive. Instead, it should try a sample of ports for each address. It should not advertise any given SocksPort line until it has tried extending to or connecting to a sample of the address/port combinations. It will now be possible for a Tor node to find that some addresses work and others do not. In this case, the node should only advertise socksport lines that have been checked. {Until support is added for extend cells to IPv6 addresses, it will only be possible to test IPv6 addresses by connecting directly. We might want to just skip self-testing those until we have IPv6 extend support.} New descriptor syntax: We add a new line in the router descriptor, "or-address". This line can occur zero, one, or multiple times. Its format is: or-address SP ADDRESS ":" PORTLIST NL ADDRESS = IP6ADDR | IP4ADDR IPV6ADDR = an ipv6 address, surrounded by square brackets. IPV4ADDR = an ipv4 address, represented as a dotted quad. PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST PORTSPEC = PORT | PORT "-" PORT PORT = a number between 1 and 65535 inclusive. [This is the regular format for specifying sets of addresses and ports in Tor.] A descriptor should not include an or-address line that does nothing but duplicate the address:port pair from its "router" line. A node must not list more than 8 or-address lines. (Q: Any reason to allow more than 2? Multiple interfaces, I guess.) New authority behavior: The same rationale applies as for self-testing. An authority needs to test the main address:port from the router line, and every or-address line. For or-address lines that contains multiple ports, it needs to test all of them if they are few, or a sample if they are not. An authority shouldn't list a node as Running unless every or-address line it advertises looks like it will work. Consensus directories and microdescriptors: We introduce a new line type for microdescriptors and consensuses, "a". Each "a" line has the same format as an or-address line. The "a" lines (if any) appear immediately after the "r" line for a router in the consensus, and immediately after the "onion-key" entry in a microdescriptor. Clients that use microdescriptors should consider a node's addresses to be the address:port listed in the "r" line of a consensus, plus all "a" lines for that node in the consensus, plus all "a" lines for that node in the its microdescriptor. Clients that use full descriptors should consider a node's addresses to be everything listed in its descriptor. We will have to define a new voting algorithm version; when using this version or later, votes should include a single "a" line for every relay that has an IPv6 address, to include the first IPv6 line in its descriptor. (If there are no or-address lines, then they shouldn't include any "a" lines.) The remaining or-address lines will turn into "a" lines in the microdescriptor. As with other data in the vote derived from the descriptor, the vote will include whichever set of "a" lines are given by the most authorities who voted for the descriptor digest that will be used for the router. Directory authorities with more addresses: We need a way for a client to configure a TrustedDirServer as having multiple OR addresses, specifically so that we can give at least one default authority an IPv6 address for bootstrapping purposes. (Q: Do any of the current authorities have stable IPv6 addresses?) We will want to allow the address in a "dir-source" line in a vote to contain an IPv6 address, and/or allow voters to list themselves with more addresses in votes/consensuses. But right now, nothing actually uses the addresses listed for voters in dir-source lines for anything besides log messages. Client behavior: I propose that initially we shouldn't change client behavior too much here. (Q: Is there any advantage to having a client choose a random address? If so we can do it later. If not, why list any more than one IPv4 and one IPv6 address?) Tor clients not running with bridges, and running with IPv4 support, should still use the address and ORPort as advertised in the router or r line of the appropriate directory object. Tor clients not running with bridges, and running without IPv4 support, should use the first listed IPv6 address for a node, using the lowest-numbered listed port for that address. They should only connect to nodes with an IPv6 address. Clients should accept Bridge lines with IPv6 addresses, and address:port sets, in addition to the lines they currently accept. Clients, for now, should only use the address:port from the router line when making EXTEND cells; see below. Nodes without IPv4 addresses: Currently Tor requires every node or bridge to have an IPv4 address. We will want to maintain this property for the foreseeable future, but we should define how a node without an IPv4 address would advertise itself. Right now, there's no way to do that: if anything but an IPv4 address appears in a router line of a routerdesc, or the "r" line of a consensus, then it won't parse. If something that looks like an IPv4 address appears there, clients will (I believe) try to connect to it. We can make this work, though: let's allow nodes to list themselves with a magic IPv4 address (say, 127.1.1.1) if they have or-address entries containing only IPv6 address. We could give these nodes a new flag other than Running to indicate that they're up, and not give them the Running flag. That way, old clients would never try to use them, but new clients could know to treat the new flag as indicating that the node is running, and know not to connect to a node listed with address 127.1.1.1. Interaction with EXTEND and NETINFO: Currently, EXTEND cells only support IPv4 addresses, so we should use only those. There is a proposal draft to support more address types. A server's NETINFO cells must list all configured addresses for a server. Why not extend DirPort this way too? Because clients are all using BEGINDIR these days. That is, clients tunnel their directory requests inside OR connections, and don't generally connect to DirPorts at all. Why not have address ranges? Earlier drafts of this proposal suggested that clients should provide not only ranges of ports, but also ranges of addresses, specified with bitmasks. That's a neat idea for circumvention, but if we did that, you wouldn't want to advertise publicly that you have an entire address range. Coding impact: In addition to the obvious changes, we need to audit everything that looks up or compares OR connections and nodes by address:port under the assumptions that each node has only a single address or ORPort.

5 5

New paper by Goldberg, Stebila, and Ostaoglu with proposed circuit handshake
by Nick Mathewson 16 Jan '12

16 Jan '12

Crypto people who have been following threads about the circuit-establishment handshake will be interested in the new paper, "Anonymity and one-way authentication in key-exchange protocols", by Goldberg, Stebila, and Ostaoglu. Here's the version they updated today: http://www.cacr.math.uwaterloo.ca/techreports/2011/cacr2011-11.pdf If we're moving to an improved handshake, this might be a good candidate to consider. The protocol itself is on page 14. Some notes, written by a guy who knows less crypto than everybody involved: * It's a pure Diffie-Hellman based system, which would lend itself nicely to use with ECC. * It seems to require the same number of exponentiations as our current system, but Ian Goldberg notes that if you want to compute X^a and X^b at the same time you can do so more efficiently by taking into account the shared base. * The security proof requires that the Gap DH assumption holds over the group -- basically, that computing the Decisional DH problem is easy, but computing the Computational DH problem is hard. This assumption isn't true of most basic ECC groups -- I think it means you need to use a pairing-based system instead for the proof to hold. I'd bet that the authors aren't seriously suggesting that we use pairing-based crypto, but I'm wondering how much they were able to prove in a groups where DDH is hard. * I haven't read over the security model closely yet; folks should review it for reasonableness. * I'm hoping to write this up as a proposed spec soon, unless Ian or somebody wants to give it a shot. yrs, -- Nick

8 29

Sanitizing and publishing our web server logs
by Karsten Loesing 01 Dec '11

01 Dec '11

Hi everyone, we have been discussing sanitizing and publishing our web server logs for quite a while now. The idea is to remove all potentially sensitive parts from the logs, publish them in monthly tarballs on the metrics website, and analyze them for top visited pages, top downloaded packages, etc. See the tickets #1641 and #2489 for details. Here's a suggested sanitizing procedure for our web logs, which are in Apache's combined log format: - Ignore everything except GET requests. - Ignore all requests that resulted in a 404 status code. - Rewrite log lines so that they only contain the following fields: - IP address 0.0.0.0 for HTTP request or 0.0.0.1 for HTTPS requests (as logged by our Apache configuration), - the request date (with the time part set to 00:00:00), - the requested URL (cut off at the first encountered "?"), - the HTTP version, - the server's HTTP status code, and - the size of the returned object. - Write all lines from a given virtual host and day to a single output file. - Sort the output file alphanumerically to conceal the original order of requests. Here's a sample sanitized log file for www.torproject.org from May 1, 2009 (462K): http://freehaven.net/~karsten/volatile/www.torproject.org-access.log-200905… Is there still anything sensitive in that log file that we should remove? For example: - Do the logs reveal how many pages were cached already on the requestor's site (e.g. as repeat accesses)? Note that log files are sorted before being published. - Are there other concerns about making these sanitized log files publicly available? Are the decisions to remove parts from the logs reasonable? In particular: - Do we have to take out all requests with 404 status codes? Some of these requests for non-existing URLs contain typos which may not be safe to make public. Should we instead put in some placeholder for the URL part and keep the 404 lines to know how many 404's we have per day? - Is there any good reason to keep the portion of a URL after a "?"? - Is it possible to leave some part of Referers in the logs that helps us figure out where our traffic originates and what search terms people use to find us? - Can we resolve client IP addresses to country codes and include those in the logs instead of our 0.0.0.0/0.0.0.1 code for HTTP/HTTPS? How would we handle countries with only a few users per day, e.g., should there be a threshold below which we consider requests to come from "a country with less than XY users?" Thanks, Karsten

6 10

Re: [tor-dev] Proposal 178: Require majority of authorities to vote for consensus parameters
by Nick Mathewson 27 Nov '11

27 Nov '11

On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn <hahn.seb(a)web.de> wrote: > Design: > > When the consensus is generated, the directory authorities ensure that > a param is only included in the list of params if at least half of the > total number of authorities votes for that param. The value chosen is > the low-median of all the votes. We don't mandate that the authorities > have to vote on exactly the same value for it to be included because > some consensus parameters could be the result of active measurements > that individual authorities make. This is possibly bikeshed, but I would suggest that instead of requiring half of existing authorities to vote on a particular parameter, we require 3 or more to vote on it. (As a degenerate case, fall back to "at least half" if there are fewer than 6 authorities in the clique.) I think we don't want the number to be _less_ than 3, since 3 is the smallest number of parties who can come up with a low-median that isn't just the diktat of a single member (1 party), or as low as either member wants it to be (2 parties). yrs, -- Nick

2 7

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

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

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

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

01 Oct '11

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

2 2

(no subject)
by Mohammad Mo 30 Sep '11

30 Sep '11

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2011