- tor-dev - lists.torproject.org

torsocks-v2.0.0-rc3 NetBSD improvements
by Thomas Klausner 06 Nov '13

06 Nov '13

Hi! I've patched torsocks-v2.0.0-rc3 to compile on NetBSD. There is one warning left: syscall.c: In function 'handle_mmap': syscall.c:88:9: warning: cast from pointer to integer of different size and I haven't done any functional tests yet. What is the easiest way to do that? Attached are the patches I've used to get this far. Some additional comments: The package installs a few files where it shouldn't: share/DEBUG share/SOCKS5 share/socks-extensions.txt These belong in share/doc/torsocks instead, I guess. And what is the point of src.old inside the tarball? Cheers, Thomas

3 3

Bug 9665
by Fábio Bertinatto 05 Nov '13

05 Nov '13

Hi, I would like to start contributing to Tor development thus I picked up a bug and tried to fix it. It's the 9665: https://trac.torproject.org/projects/tor/ticket/9665 I don't know whether I understood the problem well or not but I came up with the attached (trivial) solution. Could someone please check if it's ok? Thank you. -- F. Bertinatto

2 1

Re: [tor-dev] bananaphone obfsproxy module
by David Stainton 04 Nov '13

04 Nov '13

Howdy, Thanks. Your obfsproxy is a nice piece of work. Bananaphone + Obfs2 sounds cool! Modular transport chains make a lot of sense... I like modular transports... recently for fun I wrote a VPN in Python Twisted [https://github.com/david415/hushVPN] using twisted consumers and producers. My idea was to have a modular system where transports could easily be swapped. Over UDP it's very fast and I was thinking that maybe I could reuse some of that code to write packet transports for obfsproxy. For instance Tor over ICMP, DNS etc... Obfs2 over Bananaphone over UDP? Right now the david-bananaphone branch is functional code. I've tested it with ssh. SSH over Markov chains! It's laggy but it works. Leif's design plans are interesting... He will be better at explaining it. Perhaps it does something similar to your idea of RHE + Obfs2. Briefly: RHE(CRYPTO(HAMMERTIME(TOR))) - RHE is Banaphone's markov or random weighted Reverse Hash Encoding - CRYPTO is NaCl crypto_stream - Hammertime: "adds chaff to a bytestream to impede passive timing analysis" The goal is to not have any distinguishable patterns in the byte stream. Is that what Obfs2 accomplishes? We will do the crypto_stream secret key exchange using NaCl crypto_box and Elligator; spewing noise after keys are sent Elligator etc... We were thinking to first implement the key exchange without Elligator... and do that part later. I'm working on the basic key exchange to work in branch david-bananaphone-keyexchange https://github.com/david415/obfsproxy/tree/david-bananaphone-keyexchange I'm currently troubleshooting a problem with the message passing... Maybe I do not understand your api well enough... I'm getting strange behavior. It would help if another pair of eyes would look at this. Perhaps later I will formulate a question regarding the obfsproxy api... And I was hoping Leif would help me fix this branch: david-bananaphone-nacl-hammertime https://github.com/david415/obfsproxy/tree/david-bananaphone-nacl-hammertime I wrote a naclStreamEncoder coroutine and made hammertime_rh_server return coroutine chains with the NaCl stream encoders. It doesn't work at all... really a rough draft scribbling of code that makes the BananaPhoneBuffer unit tests through an exception... OK. I will add ALL commandline options to obfsproxy-bananaphone! OK... bandwidth overhead calculations... I'll take a look and run some tests. Onward! David On Tue, Oct 29, 2013 at 7:19 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > Greetings, > > I'm the guy who develops obfsproxy. I recently noticed that you are > writing a bananaphone module for it. The code looks good and you even > understood the pretty-much undocumented obfsproxy API! Nice! > > BTW, I thought I should let you know that we are currently writing > software that combines transports together in chains. This means that > you don't have to worry about data redundancy in bananaphone, since > you can combine it with an obfuscating transport like obfs2 to create > the following chain: > tor data -> |obfs2 encoding| ->|bananaphone encoding| -> tor bridge -> |bananaphone decoding| ->|obfs2 decoding| -> tor data > This would create a bananaphone-encoded channel which transfers > obfs2'ed Tor data (so the bananaphone traffic will look uniform, since > obfs2 data is uniform (whether uniform bananaphone traffic is useful for > censorship circumvention is a different story))). > > FWIW, we are still in the process of writing this transport > combiner. You can read more about it in: > https://trac.torproject.org/projects/tor/ticket/7167 > https://trac.torproject.org/projects/tor/ticket/9744 > https://gitweb.torproject.org/pluggable-transports/obfs-flash.git > We should also create a Wiki page about it soon, I guess. > > Anyway, this transport combiner business means that you only have to > worry about making the bananaphone transport work. It would also be > nice if the transport was configurable, so that we can tweak its > parameters easily. I would also be interested in some bandwidth > overhead calculations :) > > BTW, feel free to send me any questions you have about obfsproxy or > pluggable transports. > > Cheers! > > PS: Feel free to CC the public tor-dev mailing list in your reply if > you want.

2 2

[RELEASE] Torsocks 2.0.0-rc3
by David Goulet 03 Nov '13

03 Nov '13

Hi everyone! I just pushed the 2.0.0-rc3 tag for the torsocks rewrite. https://github.com/dgoulet/torsocks/archive/v2.0.0-rc3.tar.gz Important fixes got in especially with the testing done with firefox lately. The good news is that it works well with firefox now :). Of course, you should ALWAYS use the TBB :). Support for x86 is also fixed as well as GNU/kFreeBSD and s390/s390x. Some unit tests were contributed by Luke Gallagher. Also, thanks to Lunar, there is now a Debian experimental package! http://packages.debian.org/experimental/torsocks There are several improvements on the way also that will make it probably in the 2.1.x version. * Optimistic data * Add --only-onions option Only sockify .onion address. Asked by the Tails folks. * Support .i2p address https://lists.torproject.org/pipermail/tor-dev/2013-November/005714.html * Maybe (hopefully), rename the whole thing with a more meaninful name. (Debate to come on tor-dev ML at some point in time :) * Basic UDP DNS support. Finally, to make this project go forward, please consider helping by reviewing and testing this code base. Here is the open ticket ref.: https://trac.torproject.org/projects/tor/ticket/10007 Here is the ChangeLog for 2.0.0-rc3. 2013-11-03 torsocks 2.0.0-rc3 * Fix: add fixtures directory to EXTRA_DIST * Fix: add fixtures.h to makefile.am as EXTRA_DIST * Fix: remove DBG call in syscall() * Fix: don't lookup symbol if already found * Lookup symbols in libc in constructor * Fix: bad ret value check for default logging * Add compatibility with GNU/kFreeBSD * Fix compatibility with s390 and s390x architectures * Fix: missing registry unlock on error * Fix: undefined syscall values for x86 * Fix: check fileno returned value * Fix: torsocks.in libdir path with lib prefix * Tests: add config-file tests * Tests: add utils unit tests Thanks everyone! David

1 0

Re: [tor-dev] .i2p address support in torsocks
by str4d 02 Nov '13

02 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/03/2013 06:58 AM, David Goulet wrote: > Apparently, I failed to put the person in CC :). I subscribed to tor-dev after talking with you :) > On 02 Nov (13:47:56), David Goulet wrote: >> On 02 Nov (19:25:42), Maxim Kammerer wrote: >>> On Sat, Nov 2, 2013 at 5:58 PM, David Goulet >>> <dgoulet(a)ev0ke.net> wrote: >>>> For now, it would only be .i2p address support (like .onion). >>>> In torsocks, it's not that difficult to support both >>>> addressing. >>> >>> Does I2P's SOCKS proxy work in a way that's similar to Tor? >>> Other proxies in I2P are protocol-specific — e.g., ports >>> 4444/4445 for HTTP(S) and 6668 for IRC. I am quite sure that >>> protocol-specific local I2P proxies like HTTP and IRC strip >>> sensitive information, so providing the user with an easy >>> access to .i2p services via SOCKS might be the wrong thing to >>> do. The SOCKS information page [1] is rather scarce on details >>> of what actually goes on inside the proxy, however. >> >> For now, it's simply detecting an .i2p address, opening a >> connection to the i2p daemon and pushing the request there. The >> person at i2p I talked to told me that it's quite straight >> forward and no special SOCKS5 mangling would be needed. Specifically, the I2P tunnel runs a local SOCKS server socket that handles the standard SOCKS4/4a and SOCKS5 protocols, and any data to be sent to the .i2p address is forwarded to an I2P socket. The standard (unfiltered) SOCKS client tunnel only forwards data between the SOCKS and I2P sockets, this should be functionally similar to Tor. We also have a variant that filters IRC traffic for anonymity (using SOCKS to connect to I2P IRC networks is a common use case), but this occurs during the forwarding step, the SOCKS server socket is unchanged. If a non-.i2p address is detected, the SOCKS server opens a SOCKS client connection to a configured SOCKS outproxy. This is designed to enable chaining to Tor, but it has some bugs that need fixing (this not working reliably is why I looked into torsocks). The configured SOCKS outproxy also needs to be listening inside I2P, which adds latency. If torsocks supported separate SOCKS ports for each configured .suffix, a user could run both I2P and Tor locally and use them in parallel instead of in series. >> If there is some work to do on the protocol side like you >> mention, I would imagine that the i2p daemon does it or else... >> well there is a problem :). If there are problems with our SOCKS implementation, they can be fixed (or implemented - I2P supports datagrams, but SOCKS UDP is not yet implemented). For filtering, it is up to the user to decide if they want to use a filtered SOCKSIRC tunnel or an unfiltered SOCKS tunnel, but it should not affect torsocks usage. (I want to make it possible for different filters to be written and used, but the user still needs to be made aware of the potential dangers to anonymity of generically SOCKSifying applications [1].) str4d >> >> Putting someone from i2p in CC: >> >> Cheers! David >> >>> >>> [1] http://www.i2p2.de/socks.html >>> >>> -- Maxim Kammerer Liberté Linux: http://dee.su/liberte >>> _______________________________________________ tor-dev mailing >>> list tor-dev(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > >> _______________________________________________ tor-dev mailing >> list tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBCgAGBQJSdXoiAAoJENXeOJaUpGWyBBMH/0c39pn97sBZvBj7HaMJAde2 ucn6Ug9vd41AmxNcOEhG65wpOrfB32sfnwI7DsRAYlOhjdxdquUl1yQHzTzs7NeG VLwRNe7e7Zv7VRj9uRp6t5+0YQU6++RkzhX5Jtn7l5W+3XYq0c4lRpSpwawP4NHN Zc9MveAU1tbsQqvhsFoYoJEsADpBj+97Xf0D05buUYMttjsmKv254HhGaLpuDCpv gEY3nBDHlHZqRziwxV7WmWPIsetdkATnmkUqcoCIPbZzJh2j6W3rZmHUieGU9OPC M3offV3ImZd/gSVcKW1rzDEEZh2mDcmg0XkwMbsEwc/LCn15y5jPk2yFlGpKKsE= =u2QY -----END PGP SIGNATURE-----

2 1

.i2p address support in torsocks
by David Goulet 02 Nov '13

02 Nov '13

Greetings everyone! I've been approached by I2P folks for adding ".i2p" address support in Torsocks. Since what torsocks does can be applied for both Tor and I2P, they felt that duplicating was not a good idea thus asking if merging both systems make sense and is possible. For now, it would only be .i2p address support (like .onion). In torsocks, it's not that difficult to support both addressing. I'm all for it, I don't see why it should not be done so I'm asking the community what do you think about that :). I can already see a question coming after this email being "Well there is "Tor" in torsocks". I'll keep that for an other thread because the whole naming of torsocks is on my todo list of things to discuss but before that I prefer getting the rewrite accepted. Thus, the naming is an "issue" but I want to address it later on (not only because of i2p). Cheers! David

6 8

two new proposals for bridgedb
by isis 02 Nov '13

02 Nov '13

I separated out the backend database improvements to BridgeDB from the social bridge distributor proposal. The former is finished and up for review and is being submitted to potential funders; the latter is still a draft (though now that some parts of the underlying crypto scheme and the threat model are detailed, early review is always helpful if anyone is super eager to point fingers at any mistakes I've made). Copies of both proposals are attached, and are also available in the common BridgeDB repo at https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… and https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

two new proposals for bridgedb
by isis agora lovecruft 02 Nov '13

02 Nov '13

I separated out the backend database improvements to BridgeDB from the social bridge distributor proposal. The former is finished and up for review and is being submitted to potential funders; the latter is still a draft (though now that some parts of the underlying crypto scheme and the threat model are detailed, early review is always helpful if anyone is super eager to point fingers at any mistakes I've made). Copies of both proposals are attached, and are also available in the common BridgeDB repo at https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… and https://gitweb.torproject.org/bridgedb.git/blob/refs/heads/feature/7520-soc… -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Project "Cute" - Design document and challenges - draft
by SiNA Rabbani 01 Nov '13

01 Nov '13

Dear Team, Sorry for multiple emails, I failed to send to tor-dev@ properly. Here is an attempt, a first attempt at the "Cute" project. Please let me have your comments and suggestions. https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Cute All the best, SiNA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ "Cute" design and challenges - draft 0.1 By: SiNA Rabbani - sina redteam io *Overview* Project Cute is part of the Otter contract. This project is to provide (in the parlance of our time) "point-click-publish" hidden services to support more effective documenting and analysis of information and evidence documenting of ongoing human rights violations and corresponding training and advocacy Our goal is to improve hidden services so that they're more awesome, and to create a packaged hidden-service blogging platform which is easy for users to run. *Objective* To make secure publishing available to activists who are not IT professionals. *Activities* Tor offers Hidden Services, the ability to host web sites in the Tor Network. Deploying hidden services successfully requires the ability to configure a server securely. Mistakes in setup can be used to unmask site admins and the location of the server. Automating this process will reduce user error. We have to write "point-click-publish" plugins that work with existing blogging and micro-blogging software. *Expected results* The result will be a way to provide portals to submit text, pictures, and video. These sites will not have the ability to log information that can be used to track down citizen journalists or other users, and will be resistant to distributed denial of service (DDoS) attacks. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *Introduction* This document describes the technical risks associated with running a web-based blog tool and exposing it over a hidden service (.onion address). Our goal is to create a packaged blogging platform that is easy to operate for the non-technical user, while protecting the application from a set of known attacks that can reveal and compromise the network identity. Hidden-services make it possible for content providers and citizen journalists to offer web-applications such as blogs and websites, hosted completely behind a firewall (NAT Network) never revealing the public IP of such services. By design, Hidden Services are resilient to attacks such as traffic analysis and DDoS, therefore it becomes compelling for the adversary to focus on the application layer vulnerabilities. According to OWASP Top 10, Injection is the number one security risk for web applications. "Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker?s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization." [1] Running a site such as WordPress involves a LAMP (Linux, Apache, Mysql, PHP) installation. This stack needs to be carefully configured and implemented to meet the desired privacy and security requirements. However, default configuration files are not suitable for privacy and lead to the leakage of identity. WordPress is the most popular blog platform on the Internet. We select WordPress due to it's popular and active core development. WordPress features a plug-in architecture and a template system, "Plugins can extend WordPress to do almost anything you can imagine. In the directory you can find, download, rate, and comment on all the best plugins the WordPress community has to offer." http://wordpress.org/plugins/ Themes and plugins are mostly developed by programmers with little or no security in mind. New code is easily added to the site without the need for any programming skills. This is recipe for disaster, a quick look at the publicly available plugin repository and security forums reveals many of the OWASP top 10 vulnerabilities such as XSS and injection vulnerabilities: http://packetstormsecurity.com/search/?q=wordpress http://wordpress.org/plugins/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *Adversary Model* We use the range of attacks available to the adversary adversary as the base for our Threat Model and proposed requirements. *Adversary Goals* *Code Injection* This is the most direct compromise that can take place; the ability for the adversary to execute code on the host machine is disastrous. *XSS the front-end, DoS the back-end* The adversary can overwhelm the database backed or the web-server of a dynamically hosted application, denying access to the service. *Location/Identity information* Applications that are not designed with privacy in mind tend to reveal information by default. For example, WordPress includes the name of the editor of a post inside the RSS feed: <dc:creator>John Smith</dc:creator> *Adversary Capabilities - Positioning* The adversary can position themselves at a number of places to execute their attacks. *Local Network/ISP/Upstream Provider* The attacker can hijack the DNS of the plugin repository or perform a man-in-the-middle attack and push malicious code into the blog. *Third party service providers* It is common for a blog to email authentication information. This information is at risk of social and legal attacks. The repository of the blog's source code where themes and plugins are downloaded is a target for the adversary to insert malicious code. *Adversary Capabilities - Attacks* The adversary can perform the following attacks in order to accomplish varies aspects of their goals. Most of these attacks are due to the dynamic and Web 2.0 nature of blog platforms. *SQL Injection & XSS* Dynamic sites take advantage of databases for content storage and JavaSript for client-side presentation. Programming mistakes can lead to code injection on server or client side. *Inserting plugins or core updates* Blog platforms have automatic update install features, WordPress connects to a remote repositories to download updated code. Adversary can perform a man-in-the-middle attack and insert malicious code. *Misbehaving plugins/features* Some plugins depend on remote connections to provide a feature, for e which can lead to leakage of identity. *Brute-force the admin password* Weak passwords are vulnerable to brute-force attacks. Blog engines do not provide protection against such attacks. *Remotely exploiting the LAMP stack* A determined adversary has a very large attack surface to analyze and discover 0-day vulnerabilities in Apache, PHP or Mysql applications. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *Proposed requirement* *Dynamic to Static* A simple yet effective way to protect dynamic websites is to save a 100% static copy, hosted with a lightweight and well configured http server. We propose Nginx which is a free, open-source, high-performance HTTP server. We have the option of extending existing WordPress plugins such as "Really-Static" (HTTP://word press.or/plugins/really-static/) to generate 100% static files. *Disable Comments and New User signup (POST REQUESTS)* The ability to receive and store comments involves actions and configurations that expose the installation to DoS and other web attacks. We propose to completely disable reader's backed interactions, specifically disabling New User Registration and Comment features. *SOCKS Proxy support for WordPress* WordPress has the ability to proxy its outgoing connections, however the current implementation only supports HTTP proxy. We propose to submit a patch to WordPress core, enabling SOCKS Proxy support: http://core.trac.wordpress.org/browser/tags/3.6.1/wp-includes/class-http.php *Update safety* Tor Project or a partner such as WordPress.org should maintain the latest copy of the WordPress source-code over a .onion address. This will allow for the Core application updates to take place without ever leaving the Tor network and we achieve end-to-end encryption without relying on the traditional SSL/CA model. *OnionPress plugin* Instead of hard-coding our modifications to control WordPress' functionalities, we propose to develop a custom plugin. The plugin will provide a new menu in the Administrative panel of the site. Providing options to interact with Hidden Service features. (Note that Administrative features are going to be restricted from the public and only available to localhost) *User Authentication/Permission Levels* a) Blog Administrator This person is hosting the blog on a local computer and has physical access to the installation. There is only 1 of such role. This login will be restricted to localhost only. b) Blog editors/contributors These are the active content publishers. Each person has the ability to remotely connect, login and publish content. Editors do not have any administrative permissions such as adding or deleting users. Each editor is assigned a dedicated key and .onion hostname using the HidServAuth and HiddenServiceAuthorizeClient features in stealth mode. "HiddenServiceAuthorizeClient auth-type client-name,client-name,… If configured, the hidden service is accessible for authorized clients only. The auth-type can either be 'basic' for a general-purpose authorization protocol or 'stealth' for a less scalable protocol that also hides service activity from unauthorized clients. Only clients that are listed here are authorized to access the hidden service. Valid client names are 1 to 19 characters long and only use characters in A-Za-z0-9+-_ (no spaces). If this option is set, the hidden service is not accessible for clients without authorization any more. Generated authorization data can be found in the hostname file. Clients need to put this authorization data in their configuration file using HidServAuth." c) Readers (the world) These are the site visitors, they will be able to send GET requests to the .onion address and receive HTML and multimedia content. No login or comment posting permissions granted. *Packaged System* We propose to design and develop a Debian based Live OS that can be started as a Virtual Machine or to boot a personal computer. This OS will include Tor, LAMP stack and a running copy of WordPress. The LAMP installation will be hardened and configured to meet our security desires. We require a secondary USB disk for persistent storage. Desired outcome is a point-and-click and maybe portable solution that can be launched from inside of Windows, Linux or Mac OSX. VirtualBox is a second candidate to host the VM. http://wiki.qemu.org/Main_Page and/or https://www.virtualbox.org/ *Edge Cache Nodes* In order to provide "blazing-fast" access to the published content outside of the Tor network, we propose the deployment of caching servers operated by semi-trusted third party organizations or persons. These are similar to tor2web nodes:http://tor2web.or/ The content providers (bloggers) would select from a list of available edge servers and send a pgp signed zip file of the latest static version over Tor. Edge servers will reduce traffic from the Tor network, also provide a chance for content to reach the world in case of a DDoS or technical issues with the Tor network itself. Having cached copies available remotely make it possible for the blogger to get on-line, publish content and go back off-line, minimizing the amount of time and traffic spent on the Internet. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Proposal 221: Stop using CREATE_FAST
by Nick Mathewson 31 Oct '13

31 Oct '13

Filename: 221-stop-using-create-fast.txt Title: Stop using CREATE_FAST Authors: Nick Mathewson Created: 12 August 2013 Target: 0.2.5.x Status: Open 0. Summary I propose that in 0.2.5.x, Tor clients stop sending CREATE_FAST cells, and use CREATE or CREATE2 cells instead as appropriate. 1. Introduction The CREATE_FAST cell was created to avoid the performance hit of using the TAP handshake on a TLS session that already provided what TAP provided: authentication with RSA1024 and forward secrecy with DH1024. But thanks to the introduction of the ntor onionskin handshake in Tor 0.2.4.x, for nodes with older versions of OpenSSL, the TLS handshake strength lags behind with the strength of the onion handshake, and the arguments against CREATE no longer apply. Similarly, it's good to have an argument for circuit security that survives possible breakdowns in TLS. But when CREATE_FAST is in use, this is impossible: we can only argue forward-secrecy at the first hop of each circuit by assuming that TLS has succeeded. So let's simply stop sending CREATE_FAST cells. 2. Proposed design Currently, only clients will send CREATE_FAST, and only when they have FastFirstHopPK set to its default value, 1. I propose that we change "FastFirstHopPK" from a boolean to also allow a new default "auto" value that tells Tor to take a value from the consensus. I propose a new consensus parameter, "usecreatefast", default value taken to be 1. Once enough versions of Tor support this proposal, the authorities should set the value for "usecreatefast" to be 0. In the series after that (0.2.6.x?), the default value for "FastFirstHopPK" should be 0. (Note that CREATE_FAST must still be used in the case where a client has connected to a guard node or bridge without knowing any onion keys for it, and wants to fetch directory information from it.) 3. Alternative designs We might make some choices to preserve CREATE_FAST under some circumstances. For example, we could say that CREATE_FAST is okay if we have a TLS connection with a cipher, public key, and ephemeral key algorithm of a given strength. We might try to trust the TLS handshake for authentication but not forward secrecy, and come up with a first-hop handshake that did a simple curve25519 diffie-hellman. We might use CREATE_FAST only whenever ntor is not available. I'm rejecting all of the above for complexity reasons. We might just change the default for FastFirstHopPK to 1 in 0.2.5.x-alpha. It would make early users of that alpha easy for their guards to distinguish. 4. Performance considerations This will increase the CPU requirements on guard nodes; their cpuworkers would be more heavily loaded as 0.2.5.x is more adopted. I believe that, if guards upgrade to 0.2.4.x as 0.2.5.x is under development, the commensurate benefits of ntor will outweigh the problems here. This holds even more if we wind up with a better ntor implementation or replacement. 5. Considerations on client detection Right now, in a few places, Tor nodes assume that any connection on which they have received a CREATE_FAST cell is probably from a non-relay node, since relays never do that. Implementing this proposal would make that signal unreliable. We should do this proposal anyway. CREATE_FAST has never been a reliable signal, since "FastFirstHopPK 0" is easy enough to type, and the source code is easy enough to edit. Proposal 163 and its successors have better ideas here anyway.

3 4