tor-dev October 2012

tor-dev@lists.torproject.org

25 participants
31 discussions

Proposal: Increase Acceptable Consensus Age
by Mike Perry 17 Oct '12

17 Oct '12

Also available at: https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/tolerate-old-… ---------------------------------- Title: Increase Acceptable Consensus Age Author: Mike Perry Created: 01-10-2012 Status: Open Target: 0.2.4.x+ Overview This proposal aims to extend the duration that clients will accept old consensus material under conditions where the directory authorities are either down or fail to produce a valid consensus for an extended period of time. Motivation Currently, if the directory authorities are down or fail to consense for 24 hours, the entire Tor network will cease to function. Worse, clients will enter into a state where they all need to re-bootstrap directly from the directory authorities, which will likely exacerbate any potential DoS condition that may have triggered the downtime in the first place. The Tor network has had such close calls before. In the past, we've been able to mobilize a majority of the directory authority operators within this 24 hour window, but that is only because we've been exceedingly lucky and the DoS conditions were accidental rather than deliberate. If a DoS attack was deliberately timed to coincide with a major US and European combined holiday such as Christmas Eve, New Years Eve, or Easter, it is very unlikely we would be able to muster the resources to diagnose and deploy a fix to the authorities in time to prevent network collapse. Description Based on the need to survive multi-day holidays and long weekends balanced with the need to ensure clients can't be captured on an old consensus forever, I propose that the consensus liveness constants be set at 3 days rather than 24 hours. This requires updating two consensus defines in the source, and one descriptor freshness variable. The descriptor freshness should be set to a function of the consensus freshness. See Implementation Notes for further details. Security Concerns: Using an Old Consensus Clients should not trust old consensus data without an attempt to download fresher data from a directory mirror. As far as I could tell, the code already does this. The minimum consensus age before we try to download new data is two hours. However, the ability to accept old consensus documents does introduce the ability of malicious directory mirrors to feed their favorite old consensus document to clients to alter their paths until they download a fresher consensus from elsewhere. Directory guards (Proposal 207) may exacerbate this ability. This proposal does not address such attacks, and seeks only a modest increase in the valid timespan as a compromise. Future consideration of these and other targeted-consensus attacks will be left to proposals related to ticket #7126[1]. Once those proposals are complete and implemented, raising the freshness limit beyond 3 days should be possible. Implementation Notes There appear to be at least three constants in the code involved with using potentially expired consensus data. Two of them (REASONABLY_LIVE_TIME and NS_EXPIRY_SLOP) involve the consensus itself, and two (OLD_ROUTER_DESC_MAX_AGE and TOLERATE_MICRODESC_AGE) deal with descriptor liveness. Two additional constants ROUTER_MAX_AGE and ROUTER_MAX_AGE_TO_PUBLISH are only used when submitting descriptors for consensus voting. FORCE_REGENERATE_DESCRIPTOR_INTERVAL is the maximum age a router descriptor will get before a relay will re-publish. It is set to 18 hours. OLD_ROUTER_DESC_MAX_AGE is set at 5 days. TOLERATE_MICRODESC_AGE is set at 7 days. The consensus timestamps are used in networkstatus_get_reasonably_live_consensus() and networkstatus_set_current_consensus(). OLD_ROUTER_DESC_MAX_AGE is checked in routerlist_remove_old_routers(), router_add_to_routerlist(), and client_would_use_router(). It is my opinion that we should combine REASONABLY_LIVE_TIME and NS_EXPIRY_SLOP into a single define, and make OLD_ROUTER_DESC_MAX_AGE a function of REASONABLY_LIVE_TIME and FORCE_REGENERATE_DESCRIPTOR_INTERVAL: #define REASONABLY_LIVE_TIME (3*24*60*60) #define NS_EXPIRY_SLOP REASONABLY_LIVE_TIME #define OLD_ROUTER_DESC_MAX_AGE \ (REASONABLY_LIVE_TIME+FORCE_REGENERATE_DESCRIPTOR_INTERVAL) Based on my review of the above code paths, these changes should be all we need to enable clients to use older consensuses for longer while still attempting to fetch new ones. 1. https://trac.torproject.org/projects/tor/ticket/7126 -- Mike Perry

2 1

tor decrypt packet
by esolve esolve 16 Oct '12

16 Oct '12

HI, I capture packets on the tor client using tcpdump and I want to decrypt the captured packets for analysis. I think there are two steps 1 obtain the session keys 2 use some tools to decrypt the packets Are there any ways, tools, methodology to decrypt the packets? thanks!

1 0

Re: [tor-dev] Proposal 211: Internal Mapaddress for Tor Configuration Testing
by Nick Mathewson 15 Oct '12

15 Oct '12

On Thu, Oct 11, 2012 at 5:38 AM, Mike Perry <mikeperry(a)torproject.org> wrote: > Also at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/mapaddress-ch… > > --------------------------------------------------------------- > > Title: Internal Mapaddress for Tor Configuration Testing > Author: Mike Perry > Created: 08-10-2012 > Status: Open > Target: 0.2.4.x+ > > > Overview > > This proposal describes a method by which we can replace the > https://check.torproject.org/ testing service with an internal XML > document provided by the Tor client. > > Motivation > > The Tor Check service is a central point of failure in terms of Tor > usability. If it is ever out of sync with the set of exit nodes on the > Tor network or down, user experience is degraded considerably. Moreover, > the check itself is very time-consuming. Users must wait seconds or more > for the result to come back. Worse still, if the user's software *was* > in fact misconfigured, the check.torproject.org DNS resolution and > request leaks out on to the network. > > Design Overview > > The system will have three parts: an internal hard-coded IP address > mapping (127.84.111.114:80), a hard-coded mapaddress to a DNS name > (selftest.torproject.org:80), and a DirPortFrontPage-style simple > HTTP server that serves an XML document for both addresses. The use of XML and HTTP here are both reasons for some unhappiness. Both of them pull in a fair amount of complexity that I'd prefer not to need. (Yes, Tor already has a sort of an HTTP implementation, but at least clients aren't currently required to run what amounts to a local HTTP server.) I seriously wonder whether the benefits of HTTP (easier to access from within a locked-down web browser environment) aren't actually the _defects_ of HTTP here: it's easier to poke it from a web page. I understand that your design takes some steps to prevent browser-based attacks on this, but I'm not currently sure how to become sure that that it solves them all. Right now, I'm nervous. > Upon receipt of a request to the IP address mapping, the system will > create a new 128 bit randomly generated nonce and provide it > in the XML document. > > Requests to http://selftest.torproject.org/ must include a valid, > recent nonce as the GET url path. Upon receipt of a valid nonce, > it is removed from the list of valid nonces. Nonces are only valid > for 60 seconds or until SIGNAL NEWNYM, which ever comes first. So, I'm not totally sure what the nonce field is for. The idea as I understand it is that when you connect to the IPv4 address, you get a nonce, and later when you connect to the hostname, you provide that nonce, and Tor tells you "yes" if you gave it the same nonce. What does that protect against? My first thought is that you're trying to prevent the case where a malicious local DNS server maps "selftest.torproject.org" to some IP address in their control, and then just runs a server at that IP address to say "yes I'm Tor". But that doesn't make sense, since you could just make one of those that said "yes I'm Tor" no matter what you say for the nonce. Also, how useful is the followup DNS check? If it's checking that DNS leaks aren't happening... You're going to need torbrowser or something of equivalent complexity for this to work at all; isn't it easier then for torbrowser to make sure that it set up SOCKS ? > The list of pending nonces should not be allowed to grow beyond 10 > entries. This means that any webpage could flush out the list of pending nonces. Does that matter? > The timeout period and nonce limit should be configurable in torrc. > > Design: XML document format for http://127.84.111.114 > [...] > Security Considerations > > XML was chosen over JSON due to the risks of the identifier leaking > in a way that could enable websites to track the user[1]. Well, that's a nuclear-powered-flyswatter! If I read that page right, the problem with using JSON is that it can be parsed and executed as Javascript, and the advantage of XML is that it's unlikely to be syntactically correct javascript, then maybe instead we should If that's the issue, I'd strongly suggest that instead of going with a more complex data format, we could add a layer of encoding over the json, or use an even simpler format. > Because there are many exceptions and circumvention techniques > to the same-origin policy, we have also opted for strict controls > on dns-nonce lifetimes and usage, as well as validation of the Host > header and SOCKS4A request hostnames. Of course, this all comes down to the fact that we're using http. Can we spell out why we need HTTP for this? > 1. http://www.hpenterprisesecurity.com/vulncat/en/vulncat/dotnet/javascript_hi… > -- Nick

2 3

Re: [tor-dev] Proposal 210: Faster Headless Consensus Bootstrapping
by Nick Mathewson 15 Oct '12

15 Oct '12

On Thu, Oct 11, 2012 at 5:32 AM, Mike Perry <mikeperry(a)torproject.org> wrote: > Also at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/consensus-boo… > > ------------------------------------------------------------------------- > > Title: Faster Headless Consensus Bootstrapping > Author: Mike Perry > Created: 01-10-2012 > Status: Open > Target: 0.2.4.x+ > > > Overview and Motiviation > > This proposal describes a way for clients to fetch the initial > consensus more quickly in situations where some or all of the directory > authorities are unreachable. This proposal is meant to describe a > solution for bug #4483. > > Design: Bootstrap Process Changes > > The core idea is to attempt to establish bootstrap connections in > parallel during the bootstrap process, and download the consensus from > the first connection that completes. > > Connection attempts will be done in batches of three. Only one > connection will be performed to one of the canonical directory > authorities. Two connections will be performed to randomly chosen hard > coded directory mirrors. I misread this paragraph at first. I thought you were suggesting 3 parallel directory downloads when in fact you were discussing 3 parallel TLS connections, with only the first one that finishes actually getting a download. [...] > Design: Fallback Dir Mirror Selection Out of scope for this proposal; relevant for proposal 206. > Performance: Additional Load with Current Parameter Choices > > This design and the connection count parameters were chosen such that > no additional bandwidth load would be placed on the directory > authorities. In fact, the directory authorities should experience less > load, because they will not need to serve the consensus document for a > connection in the event that one of the directory mirrors complete their > connection before the directory authority does. To be clear, it's the part of this proposal that's shared with proposal 206 (directory sources) that would lower load on the authorities. > However, the scheme does place additional TLS connection load on the > fallback dir mirrors. Because bootstrapping is rare and all but one of > the TLS connections will be very short-lived and unused, this should not > be a substantial issue. How do we know that bootstrapping is rare? > The dangerous case is in the event of a prolonged consensus failure > that induces all clients to enter into the bootstrap process. In this > case, the number of initial TLS connections to the fallback dir mirrors > would be 2*C/100, or 10,000 for C=500,000 users. If no connections > complete before the five retries, this could reach as high as 50,000 > connection attempts, but this is extremely unlikely to happen in full > aggregate. > > However, in the no-consensus scenario today, the directory authorities > would already experience C/9 or 55,555 connection attempts. The > 5-retry scheme increases their total maximum load to about 275,000 > connection attempts, but again this is unlikely to be reached > in aggregate. Additionally, with this scheme, even if the dirauths > are taken down by this load, the dir mirrors should be able to survive > it. This looks like an argument of the form "The outcome would be horrible, but the current outcome is also horrible, so we wouldn't break stuff any worse." Right? I wonder if in this case the answer isn't to actually back off from fetching after N minutes or M servers, like a sane system. Or to treat "hey, that's not a good consensus!" as different from "couldn't connect to directory server" in terms of what it means for how we back off. -- Nick

2 1

Proposal 207: Directory guards
by Nick Mathewson 15 Oct '12

15 Oct '12

Filename: 207-directory-guards.txt Title: Directory guards Author: Nick Mathewson Created: 10-Oct-2012 Status: Open Target: 0.2.4.x Motivation: When we added guard nodes to resist profiling attacks, we made it so that clients won't build general-purpose circuits through just any node. But clients don't use their guard nodes when downloading general-purpose directory information from the Tor network. This allows a directory cache, over time, to learn a large number of IPs for non-bridge-using users of the Tor network. Proposal: In the same way as they currently pick guard nodes as needed, adding more guards as those nodes are down, clients should also pick a small-ish set of directory guard nodes, to persist in Tor's state file. Clients should not pick their own guards as directory guards, or pick their directory guards as regular guards. When downloading a regular directory object (that is, not a hidden service descriptor), clients should prefer their directory guards first. Then they should try more directories from a recent consensus (if they have one) and pick one of those as a new guard if the existing guards are down and a new one is up. Failing that, they should fall back to a directory authority (or a directory source, if those get implemented-- see proposal 206). If a client has only one directory guard running, they should add new guards and try them, and then use their directory guards to fetch multiple descriptors in parallel. Discussion: The rule that the set of guards and the set of directory guards need to be disjoint, and the rule that multiple directory guards need to be providing descriptors, are both attempts to make it harder for a single node to capture a route. Open questions and notes: What properties does a node need to be a suitable directory guard? If we require that it have the Guard flag, we'll lose some nodes: only 74% of the directory caches have it (weighted by bandwidth). We may want to tune the algorithm used to update guards. For future-proofing, we may want to have the DirCache flag from 185 be the one that nodes must have in order to be directory guards. For now, we could have authorities set it to Guard && DirPort!=0, with a better algorithm to follow. Authorities should never get the DirCache flag.

3 6

[patch] fix cparser/firm compiler warnings
by Christian Grothoff 15 Oct '12

15 Oct '12

Hi! We're trying to compile Tor with cparser and got some warnings and an error. src/or/dirserv.c:803:1: error: declaration 'was_router_added_t dirserv_add_extrainfo(extrainfo_t*, const char**)' is incompatible with 'int dirserv_add_extrainfo(extrainfo_t*, const char**)' (declared at line 96:12) src/or/dirserv.c:81:14: warning: unnecessary static forward declaration for 'char* format_versions_list(config_line_t*)' [-Wredundant-decls] src/or/dirserv.c:2186:8: warning: statement is empty [-Wempty-statement] src/or/dirserv.c:2210:8: warning: statement is empty [-Wempty-statement] src/or/dirserv.c:2752:51: warning: statement is empty [-Wempty-statement] src/or/dirserv.c:3009:51: warning: statement is empty [-Wempty-statement] src/or/dirserv.c:3280:112: warning: statement is empty [-Wempty-statement] src/or/dirserv.c:3483:54: warning: statement is empty [-Wempty-statement] src/or/dirserv.c:3603:129: warning: statement is empty [-Wempty-statement] 1 error(s), 47 warning(s) The attached patch fixes those the warnings that are unambiguously due to inconsistent style ("if (cond) {body};" -- removing extra semicolon) and fixes the warning due to inconsistently declared a return type (once declared as 'enum', once as 'int'). Is there a better place for sending patches that do not really require broad discussion? Happy hacking! Christian

3 2

txtorcon 0.6
by meejah＠meejah.ca 12 Oct '12

12 Oct '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 txtorcon 0.6 is now tagged and released. txtorcon is a Twisted-based Python asynchronous implementation of the Tor control protocol. It includes a state-tracking abstraction, configuration abstraction, Twisted endpoint support for hidden services, 96%+ unit-test coverage and many examples. New in this release: . debian packaging (mmaker); . psutil fully gone; . *changed API* for launch_tor() to use TorConfig instead of args; . TorConfig.save() works properly with no connected Tor; . fix incorrect handling of 650 immediately after connect; . pep8 compliance; . use assertEqual in tests; . messages with embdedded keywords work properly; . fix bug with setup.py + pip; . issue #15 reported along with patch by Isis Lovecruft; . consolidate requirements (from aagbsn); . increased test coverage and various minor fixes; . https URIs for ReadTheDocs Code and built documentation may be obtained: https://github.com/meejah/txtorcon https://txtorcon.readthedocs.org/en/latest/index.html git clone git://github.com/meejah/txtorcon.git You may also install it directly: pip install txtorcon easy_install txtorcon The sha256sum output is: 4f939e217ea3149175bb1285fa7296edc02ac245a71a60ec77b9cf48511e991e txtorcon-0.6.tar.gz thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iQEcBAEBAgAGBQJQd5uqAAoJEMJgKAMSgGmnTCkIAOGT6QaE+Q8jaBOedE79j/B3 QYMXh1SSfrvxn2x/utmjIgRbvCrCE+lzkxv9T9GXXjAhKSRN2xyyhRxq/Mbxvucd FWb2zHyZIjsTcc//veHYNpRNEWORl1ZIG2kU0muHQPpxY5ZAvtEkW+RA5zMJbhHp LF/JyltsAEu1Ja6HMFsfPmlLZiOtWBkBi3MgGGenUVJsScrtGRNCjWutGEkXxKXe 9pw2W0IGH5YmBAUiAuSW6q4cnyPQroqjSgO+RFfKMVGJNAaSqgUE8UCkcCifyjjM 2cDtGNA50kU0obT8QLgsiRyavePCQSfn9Jr1y8/Ck45Toa9a4FOQbBlOOyQSgrY= =bORU -----END PGP SIGNATURE-----

1 0

Proposal: Internal Mapaddress for Tor Configuration Testing
by Mike Perry 11 Oct '12

11 Oct '12

Also at: https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/mapaddress-ch… --------------------------------------------------------------- Title: Internal Mapaddress for Tor Configuration Testing Author: Mike Perry Created: 08-10-2012 Status: Open Target: 0.2.4.x+ Overview This proposal describes a method by which we can replace the https://check.torproject.org/ testing service with an internal XML document provided by the Tor client. Motivation The Tor Check service is a central point of failure in terms of Tor usability. If it is ever out of sync with the set of exit nodes on the Tor network or down, user experience is degraded considerably. Moreover, the check itself is very time-consuming. Users must wait seconds or more for the result to come back. Worse still, if the user's software *was* in fact misconfigured, the check.torproject.org DNS resolution and request leaks out on to the network. Design Overview The system will have three parts: an internal hard-coded IP address mapping (127.84.111.114:80), a hard-coded mapaddress to a DNS name (selftest.torproject.org:80), and a DirPortFrontPage-style simple HTTP server that serves an XML document for both addresses. Upon receipt of a request to the IP address mapping, the system will create a new 128 bit randomly generated nonce and provide it in the XML document. Requests to http://selftest.torproject.org/ must include a valid, recent nonce as the GET url path. Upon receipt of a valid nonce, it is removed from the list of valid nonces. Nonces are only valid for 60 seconds or until SIGNAL NEWNYM, which ever comes first. The list of pending nonces should not be allowed to grow beyond 10 entries. The timeout period and nonce limit should be configurable in torrc. Design: XML document format for http://127.84.111.114 To avoid the need to localize the message in Tor, Tor will only provide a XML object with connectivity information. Here is an example form: <tor-test> <tor-bootstrap-percent>100</tor-bootstrap-percent> <tor-version-current>true</tor-version-current> <dns-nonce>4977eb4842c7c59fa5b830ac4da896d9</dns-nonce> <tor-test/> The tor-bootstrap-percent field represents the results of the Tor client bootstrap status as integer percentages from bootstrap_status_t. The tor-version-current field represents the results of the Tor client consensus version check. If the bootstrap process has not yet downloaded a consensus document, this field will have the value null. The dns-nonce field contains a 128-bit secret, encoded in base16. This field is only present for requests that list the Host: header as 127.84.111.114. Design: XML document format for http://selftest.torproject.org/nonce <tor-test> <tor-bootstrap-percent>100</tor-bootstrap-percent> <tor-version-current>true</tor-version-current> <dns-nonce-valid>true</dns-nonce-valid> <tor-test/> The first two fields are the same as for the IP address version. The dns-nonce-valid field is only true if the Host header matches selftest.torproject.org and the nonce is current and valid. Upon receipt of a valid nonce, that nonce is removed from the list of valid nonces. Design: Request Servicing Care must be taken with the dns-nonce generation and usage, to prevent users from being tracked through leakage of nonce value to application content. While the usage of XML appears to make this impossible due to stricter same-origin policy enforcement than JSON, same-origin enforcement is still fraught with exceptions and loopholes. In particular: Any requests that contain the Origin: header MUST be ignored, as the Origin: header is only included for third party web content (CORS). dns-nonce fields MUST be omitted if the HTTP Host: header does not match the IP address 127.84.111.114. Requests to selftest.torproject.org MUST return false for the dns-nonce-valid field if the HTTP Host: header does not match selftest.torproject.org, regardless of nonce value. Further, requests to selftest.torproject.org MUST validate that 'selftest.torproject.org' was the actual hostname provided to SOCKS4A, and not some alternate address mapping (due to DNS rebinding attacks, for example). Design: Application Usage Applications will use the system in two steps. First, they will make an HTTP request to http://127.84.111.114:80/ over Tor's SOCKS port and parse the resulting XML, if any. If the request at this stage fails, the application should inform the user that either their Tor client is too old, or that it is misconfigured, depending upon the nature of the failure. If the request succeeds and valid XML is returned, the application will record the value of the dns-nonce field, and then perform a second request to http://selftest.torproject.org/nonce_value. If the second request succeeds, and the dns-nonce-valid field is true, the application may inform the user that their Tor settings are valid. If the second request fails, or does not provide the correct dns-nonce, the application will inform the user that their Tor DNS proxy settings are incorrect. If either tor-bootstrap-percent is not 100, or tor-version-current is false, applications may choose to inform the user of these facts using properly localized strings and appropriate UI. Security Considerations XML was chosen over JSON due to the risks of the identifier leaking in a way that could enable websites to track the user[1]. Because there are many exceptions and circumvention techniques to the same-origin policy, we have also opted for strict controls on dns-nonce lifetimes and usage, as well as validation of the Host header and SOCKS4A request hostnames. 1. http://www.hpenterprisesecurity.com/vulncat/en/vulncat/dotnet/javascript_hi… -- Mike Perry

2 1

Proposal: Faster Headless Consensus Bootstrapping
by Mike Perry 11 Oct '12

11 Oct '12

Also at: https://gitweb.torproject.org/user/mikeperry/torspec.git/blob/consensus-boo… ------------------------------------------------------------------------- Title: Faster Headless Consensus Bootstrapping Author: Mike Perry Created: 01-10-2012 Status: Open Target: 0.2.4.x+ Overview and Motiviation This proposal describes a way for clients to fetch the initial consensus more quickly in situations where some or all of the directory authorities are unreachable. This proposal is meant to describe a solution for bug #4483. Design: Bootstrap Process Changes The core idea is to attempt to establish bootstrap connections in parallel during the bootstrap process, and download the consensus from the first connection that completes. Connection attempts will be done in batches of three. Only one connection will be performed to one of the canonical directory authorities. Two connections will be performed to randomly chosen hard coded directory mirrors. If no connections complete within 5 seconds, another batch of three connections will be launched. Otherwise, the first connection to complete will be used to download the consensus document and the others will be closed, after which bootstrapping will proceed as normal. If at any time, the total outstanding bootstrap connection attempts exceeds 15, no new connection attempts are to be launched until existing connection attempts experience full timeout. Design: Fallback Dir Mirror Selection The set of hard coded directory mirrors from #572 shall be chosen using the 100 Guard nodes with the longest uptime. The fallback weights will be set using each mirror's fraction of consensus bandwidth out of the total of all 100 mirrors. This list of fallback dir mirrors should be updated with every major Tor release. In future releases, the number of dir mirrors should be set at 20% of the current Guard nodes, rather than fixed at 100. Performance: Additional Load with Current Parameter Choices This design and the connection count parameters were chosen such that no additional bandwidth load would be placed on the directory authorities. In fact, the directory authorities should experience less load, because they will not need to serve the consensus document for a connection in the event that one of the directory mirrors complete their connection before the directory authority does. However, the scheme does place additional TLS connection load on the fallback dir mirrors. Because bootstrapping is rare and all but one of the TLS connections will be very short-lived and unused, this should not be a substantial issue. The dangerous case is in the event of a prolonged consensus failure that induces all clients to enter into the bootstrap process. In this case, the number of initial TLS connections to the fallback dir mirrors would be 2*C/100, or 10,000 for C=500,000 users. If no connections complete before the five retries, this could reach as high as 50,000 connection attempts, but this is extremely unlikely to happen in full aggregate. However, in the no-consensus scenario today, the directory authorities would already experience C/9 or 55,555 connection attempts. The 5-retry scheme increases their total maximum load to about 275,000 connection attempts, but again this is unlikely to be reached in aggregate. Additionally, with this scheme, even if the dirauths are taken down by this load, the dir mirrors should be able to survive it. Implementation Notes: Code Modifications The implementation of the bootstrap process is unfortunately mixed in with many types of directory activity. The process starts in update_consensus_networkstatus_downloads(), which initiates a single directory connection through directory_get_from_dirserver(). Depending on bootstrap state, a single directory server is selected and a connection is eventually made through directory_initiate_command_rend(). There appear to be a few options for altering this code to perform multiple connections. Without refactoring, one approach would be to make multiple calls to directory_initiate_command_routerstatus() from directory_get_from_dirserver() if the purpose is DIR_PURPOSE_FETCH_CONSENSUS and the only directory servers available are the authorities and the fallback dir mirrors. The code in directory_initiate_command_rend() would then need to be altered to maintain a list of the dircons created for this purpose as well as avoid immediately queuing the directory_send_command() request for the DIR_PURPOSE_FETCH_CONSENSUS purpose. A flag would need to be set on the dircon to be checked in connection_dir_finished_connecting(). The function connection_dir_finished_connecting() would need to be altered to examine the list of pending dircons, determine if this one is the first to complete, and if so, then call directory_send_command() to download the consensus and close the other pending dircons. An additional timer would need to be installed to re-call update_consensus_networkstatus_downloads() or a related helper after 5 seconds. connection_dir_finished_connecting() would cancel this timer. The helper would check the list of pending connections and ensure it never exceeds 15. -- Mike Perry

2 1

Proposal 208: IPv6 Exits Redux
by Nick Mathewson 11 Oct '12

11 Oct '12

Filename: 208-ipv6-exits-redux.txt Title: IPv6 Exits Redux Author: Nick Mathewson Created: 10-Oct-2012 Status: Open Target: 0.2.4.x 1. Obligatory Motivation Section [Insert motivations for IPv6 here. Mention IPv4 address exhaustion. Insert official timeline for official IPv6 adoption here. Insert general desirability of being able to connect to whatever address there is here. Insert profession of firm conviction that eventually there will be something somebody wants to connect to which requires the ability to connect to an IPv6 address.] 2. Proposal Proposal 117 has been there since coderman wrote it in 2007, and it's still mostly right. Rather than replicate it in full, I'll describe this proposal as a patch to it. 2.1. Exit policies Rather than specify IPv6 policies in full, we should move (as we have been moving with IPv4 addresses) to summaries of which IPv6 ports are generally permitted. So let's allow server descriptors to include a list of accepted IPv6 ports, using the same format as the "p" line in microdescriptors, using the "ipv6-policy" keyword. "ipv6-policy" SP ("accept" / "reject") SP PortList NL Exits should still, of course, be able to configure more complex policies, but they should no longer need to tell the whole world about them. After this ipv6-policy line is validated, it should get copied into a "p6" line in microdescriptors. This change breaks the existing exit enclave idea for IPv6, but the exiting exit enclave implementation never worked right in the first place. If we can come up with a good way to support it, we can add that back in. 2.2. Which addresses should we connect to? One issue that's tripped us up a few times is how to decide whether we can use IPv6 addresses. You can't use them with SOCKS4 or SOCKS4a, IIUC. With SOCKS5, there's no way to indicate that you prefer IPv4 or IPv6. It's possible that some SOCKS5 users won't understand IPv6 addresses. With this in mind, I'm going to suggest that with SOCKS4 or SOCKS4a, clients should always require IPv4. With SOCKS5, clients should accept IPv6. If it proves necessary, we can also add per-SOCKSPort configuration flags to override the above default behavior. See also partitioning discussion in Security Notes below. 2.3. Extending BEGIN cells. Prop117 (and the section above) says that clients should prefer one address or another, but doesn't give them a means to tell the exit to do so. Here's one. We define an extension to the BEGIN cell as follows. After the ADDRESS | ':' | PORT | [00] portion, the cell currently contains all [00] bytes. We add a 32-bit flags field, stored as an unsigned 32 bit value, after the [00]. All these flags default to 0, obviously. We define the following flags: bit 1 -- IPv6 okay. We support learning about IPv6 addresses and connecting to IPv6 addresses. 2 -- IPv4 not okay. We don't want to learn about IPv4 addresses or connect to them. 3 -- IPv6 preferred. If there are both IPv4 and IPv6 addresses, we want to connect to the IPv6 one. (By default, we connect to the IPv4 address.) 4..32 -- Reserved. As with so much else, clients should look at the platform version of the exit they're using to see if it supports these flags before sending them. 2.4. Minor changes to proposal 117 GETINFO commands that return an address, and which should return two, should not in fact begin returning two addresses separated by CRLF. They should retain their current behavior, and there should be a new "all my addresses" GETINFO target. 3. Security notes: Letting clients signal that they want or will accept IPv6 addresses creates two partitioning issues that didn't exist before. One is the version partitioning issue: anybody who supports IPv6 addresses is obviously running the new software. Another is option partitioning: anybody who is using a SOCKS4a application will look different from somebody who is using a SOCKS5 application. We can't do much about version partitioning, I think. If we felt especially clever, we could have a flag day. Is that necessary? For option partitioning, are there many applications whose behavior is indistinguishable except that they are sometimes configured to use SOCKS4a and sometimes to use SOCKS5? If so, the answer may well be to persuade as many users as possible to switch those to SOCKS5, so that they get IPv6 support and have a large anonymity set. IPv6 addresses are plentiful, which makes caching them dangerous if you're hoping to avoid tracking over time. (With IPv4 addresses, it's harder to give every user a different IPv4 address for a target hostname with a long TTL, and then accept connections to those IPv4 addresses from different exits over time. With IPv6, it's easy.) This makes proposal 205 especially necessary here.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev October 2012