tor-dev October 2013

tor-dev@lists.torproject.org

62 participants
78 discussions

Hidden Service Scaling
by Christopher Baines 14 May '14

14 May '14

I have been looking at doing some work on Tor as part of my degree, and more specifically, looking at Hidden Services. One of the issues where I believe I might be able to make some progress, is the Hidden Service Scaling issue as described here [1]. So, before I start trying to implement a prototype, I thought I would set out my ideas here to check they are reasonable (I have also been discussing this a bit on #tor-dev). The goal of this is two fold, to reduce the probability of failure of a hidden service and to increase hidden service scalability. I think what I am planning distils down to two main changes. Firstly, when a OP initialises a hidden service, currently if you start a hidden service using an existing keypair and address, the new OP's introduction points replace the existing introduction points [2]. This does provide some redundancy (if slow), but no load balancing. My current plan is to change this such that if the OP has an existing public/private keypair and address, it would attempt to lookup the existing introduction points (probably over a Tor circuit). If found, it then establishes introduction circuits to those Tor servers. Then comes the second problem, following the above, the introduction point would then disconnect from any other connected OP using the same public key (unsure why as a reason is not given in the rend-spec). This would need to change such that an introduction point can talk to more than one instance of the hidden service. These two changes combined should help with the two goals. Reliability is improved by having multiple OP's providing the service, and having all of these accessible from the introduction points. Scalability is also improved, as you are not limited to one OP (as described above, currently you can also have +1 but only one will receive most of the traffic, and fail over is slow). I am aware that there are several undefined parts of the above description, e.g. how does a introduction point choose what circuit to use? but at the moment I am more interested in the wider picture. It would be good to get some feedback on this. 1: https://blog.torproject.org/blog/hidden-services-need-some-love 2: http://tor.stackexchange.com/questions/13/can-a-hidden-service-be-hosted-by…

11 44

Torsocks tests
by Luke Gallagher 27 Jan '14

27 Jan '14

Hi, I would like to help with the unit tests for Torsocks, I was thinking of starting with utils and config-file tests, does this sound like a reasonable place to start? regards, Luke

2 8

Design for an exit relay scanner: feedback appreciated
by Philipp Winter 03 Dec '13

03 Dec '13

I am working on a Python-based exit relay scanner which should detect malicious and misbehaving exits. The design should have a reasonable balance between being fast/parallel and stressing the network as little as possible. I came up with the following three steps: 1. Spawn a "parent" Tor process to get an up-to-date consensus. 2.1 For every selected exit relay, spawn a lightweight Tor process. 2.2 The consensus is copied from the "parent" process to the lightweight process' data directory. That way, the consensus has to be downloaded only once. 2.3 Every lightweight Tor process has the following configuration: --- SOCKSPort auto ControlPort 0 __DisablePredictedCircuits 1 UseEntryGuards 0 FetchServerDescriptors 0 DataDirectory <data_directory> ExitNodes <exit_relay> --- Entry guards are not used to distribute the load. Predicted circuits are disabled to prevent expensive creation of circuits which would not be used anyway. In addition, I am considering adding "EntryNodes" or "Bridge" to concentrate the first hop's load on machines under my control. 3. torsocks is then used to establish decoy connections over the respective exit relay. After that, the process is terminated. Any thoughts on how to further improve the design or ideas for a better one? Cheers, Philipp

7 14

Development of an HTTP PT
by dardok 25 Nov '13

25 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I am quite new in here but I am interested to help and improve the TOR system. I am interested in PTs and particularly in developing a HTTP PT. I've read some papers [0],[1],[2],[3] and the ticket #8676 and I consider that it would be a good idea to make an effort and try to implement the HTTP PT as is stated in the ticket, that is using real browser and server services. After talking with asn, we conclude that a good point to start this development may be to focus on the HTTP transport part, that is to know how to control the browser or the server and how to embed the TOR traffic into the HTTP protocol (requests and responses). Things such as the data obfuscation, the delays in the communications and the packet chopping won't be considered, because it may be used another PT such Scramblesuit to do that task. The CLIENT side: TBB <-> Scramblesuit PT <-> HTTP PT <-> CENSOR NET and the SERVER side: CENSOR NET <-> HTTP PT <-> Scramblesuit PT <-> TOR bridge The important is to know how to embed the TOR traffic already obfuscated into the requests and responses to avoid suspicion. Also as I said before, to know how to control a browser binary to make the HTTP traffic from the client side as much traditional as possible, for instance using a firefox binary or something like that. The same must be applied to the server side, implementing a real NGINX server or an Apache server on port 80 and writting some CGI to classify the traffic incoming from the TOR clients through the HTTP requests. The same server may have another CGI to write and send the HTTP responses to those TOR clients with the traffic into them. I would like to find someone interested to work on this topic. Thanks and I wait for your comments or suggestions! [0] http://www.owlfolio.org/media/2010/05/stegotorus.pdf [1] http://www.cs.kau.se/philwint/pdf/wpes2013.pdf [2] https://www.ieee-security.org/TC/SP2013/papers/4977a065.pdf [3] https://github.com/sjmurdoch/http-transport/blob/master/design.md -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSarhoAAoJEFz9RJtDk2+MsnwH/2MugLeUH+EOc6bzyKJ25W/N 5Kf9w1YdU276z5eba6+fY38H6l3hwErT6TaiWcULiVra1JshLLWaTGHS9AiP4Nf3 QTUVjUMQNiqGkLvNBIkxwqe8MQo1d5GgEhul4fYzMKS46clhmkb6lILIfZ4bRDyc 8bctM8qOk7mLVkp9Ip+ehv/J6S4wmSNtKUIj88mUyfRDDXn/+r7OQx+FDoC/3YiL XzFpaeofPgdWb35cieQvR2wWqWN3N5BRK1R7o0g02BfOYEXOxQ2KaIWUqJBiyKqo uzSAkic1a5qDpJImAQhjAVrqZi1NKZbQQM+33caWm8T9fWkNojClQZ2PzbJn0os= =zI1W -----END PGP SIGNATURE-----

5 5

Help me guague how full your plate is via regular check-in conversations
by Tom Lowenthal 20 Nov '13

20 Nov '13

Hello fighters for freedom, When applying for grants, planning future work, and otherwise thinking about what capacity we have leftover to do things in the future, it's really useful to know who's doing what and how much of it. I get some of this information from our sponsor/project-specific meetings, but it doesn't seem to be the full picture, so I'd like to trot out that old chestnut of regular one-on-one chats. This means that I'd like to spend between thirty and sixty minutes talking with each of you, once every week or two. I'd like to calibrate the frequency so that we can get calls down to 30 minutes each, with room to kvetch and have a conversation that's a little more than just rattling off deliverable status and time assignments. I think that the right group for this is the folks who post to tor-reports. If you post to tor-reports, please get back to me by the end of the week with your availability for a regular weekly check-in, as well as any thoughts you have about medium, format, or anything else. If you're not currently on tor-reports and think you should check in, or vice versa, you should probably drop me a line too. Any questions or suggestions? -Tom

5 5

Notes on HS revamping
by George Kadianakis 11 Nov '13

11 Nov '13

Hey Nick, these are my notes from when I was writing the HS blog post. I updated them a bit with some more stuff. Might be helpful :) """ HS improvements: 1 performance 1.1 reuse IPs (#8239) 1.2 torperf (#8510) 1.3 scaling https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html 1.4 valet nodes 1.5 lasse's "Improving Efficiency and Simplicity of Tor circuit establishment and hidden services" 1.5.1 big design change. maybe worth it. assumes valet nodes IIRC 2 security 2.1 Crypto upgrade 2.1.1 Upgrade id keys [https://lists.torproject.org/pipermail/tor-dev/2013-October/005536.html] [https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html] 2.1.2 Upgrade IP service keys 2.1.3 Fix hybrid encryption (?) 2.2 Onion anti-harvesting (#8106) https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html 2.3 Guard node enumeration (#9001) 2.3.1 Virtual Circuits? Guard tiers? 2.4 Unpredictable HSDirs (#8244) 2.5 Hide HS popularity 2.5.1 Oblivious transfer for HSDirs (is it needed if we have #8106? maybe yes.) 2.5.2 Unlinkable introductions in IPs (is this even possible?) (do we even care? we have service keys) 3 Can we decrease the responsibility of guard nodes? It seems that security of HSes == their guard nodes, atm. 3.1 Implement stuff from https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… 3.2 Add optional padding/bitrate anti-fingerprinting transport for HSes. 3.2.1 Can be enabled by truly paranoid HSes. 3.2.2 But this is going to make HSes stand out even more! 3.2.3 These transports can all be broken anyway. Except a truly slow but theoretically secure padding/constant bitrate transport. 3.3 What are other anonymous publishing protocols doing here? I2P seems to be weak here too, according to Grothoff's recent paper. 4 misc 4.1 HSDirs system 4.1.1 Do we still need the hash ring even after #8106? 4.1.2 Look into Valet nodes 4.2 petnames/human memorable onions? 4.2.1 maybe better as a third party (probably unofficial) plugin to tor/firefox 4.3 Read and compare with other HS-like designs. See: 4.3.1 I2P, GNUNet, rewebber, retroshare, "Anonymizing censorship resistant systems" by Serjantov, ... 4.3.2 Check uni-directional tunnels of I2P and their pros/cons. 4.3.3 http://freehaven.net/anonbib/ 4.4 Encrypted servives https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-en… 5 What else should we do? How would we design HSes if we were not prejudiced by the current design? """

4 7

[Draft Proposal] Scalable Hidden Services
by Matthew Finkel 07 Nov '13

07 Nov '13

Hi everyone, This is a proposal I wrote to implement scalable hidden services. It's by no means finished (there are some slight inconsistencies which I will be correcting later today or tomorrow) but I want to make it public in the meantime. I'm also working on some additional security measures that can be used, but those haven't been written yet. Many thanks to George for his initial feedback. I pushed this version to my public repo, and will continue to push updates there. In reality this is really 3.2 proposals, so the end result, if accepted, will look significantly different, but I'm indecisive at this point about which of the designs is least dangerous. Thanks, Matt

5 8

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev October 2013