[tor-dev] Pluggable Transports v1 spec rewrite.
Hello all, In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention, I have drafted a re-write of the spec. This is not intended to alter existing behavior, but instead make it clear that the whole "Pluggable Transports" thing isn't just for Tor. Unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented. Regards, -- Yawning Angel Pluggable Transport Specification (Version 1) Abstract Pluggable Transports (PTs) are a generic mechanism for the rapid development and deployment of censorship circumvention, based around the idea of modular sub-processes that transform traffic to defeat censors. This document specifies the sub-process startup, shutdown, and inter-process communication mechanisms required to utilize PTs. Table of Contents 1. Introduction 1.1. Requirements Notation 2. Architecture Overview 3. Specification 3.1. Pluggable Transport Naming 3.2. Pluggable Transport Configuration Environment Variables 3.2.1. Common Environment Variables 3.2.2. Pluggable Transport Client Environment Variables 3.2.3. Pluggable Transport Server Environment Variables 3.3. Pluggable Transport To Parent Process Communication 3.3.1. Common Messages 3.3.2. Pluggable Transport Client Messages 3.3.3. Pluggable Transport Server Messages 3.4. Pluggable Transport Shutdown 3.5. Pluggable Transport Client Per-Connection Arguments 4. Tor Configuration (torrc directives) 4.1. Client Configuration 4.1.1. ClientTransportPlugin 4.1.2. Bridge 4.2. Server Configuration 4.2.1. ServerTransportPlugin 4.2.2. ServerTransportListenAddr 4.2.3. ServerTransportOptions 5. Anonymity Considerations 6. Future Improvements 7. References 8. Acknowledgments Appendix A. Example Client Pluggable Transport Session Appendix B. Example Server Pluggable Transport Session 1. Introduction This specification describes a way to decouple protocol-level obfuscation from an application's client/server code, in a manner that promotes rapid development of obfuscation/circumvention tools and promotes reuse beyond the scope of the Tor Project's efforts in that area. This is accomplished by utilizing helper sub-processes that implement the necessary forward/reverse proxy servers that handle the censorship circumvention, with a well defined and standardized configuration and management interface. Any application code that implements the interfaces as specified in this document will be able to use all spec compliant Pluggable Transports. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Architecture Overview +++---+ | Client App +-- Local Loopback --+ PT Client (SOCKS Proxy) +--+ +++---+ | | Public Internet (Obfuscated/Transformed traffic) ==> | | +++---+ | | Server App +-- Local Loopback --+ PT Server (Reverse Proxy) +--+ +++---+ On the client's host, the PT Client software exposes a SOCKS proxy [RFC1928] to the client application, and obfuscates or otherwise transforms traffic before forwarding it to the server's host. On the server's host, the PT Server software exposes a reverse proxy that accepts connections from PT Clients, and handles reversing the obfuscation/transformation applied to traffic, before forwarding it to the actual server software. An optional lightweight protocol exists to facilitate communicating connection meta-data that would otherwise be lost such as the source IP address and port [EXTORPORT]. All PT instances are configured by the respective parent process via a set of standardized environment variables (3.2) that are set at launch time, and report status information back to the parent via writing output in a standardized format to stdout (3.3). Each invocation of a PT MUST be either a client OR a server. All PT client forward proxies MUST support either SOCKS 4 or SOCKS 5, and SHOULD prefer SOCKS 5 over SOCKS 4. 3. Specification Pluggable T
Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting
teor writes: >> On 29 Oct 2015, at 05:26, David Goulet wrote: >> >> Finally, we would like your opinion also on if we should keep the >> conflict mechanism or not?. Since those partition attacks are basically >> dumb, do not achive much result for an attacker and it's at a high cost >> of comprimising a directory authority, should we keep them? Keep in mind >> that it adds a layer of complexity in the code especially with shared >> random keys which rotates every 30 days and are only available in the >> vote of an authority. It gets difficult to validate a conflict of an >> authority if we haven't seen yet a vote from that authority. There are >> ways to fix that code wise but is this worth it considering that every >> partition attack will be detected anyway by DocTor? One argument to keep >> it is resilience of the protocol. With conflict line, if one dirauth >> does stupid things, it will get ignored for the rest of the protocol run >> so we can still compute a fresh random value in the end. Again, does it >> worth it? > > The protocol is already resilient because if there is a failure, it still > produces a (predictable) value based on the previous value. As long as a > misbehaving authority can't mess with this fallback behaviour, and as long as > sufficient directory authority operators can react within 24 hours to remove a > misbehaving authority, then this seems ok to me. > Thanks for the feedback teor! > A few questions: > > Do we expect 24 or 48 hours of shared random downtime in the event of an > incident, taking into account response time to remove an authority? > Hm, I admit I have not thought too much about the response procedure in case of an incident. I've mainly been relying on the fact that these attacks are not worth doing, and no one is going to bother. However that sounds like a stupid thing to rely on so having an incident response procedure might be much smarter!!! The obvious thing would be to remove the dirauth if we are sure that it was an attack. Of course, there will need to be some investigation of the "was this an attack or a bug" type that might take some time... Maybe we should add a BadSharedRandomnessAuth flag that will block a dirauth from this protocol till the investigation is complete. Or maybe this is a stupid idea. > What would an authority do when it detects a conflict under the new proposal? > Ignore it (pick the numerically higher value?) and expect DocTor to detect it? > The spec seems to say: When a conflict line is seen in a vote, an authority should verify the commit values (see [VALIDATEVALUES]) that they are in fact coming from the authority identified by "identity" and if so, ignore that authority until the next protocol run. If the conflict line is invalid, ignore it. More on conflict detection on my next point. > What if an authority changes shared random signing keys partway through a > round? Good question! Fortunately, I think we can handle this. First, we include the shared randomness key in the votes of each dirauth, then we also mandate that the authoritative commitments in each vote are signed by the current shared randomness key. This means that other dirauths should always be able to verify the signatures of the commitments in a vote. Here is a proposed procedure to handle key rotation: 1) When Alice receives a valid commitment from dirauth Bob, it saves the commitment values (timestamp, H(REVEAL), etc.) and the shared randomness public key in its state. 2) When Alice, later in the protocol run, receives another valid commitment from dirauth Bob, it needs to verify the new signature and check that the commitment values *did not change*. If the signature is valid and the commitment values are the same, then we consider the commitment and authority trusted. How does that sound to you? We should probably write this procedure down in the spec, maybe. And we should also have tests to ensure that this works smoothly, because as you said it definitely happen eventually. --- However, key rotation *does* make the commit conflict mechanism more complicated. The reason is that when Alice receives a conflict line from dirauth Bob: "shared-rand-conflict" SP identity SP commit1 SP commit2 NL she doesn't know which shared randomness key to use for which commit. If she already knows a shared randomness key for 'identity', then she can try to use that to verify both signatures. However, the conflicting attacker could have rotated shared randomness keys and could have signed 'commit2' using a different SR key than 'commit1'. In this case, if Alice does not know both SR keys, she is unable to verify the validity of the conflict line. In that case, should she trust the conflict line or not? I guess not, otherwise Bob could just craft fake conflict lines and feed them to other auths. However, if we don't trust the conflict line, then the attacker can again partition the authorities by causing everyone to
Re: [tor-dev] Pluggable Transports v1 spec rewrite.
Hi, A commendable effort. It is both deserved and pleasant that Tor hold the "gold standard" for a low latency, privacy enhancing, distributed, collaborative network. A perhaps more crowning achievement could be the fostering of a diverse ecosystem of related technologies. This effort continues to signal the Tor community's belief in open, free(dom), collaboration in the space. Hats off ! Hugo Date: Thu, 29 Oct 2015 13:19:01 + From: Yawning Angel To: tor-dev@lists.torproject.org Subject: [tor-dev] Pluggable Transports v1 spec rewrite. Message-ID: <20151029131901.3bbe0...@schwanenlied.me> Content-Type: text/plain; charset="us-ascii" Hello all, In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention, I have drafted a re-write of the spec. This is not intended to alter existing behavior, but instead make it clear that the whole "Pluggable Transports" thing isn't just for Tor. Unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented. Regards, -- Yawning Angel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable Transports v1 spec rewrite.
On Thu, Oct 29, 2015, at 09:19 AM, Yawning Angel wrote: > Hello all, > > In an attempt to make Pluggable Transports more accessible to other > people, and to have a spec that is more applicable and useful to other > projects that seek to use Pluggable Transports for circumvention, I have > drafted a re-write of the spec. > > This is not intended to alter existing behavior, but instead make it > clear that the whole "Pluggable Transports" thing isn't just for Tor. > > Unless people have serious objections, this will replace the existing > PT spec, to serve as a stop-gap while the next revision of the PT spec > (that does alter behavior) is being drafted/implemented. > Any small or big changes to highlight that push us to the more accessible goal? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable Transports v1 spec rewrite.
Excellent work on the rewrite. To summarize for those that do not have time to read the whole document, it's the same spec, it's just been rewritten to read more clearly. I think it's a great improvement over the previous version. I have two suggestions: Section 4, "Tor Configuration", I think should be moved into another document and a reference should be added instead. While it's useful for developers reading the PT spec to see how to configure their Tor nodes so they can test their PTs, this information is going to be used mostly by bridge operators. Bridge operators shouldn't have to go to the PT spec to figure out how to configure their bridge. PT developers though will need to configure a bridge anyway, so I think it's sensible to at the end of the PT spec send them to the bridge configuration documentation and the PT configuration section specifically. Section 6 "Future Improvements" I think should be moved into a PT roadmap document. There is a lot to discuss regarding future improvements. My list for the most part does not overlap with this list. We could engage in healthy debate over what should go in the future improvements section, but this seems to me to be something better done when drafting a roadmap document rather than in the spec. It would of course be useful to add a reference to any roadmap documentation at the end of the spec. On Thu, Oct 29, 2015 at 8:19 AM, Yawning Angel wrote: > Hello all, > > In an attempt to make Pluggable Transports more accessible to other > people, and to have a spec that is more applicable and useful to other > projects that seek to use Pluggable Transports for circumvention, I have > drafted a re-write of the spec. > > This is not intended to alter existing behavior, but instead make it > clear that the whole "Pluggable Transports" thing isn't just for Tor. > > Unless people have serious objections, this will replace the existing > PT spec, to serve as a stop-gap while the next revision of the PT spec > (that does alter behavior) is being drafted/implemented. > > Regards, > > -- > Yawning Angel > > ___ > 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
Re: [tor-dev] Pluggable Transports v1 spec rewrite.
On Thu, 29 Oct 2015 10:27:53 -0400 Nathan Freitas wrote: > Any small or big changes to highlight that push us to the more > accessible goal? Well, it emphasizes that it's generic, gives a better view of the architecture, and should be usable by anyone competent (unless my rewrite is bad) to add support for Pluggable Transports to any client/server code base. All the Tor specific stuff is neatly contained in it's own section now that people can be free to ignore. Stuff it still should do: * Fold in the ExtORPort spec since that's useful for people that aren't tor. * Document the tor pt external mode torrc configuration format (In my defense, the current spec doesn't do this either). So, yes? Dunno. There's a limit to how far I can de-torify this sort of document, and I think this is a reasonable step in the right direction. Regards, -- Yawning Angel pgp2LOhKYB67e.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal 258: Denial-of-service resistance for directory authorities
[Here's a new proposal from Andrea. See ticket 4581 for implementation details.] Filename: 258-dirauth-dos.txt Title: Denial-of-service resistance for directory authorities Author: Andrea Shepard Created: 2015-10-27 Status: Open 1. Problem statement The directory authorities are few in number and vital for the functioning of the Tor network; threats of denial of service attacks against them have occurred in the past. They should be more resistant to unreasonably large connection volumes. 2. Design overview There are two possible ways a new connection to a directory authority can be established, directly by a TCP connection to the DirPort, or tunneled inside a Tor circuit and initiated with a begindir cell. The client can originate the former as direct connections or from a Tor exit, and the latter either as fully anonymized circuits or one-hop links to the dirauth's ORPort. The dirauth will try to heuristically classify incoming requests as one of these four indirection types, and then in the two non-anonymized cases further sort them into hash buckets on the basis of source IP. It will use an exponentially-weighted moving average to measure the rate of connection attempts in each bucket, and also separately limit the number of begindir cells permitted on each circuit. It will periodically scan the hash tables and forget counters which have fallen below a threshold to prevent memory exhaustion. 3. Classification of incoming connections Clients can originate connections as one of four indirection types: - DIRIND_ONEHOP: begindir cell on a single-hop Tor circuit - DIRIND_ANONYMOUS: begindir cell on a fully anonymized Tor circuit - DIRIND_DIRECT_CONN: direct TCP connection to dirport - DIRIND_ANON_DIRPORT: TCP connection to dirport from an exit relay The directory authority can always tell a dirport connection from a begindir, but it must use its knowledge of the current consensus and exit policies to disambiguate whether the connection is anonymized. It should treat a begindir as DIRIND_ANONYMOUS when the previous hop in the circuit it appears on is in the current consensus, and as DIRIND_ONEHOP otherwise; it should treat a dirport connection as DIRIND_ANON_DIRPORT if the source address appears in the consensus and allows exits to the dirport in question, or as DIRIND_DIRECT_CONN otherwise. In the case of relays which also act as clients, these heuristics may falsely classify direct/onehop connections as anonymous, but will never falsely classify anonymous connections as direct/onehop. 4. Exponentially-weighted moving average counters and hash table The directory authority implements a set of exponentially-weighted moving averages to measure the rate of incoming connections in each bucket. The two anonymous connection types are each a single bucket, but the two non- anonymous cases get a single bucket per source IP each, stored in a hash table. The directory authority must periodically scan this hash table for counters which have decayed close to zero and free them to avoid permitting memory exhaustion. This introduces five new configuration parameters: - DirDoSFilterEWMATimeConstant: the time for an EWMA counter to decay by a factor of 1/e, in seconds. - DirDoSFilterMaxAnonConnectRate: the threshold to trigger the DoS filter on DIRIND_ANONYMOUS connections. - DirDoSFilterMaxAnonDirportConnectRate: the threshold to trigger the DoS filter on DIRIND_ANON_DIRPORT connections. - DirDoSFilterMaxBegindirRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_ONEHOP connections. - DirDoSFilterMaxDirectConnRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_DIRECT_CONN connections. When incrementing a counter would put it over the relevant threshold, the filter is said to be triggered. In this case, the directory authority does not update the counter, but instead suppresses the incoming request. In the DIRIND_ONEHOP and DIRIND_ANONYMOUS cases, the directory authority must kill the circuit rather than merely refusing the request, to prevent an unending stream of client retries on the same circuit. 5. Begindir cap Directory authorities limit the number of begindir cells permitted in the lifetime of a particular circuit, separately from the EWMA counters. This can only affect the DIRIND_ANONYMOUS and DIRIND_ONEHOP connetion types. A sixth configuration variable, DirDoSFilterMaxBegindirPerCircuit, controls this feature. 6. Limitations Widely distributed DoS attacks with many source IPs may still be able to avoid raising any single DIRIND_ONEHOP or DIRIND_DIRECT_CONN counter above threshold. ___ tor-dev mailing list tor-dev@lists.torproject.or
[tor-dev] [proposal] New Entry Guard Selection Algorithm
Hello, For your reviewing pleasure, may I present you with a new (draft) proposal for a new entry guard selection algorithm, and associated data structures (with reference implementations!). [0] The bulk of it is based upon George Kadianakis' recent email and pseudocode. [1] [2] There are still a few XXXs which need elucidation and/or comment. Relevant tickets include: https://bugs.torproject.org/17261 https://bugs.torproject.org/17262 https://bugs.torproject.org/16120 https://bugs.torproject.org/12466 https://bugs.torproject.org/12450 https://bugs.torproject.org/12595 Assistance with the completion of #17262 (due 31 Oct) would be greatly appreciated, since my plan for tomorrow is to work with some of the cryptographers here to review my changes to the crypto in rBridge for #7520. [0]: https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=bug17261-best-guess&id=c9a9acb2 [1]: https://lists.torproject.org/pipermail/tor-dev/2015-August/009328.html [2]: https://gitweb.torproject.org/user/asn/tor.git/tree/src/or/guardlist.c?h=bug12595 Best regards, -- ♥Ⓐ isis agora lovecruft _ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor Messenger Beta: Chat over Tor, Easily
Hi, Today we are releasing a new, beta version of Tor Messenger, based on Instantbird [0], an instant messaging client developed in the Mozilla community. * What is it? Tor Messenger is a cross-platform chat program that aims to be secure by default and sends all of its traffic over Tor. It supports a wide variety of transport networks, including Jabber (XMPP), IRC, Google Talk, Facebook Chat, Twitter, Yahoo, and others; enables Off-the-Record (OTR) Messaging [1] automatically; and has an easy-to-use graphical user interface localized into multiple languages. * What it isn't... Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor. We are also excited about systems like Pond [2] and Ricochet [3], which try to solve this problem, and would encourage you to look at their designs and use them too. * Why Instantbird? We considered a number of messaging clients: Pidgin, Adam Langley's xmpp-client, and Instantbird. Instantbird was the pragmatic choice -- its transport protocols are written in a memory-safe language (JavaScript); it has a graphical user interface and already supports many natural languages; and it's a XUL application, which means we can leverage both the code (Tor Launcher) and in-house expertise that the Tor Project has developed working on Tor Browser with Firefox. It also has an active and vibrant software developer community that has been very responsive and understanding of our needs. The main feature it lacked was OTR support, which we have implemented [4] and hope to upstream to the main Instantbird repository for the benefit of all Instantbird (and Thunderbird) users. * Current Status Today we are releasing a beta version with which we hope to gain both usability and security related feedback. There have been three previous alpha releases to the mailing lists that have already helped smooth out some of the rougher edges. * Downloads Linux (32-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux32-0.1.0b2_en-US.tar.xz Linux (64-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux64-0.1.0b2_en-US.tar.xz Windows https://dist.torproject.org/tormessenger/0.1.0b2/tormessenger-install-0.1.0b2_en-US.exe OS X https://dist.torproject.org/tormessenger/0.1.0b2/TorMessenger-0.1.0b2-osx64_en-US.dmg sha256sums https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt.asc The sha256sums.txt file containing hashes of the bundles is signed with the key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391). * Instructions - On Linux, extract the bundle(s) and then run: ./start-tor-messenger.desktop - On OS X, copy the Tor Messenger application from the disk image to your local disk before running it. On all platforms, Tor Messenger sets the profile folder for Firefox/Instantbird to the installation directory. - Note that as a policy, unencrypted one-to-one conversations are not allowed and your messages will not be transmitted if the person you are talking with does not have an OTR-enabled client. You can disable this option in the preferences to allow unencrypted communication but doing so is not recommended. * Source Code We are doing automated builds [5] of Tor Messenger for all platforms. The Linux builds are reproducible: anyone who builds Tor Messenger for Linux should have byte-for-byte identical binaries compared with other builds from a given source. You can build it yourself [6] and let us know if you encounter any problems or cannot match our build. The Windows and OS X builds are not completely reproducible yet but we are working on it [7]. * What's to Come Our current focus is security, robustness and user experience. We will be fixing bugs and releasing updates as appropriate, and in the future, we plan on pairing releases with Mozilla's Extended Support Release (ESR) cycle. We have some ideas on where to take Tor Messenger but we would like to hear what you have to say. Some possibilities include: - Reproducible builds for Windows and OS X (#10942) - Sandboxing (#10943) - Automatic updates (#14388) - Improved Tor support (#10950) - OTR over Twitter DMs (#13312) - Produce (and distribute) internationalized builds (#10945) - Secure multi-party communication (np1sec) [8] - Encrypted file-transfers - Usability study * How To Help Give it a try and provide feedback, requests, and file bugs [9] (choose the "Tor Messenger" component). If you are a developer, help us close all our tickets [10] or help us review our design doc [11]. As always, we are id
Re: [tor-dev] [proposal] New Entry Guard Selection Algorithm
On Thu, Oct 29, 2015 at 5:01 PM, isis wrote: > Hello, > > For your reviewing pleasure, may I present you with a new (draft) proposal for > a new entry guard selection algorithm, and associated data structures (with > reference implementations!). [0] The bulk of it is based upon George > Kadianakis' recent email and pseudocode. [1] [2] There are still a few XXXs > which need elucidation and/or comment. > > Relevant tickets include: > https://bugs.torproject.org/17261 > https://bugs.torproject.org/17262 > https://bugs.torproject.org/16120 > https://bugs.torproject.org/12466 > https://bugs.torproject.org/12450 > https://bugs.torproject.org/12595 > > Assistance with the completion of #17262 (due 31 Oct) would be greatly > appreciated, since my plan for tomorrow is to work with some of the > cryptographers here to review my changes to the crypto in rBridge for #7520. Woo, this is now proposal 259. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [Applications Team] First meeting next Tuesday 19:00 UTC
Hi, just a reminder that the applications team is starting the monthly meetings next week on Tuesday, November 3 at 19:00 UTC[0] in #tor-project on irc.oftc.net. The proposed topic is still talking about UX/internationalization issues. If there are other things worth discussing we can easily amend the agenda at the beginning of the meeting. See you there, Georg [0] Originally I had written "18:00 UTC" but I forgot to take the end of the summer time into account. 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
