October 2011 - tor-dev - lists.torproject.org

Proposal 188: Bridge Guards and other anti-enumeration defenses
by Nick Mathewson 12 Jun '12

12 Jun '12

Filename: 188-bridge-guards.txt Title: Bridge Guards and other anti-enumeration defenses Author: Nick Mathewson Created: 14 Oct 2011 Status: Open 1. Overview Bridges are useful against censors only so long as the adversary cannot easily enumerate their addresses. I propose a design to make it harder for an adversary who controls or observes only a few nodes to enumerate a large number of bridges. Briefly: bridges should choose guard nodes, and use the Tor protocol's "Loose source routing" feature to re-route all extend requests from clients through an additional layer of guard nodes chosen by the bridge. This way, only a bridge's guard nodes can tell that it is a bridge, and the attacker needs to run many more nodes in order to enumerate a large number of bridges. I also discuss other ways to avoid enumeration, recommending some. These ideas are due to a discussion at the 2011 Tor Developers' Meeting in Waterloo, Ontario. Practically none of the ideas here are mine; I'm just writing up what I remember. 2. History and Motivation Under the current bridge design, an attacker who runs a node can identify bridges by seeing which "clients" make a large number of connections to it, or which "clients" make connections to it in the same way clients do. This has been a known attack since early versions {XXXX check} of the design document; let's try to fix it. 2.1. Related ideas: Guard nodes The idea of guard nodes isn't new: since 0.1.1, Tor has used guard nodes (first designed as "Helper" nodes by Wright et al in {XXXX}) to make it harder for an adversary who controls a smaller number of nodes to eavesdrop on clients. The rationale was: an adversary who controls or observes only one entry and one exit will have a low probability of correlating any single circuit, but over time, if clients choose a random entry and exit for each circuit, such an adversary will eventually see some circuits from each client with a probability of 1, thereby building a statistical profile of the client's activities. Therefore, let each client choose its entry node only from among a small number of client-selected "guard" nodes: the client is still correlated with the same probability as before, but now the client has a nonzero chance of remaining unprofiled. 2.2. Related idea: Loose source routing Since the earliest versions of Onion Routing, the protocol has provided "loose source routing". In strict source routing, the source of a message chooses every hop on the message's path. But in loose source routing, the message traverses the selected nodes, but may also traverse other nodes as well. In other words, the client selects nodes N_a, N_b, and N_c, but the message may in fact traverse any sequence of nodes N_1...N_j, so long as N_1=N_a, N_x=N_b, and N_y=N_c, for 1 < x < y. Tor has retained this feature, but has not yet made use of it. 3. Design Every bridge currently chooses a set of guard nodes for its circuits. Bridges should also re-route client circuits through these circuits. Specifically, when a bridge receives a request from a client to extend a circuit, it should first create a circuit to its guard, and then relay that extend cell through the guard. The bridge should add an additional layer of encryption to outgoing cells on that circuit corresponding to the encryption that the guard will remove, and remove a layer of encryption on incoming cells on that circuit corresponding to the encryption that the guard will add. 3.1. An example This example doesn't add anything to the design above, but has some interesting inline notes. - Alice has connected to her bridge Bob, and built a circuit through Bob, with the negotiated forward and reverse keys KB_f and KB_r. - Alice then wants to extend the circuit to node Charlie. She makes a hybrid-encrypted onionskin, encrypted to Charlie's public key, containing her chosen g^x value. She puts this in an extend cell: "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) (Charlie's ID)". She encrypts this with KB_f and sends it as a RELAY_EARLY cell to Bob. - Bob receives the RELAY_EARLY cell, and decrypts it with KB_f. He then sees that it's an extend cell for him. So far, this is exactly the same as the current procedure that Alice and Bob would follow. Now we diverge: - Instead of connecting to Charlie directly, Bob makes sure that he is connected to his guard, Guillaume. Bob uses a CREATE_FAST cell (or a CREATE cell, but see 4.1 below) to open a circuit to Guillaume. Now Bob and Guillaume share keys KG_f and KG_b. - Now Bob encrypts the Extend cell body with KG_f and sends it as a RELAY_EARLY cell to Guillaume. - Guillaume receives it, decrypts it with KG_f, and sees: "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) (Charlie's ID)". Guillaume acts accordingly: creating a connection to Charlie if he doesn't have one, ensuring that the ID is as expected, and then sending the onionskin in a create cell on that connection. Note that Guillaume is behaving exactly as a regular node would upon receiving an Extend cell. - Now the handshake finishes. Charlie receives the onionskin and sends Guillaume "CREATED g^y,KH". Guillaume sends Bob "E(KG_r, EXTENDED g^y KH)". (Charlie and Guillaume are still running as regular Tor nodes do today). - With this extend cell, and with all future relay cells received on this circuit, Bob first decrypts the cell with KG_r, then re-encrypts it with KB_r, then passes it to Alice. When Alice receives the cell, it will be just as she would have received if Bob had extended to Charlie directly. - With all future outgoing cells that he receives from Alice, Bob first decrypts the cell with KA_f, and if the cell does not have Bob as its destination, Bob encrypts it with KG_f before passing it to Guillaume. Note that this design does not require that our stream cipher operations be transitive, even though they are. Note also that this design requires no change in behavior from any node other than Bob the bridge. Finally, observe that even though the circuit is one hop longer than it would be otherwise, no relay's count of permissible RELAY_EARLY cells falls lower than it otherwise would. This is because the extra hop that Bob adds is done with a CREATE_FAST cell, and so he does not need to send any RELAY_EARLY cells not originated by Alice. 4. Other ideas and alternative designs In addition to the design above, there are more ways to try to prevent enumeration. 4.1. Make it harder to tell clients from bridges Right now, there are multiple ways for the node after a bridge to distinguish a circuit extended through the bridge from one originating at the bridge. (This lets the node after the bridge tell that a bridge is talking to it.) One of the giveaways here is that the first hop in a circuit is created with CREATE_FAST cells, but all subsequent hops are created with CREATE cells. In the above design, it's no longer quite so simple to tell, since all of the circuits that extend through a bridge now reach its guards through CREATE_FAST cells, whether the bridge originated them or not. (If we adopt a faster circuit extension algorithm -- for example, Goldberg, Stebila, and Ustaoglu's design instantiated over curve25519 -- we could also solve this issue by eliminating CREATE_FAST/CREATED_FAST entirely, which would also help our security margin a little.) The CREATE/CREATE_FAST distinction is not the only way for a bridge's guard to tell bridges from orginary clients, however. Most importantly, a busy bridge will open far more circuits than a client would. More subtly, the timing on response from the client will be higher and more highly variable that it would be with an ordinary client. I don't think we can make bridges behave wholly indistinguishably from clients: that's why we should go with guard nodes for bridges. 4.2. Client-enforced bridge guards What if Tor didn't have loose source routing? We could have bridges tell clients what guards to use by advertising those guard in their descriptors, and then refusing to extend circuits to any other nodes. This change would require all clients to upgrade in order to be able to use the newer bridges, and would quite possibly cause a fair amount of pain along the way. Fortunately, we don't need to go down this path. So let's not! 4.3. Separate bridge-guards and client-guards In the design above, I specify that bridges should use the same guard nodes for extending client circuits as they use for their own circuits. It's not immediately clear whether this is a good idea or not. Having separate sets would seem to make the two kinds of circuits more easily distinguishable (even though we already assume they are distinguishable). Having different sets of guards would also seem like a way to keep the nodes who guard our own traffic from learning that we're a bridge... but another set of nodes will learn that anyway, so it's not clear what we'd gain. 5. Other considerations What fraction of our traffic is bridge traffic? Will this alter our circuit selection weights? Are the current guard selection/evaluation/replacement mechanisms adequate for bridge guards, or do bridges need to get more sophisticated?

7 7

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

[Patch] or/eventdns.c
by Gisle Vanem 09 Nov '11

09 Nov '11

I've made eventdns.c + '-DEVDNS_MAIN' compile and work under Windows / MSVC. Some simple patches: * Use set_socket_nonblocking() instead of the F_SETFL hacks. * Preserve the ret-val from evdns_config_windows_nameservers(). * In main(), call network_init() to call WSAStartup() etc. * Removed 'evdns_resolv_conf_parse(DNS_OPTION_NAMESERVERS, ...' and call evdns_init() instead. This uses 'DNS_OPTIONS_ALL'. Does that really matter? Attached diff-1.txt. (sorry, I'm a Git neophyte). --gv

2 2

Reminder: one month left for big features in 0.2.3.x
by Nick Mathewson 31 Oct '11

31 Oct '11

Hi, all! This is the final reminder about the December 1 deadline for getting large stuff merged into 0.2.3.x. See http://archives.seul.org/or/dev/Jul-2011/msg00030.html for the original announcment. It should answer many questions. December 1 is the deadline for getting large features and complicated bugfixes merged into 0.2.3.x. January 6 is the deadline for new features and marginal bugfixes. I am looking forward to being able to release 0.2.3.x on a faster-than-previous-Tor-releases schedule. Please plan accordingly! cheers, -- Nick

1 0

git-rw moved hosts - new ssh host key
by Sebastian Hahn 30 Oct '11

30 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey there people who have repositories hosted on tpo hardware, weasel migrated cupani to our shiny new VM server. Along with this came a change of ssh host key, so please be ready to modify your known_hosts file accordingly when you next push. The new ssh key fingerprint is: ssh-rsa e7:a0:63:15:a6:d3:41:e3:cf:92:6e:78:ea:cb:d7:ee After doing the migration, we took the opportunity to run a full git gc --aggressive on each repository, which should result in smaller clone sizes and generally faster clones. Take this as a reminder to occasionally optimize your local repositories too, your pushes will benefit and you can reclaim some lost space :) Sorry this went through without prior notice, I hope nobody's work was interrupted. Let me know if there is anything amiss, we don't expect any kind of issues tho. All the best Sebastian -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJOrbUZAAoJEKlsb90UDJYb77AIAIXIW5bkuXVfOB8DEYwh93vN ddIlxAea8QvrY8hebqHNYGC9a/GgHkgT3+fDGRLW1EsHgTb6YzpYT4Jhnrj1BKHu 37Kn1UzIyuS1X6X1CzFKJzoa6Z2Wej8lmpcOMk5m8GXE+MTMnYV/3kAZ+qsRgJOi GLO75HIFZc4FbD/wy2xAU6it3aBMPP1wszKK30wtU0oCldo20FDeltqaXt9GlWav jimBI+AcWBhgFr6hx7FKVLsLNlNkVEeH911E7qtDTF2lNzQAh7mHnzDU4sIZ6FhK wTNJOV3n/eCiyOp6amNmWC9mk+5RO0qjtNsdG+0aiPcmeKPzNNeIPiH1oQFVBWc= =rYix -----END PGP SIGNATURE-----

1 0

Proposal 187: Reserve a cell type to allow client authorization
by Nick Mathewson 29 Oct '11

29 Oct '11

Filename: 187-allow-client-auth.txt Title: Reserve a cell type to allow client authorization Author: Nick Mathewson Created: 16-Oct-2011 Status: Open Target: 0.2.3.x Overview: Proposals 176 and 184 introduce a new "v3" handshake, coupled with a new version 3 link protocol. This is a good time to introduce other stuff we might need. One thing we might want is a scanning resistance feature for bridges. This proposal suggests a change we should make right away to enable us to deploy such a feature in future versions of Tor. Motivation: If an adversary has a suspected bridge address/port combination, the easiest way for them to confirm or disconfirm their suspicion is to connect to the address and see whether they can do a Tor handshake. The easiest way to fix this problem seems to be to give out bridge addresses along with some secret that clients should know, but which an adversary shouldn't be able to learn easily. The client should prove to the bridge that it's authorized to know about the bridge, before the bridge acts like a bridge. If the client doesn't show knowledge of the proper secret, the bridge should at like an HTTPS server or a bittorrent tracker or something. This proposal *does not* specify a way for clients to authorize themselves at bridges; rather, it specifies changes that we should make now in order to allow this kind of authorization in the future. Design: Currently, now that proposal 176 is implemented, if a server provides a certificate that indicates a v3 handshake, and the client understands how to do a V3 handshake, we specify that the client's first cell must be a VERSIONS cell. Instead, we make the following specification changes: We reserve a new variable-length cell type, "AUTHORIZE." We specify that any number of PADDING or VPADDING or AUTHORIZE cells may be sent by the client before it sends a VERSIONS cell. Servers that do not require client authorization MUST ignore such cells, except to include them when calculating the HMAC that will appear in the CLOG part of a client's AUTHENTICATE cell. We still specify that clients SHOULD send VERSIONS as their first cell; only in some future version of Tor will an AUTHORIZE cell be sent first. Discussion: This change allows future versions of the Tor client to know that some bridges need authorization, and to send them authentication before sending them anything recognizably Tor-like. The authorization cell needs to be received before the server can send any Tor cells, so we can't just patch it in after the VERSIONS cell exchange: the server's VERSIONS cell is unsendable until after the AUTHORIZE has been accepted. Note that to avoid scanning attacks, it's not sufficient to wait for a single cell, and then either handle it as authorization or reject the connection. Instead, we need to decide what kind of server we're impersonating, and respond once the client has provided *either* an authorization cell, *or* a recognizably valid or invalid command in the impersonated protocol. Alternative design: Just use pluggable transports Pluggable transports can do this too, but in general, we want to avoid designing the Tor protocol so that any particular desirable feature can only be done with a pluggable transport. That is, any feature that *every* bridge should want, should be doable in Tor proper. Also, as of 16 Oct 2011, pluggable transports aren't in general use. Past experience IMO suggests that we shouldn't offload architectural responsibilities to our chickens until they've hatched. Alternative design: Out-of-TLS authorization There are features (like port-knocking) designed to allow a client to show that it's authorized to use a bridge before the TLS handshake even happens. These are appropriate for bunches of applications, but they're trickier with an adversary who is MITMing the client. Alternative design: Just use padding. Arguably, we could only add the "VPADDING" cell type to the list of those allowed before VERSIONS cells, and say that any client authorization we specify later on will be sent as a VPADDING cell. But that design is kludgy: padding should be padding, not semantically significant. Besides, cell types are still fairly plentiful. Counterargument: specify it later We could, later on, say that if a client learns that a bridge needs authorization, it should send an AUTHORIZE cell. So long as a client never sends an AUTHORIZE to anything other than a bridge that needs authorization, it'll never violate the spec. But all things considered, it seems easier (just a few lines of spec and code) to let bridges eat unexpected authorization now than it does to have stuff fail later when clients think that a bridge needs authorization but it doesn't. Counterargument: it's too late! We've already got the prop176 branch merged and running on a few servers. But as of this writing, it isn't in any Tor version. Even if it *is* out in an alpha before we can get this proposal accepted and implemented, that's not a big disaster. In the worst case, where future clients don't know whom to send authorization to so they need to send it to _all_ v3 servers, they will at worst break their connections only to a couple of alpha versions which one hopes by then will be long-deprecated already.

3 2