Changes between Initial Version and Version 1 of Ticket #2490, comment 7
- Timestamp:
- 2016-09-13T20:15:00Z (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #2490, comment 7
initial v1 25 25 26 26 And at runtime (`tahoe start` / `Client.__init__`), if the `onion.*` keys are present, we do the following: 27 * assert that `control.port`/`launch`/`tor.executable` explicitly point to a Tor, and forbid the use of default search-for-tor behavior 27 28 * use the `control.port`/etc keys to tell txtorcon how we want to access Tor 28 29 * read the private key material from the named file … … 36 37 We have `tahoe.cfg` record the private key as a filename, rather than putting the (moderately-sized RSA) key bytes inline inside the config file. We're trying to stick to a policy of not adding new secrets to `tahoe.cfg`. 37 38 39 We forbid search-for-Tor in the onion case because we're going to be revealing the onion private key to whichever Tor we use, and I don't want to enable a different user (on the same box) from being able to camp out on 9150 and steal these keys. For the use-Tor-for-outbound case, this isn't as big a deal, because 1: Foolscap provides the crypto and authentication, and 2: such an attacker already knows your IP address. An attacker who camps out on 9150 early enough to catch your `tahoe create-node` interaction will be the one to provide you with the onion key in the first place. So I think the only threat is when you spoke with a real Tor at create-node time, but are talking to a spoofed Tor at start-node time, which is why I'm thinking that it's sufficient to just record *how* we contacted Tor the first time and do the same thing the second time. 40 38 41 TODO: currently tahoe.cfg must either have both `tub.location` and `tub.port`, or neither, so the `tub.port = disabled` above won't work. We need to decide on a fix for that.
