latreel.blogg.se - How to use chutney for private tor network

HOW TO USE CHUTNEY FOR PRIVATE TOR NETWORK UPGRADE
HOW TO USE CHUTNEY FOR PRIVATE TOR NETWORK SOFTWARE

There are actually three different ways to do it. And you can absolutely run your own tor network. There aren't a lot of instructions for actually deploying the Directory Authorities, but what is there is not bad. Then an alternate network could flourish, and relay operators could join multiple networks to support other administrative boundaries. (There's been some thoughts that one might be able to, but it would be an unsupported hack, liable to break.) It would be interesting if the codebase could evolve such that a tor node may belong to more than one network at a time. If I want to change the Directory Authorities that I trust I can technically do so, but I will no longer be able to use the official Tor Network because those few thousand relays 'belong' to it, and one cannot set up a network that includes them. It's worth noting that the Tor Network has some amount of trust agility, but it's not perfect. We should be able to change who we trust at any time - Moxie dubs it Trust Agility.

If tor only allowed you to use the official Tor Network - that would be bad. Certificate Transparency has at least two different implementations for comparison.īut, to be clear - locking a user into a trust decision, even a consensus of mutually distrusting authorities, is still a bad thing. Going even further - there is only one implementation of the DirAuth voting protocol in the tor daemon itself.

HOW TO USE CHUTNEY FOR PRIVATE TOR NETWORK UPGRADE

This is a poor example, because tor relies on OpenSSL and it's not easily swapped out - but the majority of DirAuths had to upgrade when Heartbleed hit.

HOW TO USE CHUTNEY FOR PRIVATE TOR NETWORK SOFTWARE

If one were to take it a step further, one would ensure that no majority of the servers were running the same software stack, to reduce the possbility of a single bug affecting a majority. But seperately managed servers that operate in a majority vote mitigate many concerns. A single trusted server, or set of servers, administered by one organization is at risk to a complete compromise in one fell swoop. Relying on the user to make trust decisions doesn't work out so well. I think the Directory Authority model is pretty elegant. (Think Whisper Systems' RedPhone/TextSecure/Signal.) Relying on a single operator to run a service.

(Think Certificate Authorities, any of whom can cerify any domain on the web.)

Relying on a number of trusted parties who operate independently.

(Think country-code TLDs, or even Verisign operating.

Relying on a single party to sign everything and adjudicate.

Relying on an individual to make trust decisions given a database of data and a little context.

The only thing that comes close, that I can think of, is the Bitcoin blockchain or Ripple's ledgers. This infrastructure design is very interesting. If the majority of authorities vote for something (the inclusion of a relay, marking it as 'Bad', whatever) - it passes the vote. A Directory Authory votes on its view of the network, and collects the votes of the other Directory Authorities. These Directory Authorities are run by members of the Tor Project and by trusted outside individuals/groups, such as and CCC.de. One of the reasons it's interesting is that the network itself operates, at its core, by mutually distrusting Directory Authorities.