- tor-dev - lists.torproject.org

[FWD: Re: Apple developer account + codesigning]
by Mike Perry 28 Oct '15

28 Oct '15

Here is some info about OSX codesigning, courtesy of Mike Tigas. It sounds like undoing the codesigning to verify build (and signing machine) integrity will be tricky. If anyone has more info on how to do that, it would be appreciated. ----- Forwarded message from Mike Tigas <mike(a)tig.as> ----- Date: Fri, 10 Jul 2015 01:29:02 -0400 From: Mike Tigas <mike(a)tig.as> To: Mike Perry <mikeperry(a)torproject.org> Subject: Re: Apple developer account + codesigning Hey Mike, Cool seeing y'all at that CPJ thing briefly. Yeah, that account is what you'll need to get the Apple-signed certs that let you codesign an app & allow it to launch unimpeded -- regardless of App Store or not. Used to be separate accounts for Mac vs iOS, but looks like it's just one account for everything Apple. (More info in the middle below on how to get the cert you need, etc.) On another open-source thing I work on <http://tabula.technology/>, we have a cross-platform JRuby program that we turn into a .app for Mac. We avoid the XCode IDE altogether (using a tool called `jarbundler` that turns our jar into a Mac .app bundle for us) and use the command-line "codesign" tool that comes with MacOSX or XCode (can't remember which). The invocation is basically like: codesign -f -s 'Developer ID Application: Mike Tigas (68QUP6KP2C)' /path/to/Foo.app Where the `-s` argument is the ID of the certificate you end up with from Apple -- see my comment here about "For production builds...": https://github.com/tabulapdf/tabula/blob/fe6b105ca4f84ea64975d8ddc876dce8d1… Once you have your Apple Developer account, link 3 in that comment is where you'll get your cert. There's a little wizard for it that walks you through it. (You want to be in Mac Apps -> Certificates -> All, click + to add a certificate, and you want a Production -> Developer ID, for an Application.) In our case we had to manually sign another OSX framework (Java) that we bundled with the app, so there's two invocations of the `codesign` command. We previously didn't do that (in https://github.com/tabulapdf/tabula/blob/c21b27c867ecdb578f97667310ea8b21e0… ), instead invoking `codesign` with the `--deep` flag, which tries to recursively sign all executable binaries inside the target (but there's some peculiarity with the Java OSX framework that prevented us from doing it). So just throwing that out there as another option to try. If this is for TBB or something else with a bunch of binaries inside, you'll have to keep this in mind. I've also discovered that this is a bitch to test, since once you've bypassed codesigning to open an app (doing right-click and open instead of double-clicking shows a prompt that allows a user to bypass the warning https://support.apple.com/en-us/HT202491 ), the app's whitelisted on your system. So I've historically messed up quite a few releases by signing with the wrong key, missing some bundled framework, etc, since my own work opens up fine on my own computer. I remember us vaguely talking about reproducible builds and verification, too. Guessing this ties in to the "removing signatures" part of what you said? Of course anything that happens during and after a codesign isn't reproducible for other users, but here are some notes about what `codesign` and the App Store do to built apps, particularly on iOS (but probably applicable to OSX too). https://github.com/OnionBrowser/iOS-OnionBrowser/issues/58 https://github.com/WhisperSystems/Signal-iOS/issues/641#issuecomment-782027… Essentially, codesign only touches executable binaries in the .app (see that second link for info on how the binary's segments get moved around) and also adds an SC_Info directory for codesign/DRM metadata. For App Store apps, only the SC_Info gets modified for different users for DRM. That makes it possible to actually verify an App Store app's integrity by removing that directory to check hashes -- https://github.com/OnionBrowser/iOS-OnionBrowser/releases/tag/v1.5.11 -- but you won't have this problem since you're not gonna go that route. The design (per that comment) doesn't seem to allow reversing the signing process easily due to DRM encryption of parts of the binary -- though I'm not clear on which parts are due to `codesign` locally versus magic that Apple performs on App Store-submitted applications. If the `codesign` by itself doesn't encrypt the binary (i.e. if it just rearranges the binary's segments & adds metadata & creates the metadata/DRM directory), it might be possible to reverse it. Could be worth someone exploring segment sizes/positions with `size` and `otool` http://www.objc.io/issues/6-build-tools/mach-o-executables/ to determine this for real. Ah holy shit, that is a LOT of words. But hope that helps and isn't too overwhelming. That's just about everything I know about this off the top of my head. Let me know if something isn't clear or if you run into any issues with the Apple account or something like that. Cheers, Mike Tigas Reporter/News Applications Developer, ProPublica https://www.propublica.org/ @mtigas | https://mike.tig.as/ | 0x6E0E9923 ----- End forwarded message ----- -- Mike Perry

8 14

Proposal 257: Refactoring authorities and taking parts offline
by Nick Mathewson 27 Oct '15

27 Oct '15

Filename: 257-hiding-authorities.txt Title: Refactoring authorities and taking parts offline Authors: Nick Mathewson, Andrea Shepard Created: 2015-10-27 Status: Draft 1. Introduction Directory authorities are critical to the Tor network, and represent a DoS target to anybody trying to disable the network. This document describes a strategy for making directory authorities in general less vulnerable to DoS by separating the different parts of their functionality. 2. Design 2.1. The status quo This proposal is about splitting up the roles of directory authorities. But, what are these roles? Currently, directory authorities perform the following functions. Some of these functions require large amounts of bandwidth; I've noted that with a (BW). Some of these functions require a publicly known address; I've marked those with a (PUB). Some of these functions inevitably leak the location from which they are performed. I've marked those with a (LOC). Not everything in this list is something that needs to be done by an authority permanently! This list is, again, just what authorities do now. * Authorities receive uploaded server descriptors and extrainfo descriptors from regular Tor servers and from each other. (BW, PUB?) * Authorities periodically probe the routers they know about in order to determine whether they are running or not. By remembering the past behavior of nodes, they also build a view of each node's fractional uptime and mean time between failures. (LOC, unless we're clever) * Authorities perform the consensus protocol by: * Generating 'vote' documents describing their view of the network, along with a set of microdescriptors for later client use. * Uploading these votes to one another. * Computing a 'consensus' of these votes. * Authorities serve as a location for distributing consensus documents, descriptors, extrainfo documents, and microdescriptors... * To directory mirrors. (BW?, PUB?, LOC?) * To clients that do not yet know a directory mirror. (BW!!, PUB) These functions are tied to directory authorities, but done out-of-process: * Bandwidth measurement (BW) * Sybil detection * 'Guardiness' measurement, possibly. 2.2. Design goals Principally, we attempt to isolate the security-critical, high-resource, and availability-critical pieces of our directory infrastructure from one another. We would like to make the security-critical pieces of our infrastructure easy to relocate, and the communications between them easy to secure. We require that the Tor network remain able to bootstrap itself in the event of catastrophic failure. So, while we can _use_ a running Tor network to communicate, we should not _require_ that a running Tor network exist in order to perform the voting process. 2.3. Division of responsibility We propose dividing directory authority operations into these modules: ---------- ---------- -------------- ---------------- | Upload |======>| Voting |===>| Publishing |===>| Distribution | ---------- ---------- -------------- ---------------- I ^ I ----------- I ====>| Metrics |=== ----------- A number of 'upload' servers are responsible for receiving router descriptors. These are publicly known, and responsible for collecting descriptors. Information from these servers is used by 'metrics' modules (which check Tor servers for reliability and measure their history), and fed into the voting process. The voting process involves only communication (indirectly) from authorities to authorities, to produce a consensus and a set of microdescriptors. When voting is complete, consensuses, descriptors, and microdescriptors must be made available to the rest of the world. This is done by the 'publishing' module. The consensuses, descriptors, and mds are then taken up by the directory caches, and distributed. The rest of this proposal will describe means of communication between these modules. 3. The modules in more detail This section will outline possibilities for communication between the various parts of the system to isolate them. There will be plenty of "may"s and "could"s and "might"s here: these are possibilities, in need of further consideration. 3.1. Sending descriptors to the Upload module We retain the current mechanism: a set of well-known IP addresses with well-known OR keys to which each relay should upload a copy of its descriptors. The worst that a hostile upload server can do is to drop descriptors. (It could also generate large numbers of spurious descriptors in order to increase the load on the metrics system. But an attacker could do that without running an upload server) With respect to dropping, upload servers can use an anytrust model: so long as a single server receives and honestly reports descriptors to the rest of the system, those descriptors will arrive correctly. To avoid DoS attacks, we can require that any relay not previously known to an upload module perform some kind of a proof of work as it first registers itself. (Details TBD) If we're using TLS here, we should also consider a check-then-start TLS design as described in A.1 below. The location of Upload servers can change over time; they can be published in the consensus. (Note also that as an alternative, we could distribute this functionality across the whole network.) 3.2. Transferring descriptors to the metrics server and the voters The simplest option here would be for the authorities and metrics servers to mirror them using Tor. rsync-over-ssh-over-Tor is a possibility, if we don't feel like building more machinery. (We could use hidden services here, but it is probably okay for upload servers and to be known by the the voters and metrics.) A fallback to a non-Tor connection could be done manually, or could require explicit buy-in from the voter/metrics operator. 3.3. Transferring information from metrics server to voters The same approaches as 3.2 should work fine. 3.4. Communication between voters Voters can, we hope, communicate to each other over authenticated hidden services. But we'll need a fallback mechanism here. Another option is to have public ledgers available for voters to talk to anonymously. This is probably a better idea. We could re-use the upload servers for this purpose, perhaps. Giving voters each others' addresses seems like a bad idea. 3.5. Communication from voters to directory nodes We should design a flood-distribution mechanism for microdescriptors, listed descriptors, and consensuses so that authorities can each upload to a few targets anonymously, and have them propagate through the rest of the network. 4. Migration To support old clients and old servers, the current authority IP addresses should remain as Upload and Distribution points. The current authority identity keys keys should remain as the keys for voters. A.1. Check-then-start TLS Current TLS protocols are quite susceptible to denial-of-service attacks, with large asymmetries in resource consumption. (Client sends junk, forcing server to perform private-key operation on junk.) We could hope for a good TLS replacement to someday emerge, or for TLS to improve its properties. But as a replacement, I suggest that we wrap TLS in a preliminary challenge-response protocol to establish that the use is authorized before we allow the TLS handshake to begin. (We shouldn't do this for all the TLS in Tor: only for the cases where we want to restrict the users of a given TLS server.)

2 1

Proposal 256: Key revocation for relays and authorities
by Nick Mathewson 27 Oct '15

27 Oct '15

Filename: 256-key-revocation.txt Title: Key revocation for relays and authorities Authors: Nick Mathewson Created: 27 October 2015 Status: Open 1. Introduction This document examines the different kinds of long-lived public keys in Tor, and discusses a way to revoke each. The kind of keys at issue are: * Authority identity keys * Authority signing keys * OR identity keys (ed25519) * OR signing keys (ed25519) * OR identity keys (RSA) Additionally, we need to make sure that all other key types, if they are compromised, can be replaced or rendered unusable. 2. When to revoke keys Revoking keys should happen when the operator of an authority or relay believes that the key has been compromised, or has a significant risk of having been compromised. In this proposal we deliberately leave this decision up to the authority/relay operators. (If a third party believes that a key has been compromised, they should attempt to get the key-issuing party to revoke their key. If that can't be done, the uncompromised authorities should block the relay or de-list the authority in question.) Our key-generation code (for authorities and relays) should generate preemptive revocation documents at the same time it generates the original keys, so that operators can retain those documents in the event that access to the original keys is lost. The operators should keep these revocation documents private and available enough so that they can issue the revocation if necessary, but nobody else can. Additionally, the key generation code should be able to generate retrospective revocation documents for existing keys and certificates. (This approach can be more useful when a subkey is revoked, but the operator still has ready access to the issuing key.) 3. Authority keys Authority identity keys are the most important keys in Tor. They are kept offline and encrypted. They are used to sign authority signing keys, and for no other purpose. Authority signing keys are kept online. They are authenticated by authority identity keys, and used to sign votes and consensus documents. (For the rest of section 2, all keys mentioned will be authority keys.) 3.1. Revocation certificates for authorities We add the following extensions to authority key certificates (see dir-spec.txt section 3.1), for use in key revocation. "dir-key-revocation-type" SP "master" | "signing" NL Specifies which kind of revocation document this is. If dir-key-revocation is absent, this is not a revocation. [At most once] "dir-key-revocation-notes" SP (any non-NL text) NL An explanation of why the key was revoked. Must be absent unless dir-key-revocation-type is set. [Any number of times] "dir-key-revocation-signing-key-unusable" NL Present if the signing key in this document will not actually be used to sign votes and consensuses. [At most once] "dir-key-revoked-signing-key" SP DIGEST NL Fingerprints of signing keys being explicitly revoked by this certificate. (All keys published before this one are _implicitly_ revoked.) [Any number of times] "dir-key-revocation-published" SP YYYY-MM-DD SP HH:MM:SS NL The actual time when the revocation was generated. (Used since the 'published' field in the certificate will lie; see below.) [at most once.] 3.2. Generating revocations Revocations for signing keys should be generated with: * A 'published' time immediately following the published date on the key that they are revoking. * An 'expires' time at least 48 hours after the expires date on the key that they are revoking, and at least one week in the future. (Note that this ensures as-correct-as-possible behavior for existing Tor clients and servers. For Tor versions before 0.2.6, having a more recent published date than the older key will cause the revoked key certificate to be removed by trusted_dirs_remove_old_certs() if it is published at least 7 days in the past. For Tor versions 0.2.6 or later, the interval is reduced to 2 days.) If generating a signing key revocation ahead of time, the revocation document should include a dummy signing key, to be thrown away immediately after it is generated and used to make the revocation document. The "dir-key-revocation-signing-key-unusable" element should be present. If generating a signing key revocation in response to an event, the revocation document should include the new signing key to be used. The "dir-key-revocation-signing-key-unusable" element must be be absent. All replacement certificates generated for the lifetime of the original revoked certificate should be generated as revocations. Revocations for master keys should be generated with: * A 'published' time immediately following the published date on the most recently generated certificate, if possible. * An 'expires' time equal to 18 Jan 2038. (The next-to-last day encodeable in time_t, to avoid Y2038 problems.) * A dummy signing key, as above. 3.3. Submitting revocations In the event of a key revocation, authority operators should upload the revocation document to every other authority. If there is a replacement signing key, it should be included in the authority's votes (as any new key certificate would be). 3.4. Handling revocations We add these additional rules for caching and storing revocations on Tor servers and clients. * Master key revocations should be stored indefinitely. * If we have a master key revocation, no other certificates for that key should be fetched, stored, or served. * If we have a master key revocation, we should replace any DirAuthority entry for that master key with a 'null' entry -- an authority with no address and no keys, from which nothing can be downloaded and nothing can be trusted, but which still counts against the total number of authorities. * Signing key revocations should be retained until their 'expires' date. * If we have a signing key revocation document, we should not trust any signature generated with any key in an older signing key certificates for the same master key. We should not serve such key certificates. * We should not attempt to fetch any certificate document matching an <identity, signing> pair for which a revocation document exists. We add these additional rule for directory authorities: * When generating or serving a consensus document, an authority should include a dir-source entry based on the most recent revocation cert it has from an authority, unless that authority has a more recent valid key cert. (This will require a new consensus method.) * When generating or serving a consensus document, if no valid signature exists from a given authority, and that authority has a currently valid key revocation document with a signing key in it, it should include a bogus signature purporting to be made with that signing key. (All-zeros is suggested.) (Doing this will make old Tor clients download the revocation certificates.) 4. Router identity key revocations 4.1. RSA identity keys If the RSA key is compromised but the ed25519 identity and signing keys are not, simply disable the router. Key pinning should take care of the rest. (This isn't ideal when key pinning isn't deployed yet, but I'm betting that key pinning comes online before this proposal does.) 4.2. Ed25519 master identity keys (We use the data format from proposal 220, section 2.3 here.) To revoke a master identity key, create a revocation for the master key and upload it to every authority. Authorities should accept these documents as meaning that the signing key should never be allowed to appear on the Tor network. This can be enforced with the key pinning mechanism. 4.3. Ed25519 signing keys (We use the data format from proposal 220, section 2.3 here.) To revoke a signing key, include the revocation for every not-yet-expired signing key in your routerinfo document, as in: "revoked-signing-key" SP Base64-Ed25519-Key NL Note that this doesn't need to be authenticated, since the newer signing key certificate creates a trust path from the master identity key to the the revocation. [Up to 32 times.] Upon receiving these entries, authorities store up to 32 such entries per router per year. (If you have more than 32 keys compromised, give up and take your router down. Start it with a new master key.) When voting, authorities include a "rev" line in the microdescriptor for every revoked-signing-key in the routerinfo: "rev" SP "ed25519" SP Base64-Ed25519-Key NL (This will require a new microdescriptor version.) Upon receiving such a line in the microdescriptor, Tor instances MUST NOT trust any signing key certificate with a matching key.

1 0

Tor browser for other Projects
by salutarydiacritical23＠ruggedinbox.com 27 Oct '15

27 Oct '15

Hello good people of Tor. As you know, your client side applications like Tor browser are unmatched by anything out there. They are the natural choice for other anonymous networks. Freenet is considering ways to interface with Tor browser for better privacy. Disclaimer: I am not an official spokesperson for them. I am testing the waters first before filing tickets on trac. My idea is for Tor browser to include the FoxyProxy for redirecting browser requests to proxies based on URL patterns. Optionally there's color indicators for every proxy so users know what network they are visiting. You can add rules to block LAN accesses to keep users safe from misbehaving JavaScript. Rules can be added for I2P URLs too. You'll need to disable the ads in the original addon but the code is DFSG compliant. Like the transports, your client side applications are a new area for collaboration beyond your project. What do you say?

2 1

Status of remaining SVN repositories
by Jens Kubieziel 27 Oct '15

27 Oct '15

Hi, Tor has a SVN with several repositories in it. The ticket #4929 deals with migrating them to git (<URL:https://trac.torproject.org/projects/tor/ticket/4929>). I made a table within the ticket to track the current status. Most of the repositories are in git right now. However some remain where I don't know what the current status is. This are: - blossom - bsockets - incognito - libevent-urz - topf - projects (it seems sub repos are in git) - website Should the first five repos also be moved to trac or what do we want to do with them? -- Jens Kubieziel http://www.kubieziel.de Eine schwarze Katze auf dem Weg zum Galgen bringt Unglück. Werner Mitsch

2 1

A layered transport
by Da Feng 26 Oct '15

26 Oct '15

Hi: I've discovered that the GFW normally doesn't block https protocols. We can use a https front tier to distribute connections to actual bridges. The front tier encrypts an internal address identifier with its private key (no matching public key or public algorithm) and returns to user the encrypted identifier, part of which also includes the user's chosen password. Then when submitting requests, the user encrypt again with his password the items such as his timestamp, broswer headers. The request line to https server is no different from an ordinary one and include both the user encrypted item and front tier encrypted item. After the connection is established, data is relayed inside https between bridge and user.

4 3

Onion Services and NAT Punching
by Tim Wilson-Brown - teor 26 Oct '15

26 Oct '15

Hi All, Do you know a use case which needs Single Onion Services and NAT punching? We’re wondering if there are mobile or desktop applications / services that would use a single onion service for the performance benefits, but still need NAT punching. (And don’t need the anonymity of a hidden service.) Single Onion Services: * can’t do NAT punching, (they need an ORPort on a publicly accessible IP address), * locations are easier to discover, and * have lower latency. Hidden Services: * can do NAT punching, * locations are hard to discover, and * have higher latency. Are there any use cases that: * need NAT punching, * don’t need service location anonymity, and * would benefit from lower latency? Thanks Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

6 6

txtorcon 0.14.0
by meejah 25 Oct '15

25 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce txtorcon 0.14.0. Changes: * IStreamAttacher handling was missing None and DO_NOT_ATTACH cases if a Deferred was returned. * add .is_built Deferred to txtorcon.Circuit that gets callback()'d when the circuit becomes BUILT * David Stainton ported his "tor:" endpoint parser so now both client and server endpoints are supported. This means **any** Twisted program using endpoints can use Tor as a client. For example, to connect to txtorcon's Web site: ep = clientFromString("tor:timaq4ygg2iegci7.onion:80"). (In the future, I'd like to automatically launch Tor if required, too). * Python3 fixes from Isis Lovecruft (note: needs Twisted 15.4.0+) You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.14.0 https://github.com/meejah/txtorcon/releases/tag/v0.14.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz.asc http://timaq4ygg2iegci7.onion/txtorcon-0.14.0-py2-none-any.whl http://timaq4ygg2iegci7.onion/txtorcon-0.14.0-py2-none-any.whl.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check d44be978dd9521f22333edea49789fe7e19c4bea9a02d63e6ec826d08fb571d1 dist/txtorcon-0.14.0-py2-none-any.whl a2d0fae65da015840bb392ffc4fd63918168edb6b634941f6b8aa843b338edbf dist/txtorcon-0.14.0.tar.gz EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJWB3FqAAoJEMJgKAMSgGmn1fsIAOcqJdIFIO5cIvj7TRv9rxFP aEW/Vb0UGN2/A2skWxajzYJLeZ0geZaOmYGFyscs+fguIzRaGRX4G8+7xRuIzzim GqjPd+my2+h79hDpH/RntwQvNmW9K50UCKOH5TiW5fGnjbO0ZkqoK8ln+aGz7WCC HjRmNTJb7iI/vVs6h66evBHjkgib4lBpZSEnJR6H+c1ZC5hJ0uYt1SFch5IF/UsA QeISGyc2SE5wuwjLuiHDyPoFC/Q5IEhDWABFgs3Z6LB/2yfnUFEjrtEla1Uq454H YJ5mWsgxx/apGDXbACQ3p8N5ISA/WDOWHm2Rg+XgZo758KyMyOQIfSy1RrGBld4= =Wffv -----END PGP SIGNATURE-----

1 1

[PATCH] Document our current guard selection algorithm in path-spec.txt.
by isis 23 Oct '15

23 Oct '15

Hey hey, I've been working on documenting our current guard selection algorithm (#17261), [0] which as most of you already know, has some room for improvement. The patch is in my bug17261 branch. [1] However, it's also attached here for reference and discussion. [0]: https://trac.torproject.org/projects/tor/ticket/17261 [1]: https://gitweb.torproject.org/user/isis/torspec.git/log/?h=bug17261 Best, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?
by Alec Muffett 23 Oct '15

23 Oct '15

info(a)tvdw.eu wrote: > Hi Alec, Hi Tom! I love your proposal, BTW. :-) > Most of what you said sounds right, and I agree that caching needs TTLs (not just here, all caches need to have them, always). Thank you! > However, you mention that one DC going down could cause a bad experience for users. In most HA/DR setups I've seen there should be enough capacity if something fails, is that not the case for you? Can a single data center not serve all Tor traffic? It's not the datacentre which worries me - we already know how to deal with those - it's the failure-based resource contention for the limited introduction-point space that is afforded by a maximum (?) of six descriptors each of which cites 10 introduction points. A cap of 60 IPs is a clear protocol bottleneck which - even with your excellent idea - could break a service deployment. Yes, in the meantime the proper solution is to split the service three ways, or even four, but that's administrative burden which less well-resourced organisations might struggle with. Many (most?) will have a primary site and a single failover site, and it seems perverse that they could bounce just ONE of those sites and automatically lose 50% of their Onion capacity for up to 24 hours UNLESS they also take down the OTHER site for long enough to invalidate the OnionBalance descriptors. Such is not the description of a high-availability (HA) service, and it might put people off. > If that is a problem, I would suggest adding more data centers to the pool. That way if one fails, you don't lose half of the capacity, but a third (if N=3) or even a tenth (if N=10). ...but you lose it for 1..24 hours, even if you simply reboot the Tor daemon. > Anyway, such a thing is probably off-topic. To get back to the point about TTLs, I just want to note that retrying failed nodes until all fail is scary: I find that worrying, also. I'm not sure what I think about it yet, though. > what will happen if all ten nodes get a 'rolling restart' throughout the day? Wouldn't you eventually end up with all the traffic on a single node, as it's the only one that hadn't been restarted yet? Precisely. > As far as I can see the only thing that can avoid holes like that is a TTL, either hard coded to something like an hour, or just specified in the descriptor. Then, if you do a rolling restart, make sure you don't do it all within one TTL length, but at least two or three depending on capacity. Concur. desnacked(a)riseup.net wrote: > Please see rend_client_get_random_intro_impl(). Clients will pick a random intro point from the descriptor which seems to be the proper behavior here. That looks great! > I can see how a TTL might be useful in high availability scenarios like the one you described. However, it does seem like something with potential security implications (like, set TTL to 1 second for all your descriptors, and now you have your clients keep on making directory circuits to fetch your descs). Okay, so, how about: IDEA: if ANY descriptor introduction point connection fails AND the descriptor's ttl has been exceeded THEN refetch the descriptor before trying again? It strikes me (though I may be wrong?) that the degenerate case for this would be someone with an onion killing their IP in order to force the user to refetch a descriptor - which is what I think would happen anyway? At very least this proposal would add a work factor. > For this reason I'd be interested to see this specified in a formal Tor proposal (or even as a patch to prop224). It shouldn't be too big! :) I would hesitate to add it to Prop 224 which strikes me as rather large and distant. I'd love to see this by Christmas :-P teor2345(a)gmail.com wrote: > Do we connect to introduction points in the order they are listed in the descriptor? If so, that's not ideal, there are surely benefits to a random choice (such as load balancing). Apparently not (re: George) :-) > That said, we believe that rendezvous points are the bottleneck in the rendezvous protocol, not introduction points. Currently, and in most current deployments, yes. > However, if you were to use proposal #255 to split the introduction and rendezvous to separate tor instances, you would then be limited to: > - 6*10*N tor introduction points, where there are 6 HSDirs, each receiving 10 different introduction points from different tor instances, and N failover instances of this infrastructure competing to post descriptors. (Where N = 1, 2, 3.) > - a virtually unlimited number of tor servers doing the rendezvous and exchanging data (say 1 server per M clients, where M is perhaps 100 or so, but ideally dynamically determined based on load/response time). > In this scenario, you could potentially overload the introduction points. Exactly my concern, especially when combined with overlong lifetimes of mostly-zombie descriptors. - alec

3 4