wiki:org/meetings/2015WinterDevMeeting/Notes/SecureServerRouting

We've been chatting about two possible plans to add nifty torification options to the Let's Encrypt agent. In these plans, the many servers who will be getting certs provisioned by Let's Encrypt could be given an easy option to also activate a secure routing path for Tor clients, if they wish to. Because the Let's Encrypt agent runs on web/mail/other servers, and can add metadata to or via somewhat trustworthy certs, it's in a great position to do this well.

This can be thought of as Exit Enclaves Version 2, with better security and a large-scale deployment plan.

Plan A: Revive something like .exit

Overview

  • each server runs its own Tor relay.
  • the relay allows exiting to localhost:443 or whatever other server port is applicable
  • the relay presents a Let's Encrypt certificate indicating that as the domain owner, they want all traffic exiting the Tor network to their domain to be routed through their relay
  • these are stored in the relay's microdescriptors
  • verification of the certificate and request can occur in the client, or in the Directory Authorities, or both
  • if the site takes down its relay, the Let's Encrypt agent should also request a new cert or otherwise revoke the routing request? Or maybe this isn't required, since the microdescriptor will no longer list this New E

Engineering Work

  • Add the certs and validators to the bridge descriptor and microdescriptor infrastructure
  • In order to scale, implement a way to find and route to these .exits even if they are relatively slow and have overflowed from the Consensus

Advantages, Problems

Pro

  • They dramatically increase Tor network capacity by both adding new middle relays and offloading exit traffic (it's realistic to think that FB/Google/etc may run these)
  • They are more resistant to E2E traffic analysis because there is real Tor cover traffic

Con

  • The scalability challenge is tricky

Plan B: .onion

  • each server runs a Tor client
  • it publishes a non-hidden (1-hop to rendezvous) .onion service
  • availability of the service is anounced through the Let's Encrypt cert or some other channel
  • HTTPS Everywhere or some other TBB component keeps a list of these announced .onion routing options, and upgrades sites to them in the background
  • if the .onion is down, that client code will somehow have to decide whether to allow a downgrade to regular TLS or not (probably the downgrade is okay by default, as long as we didn't make too many promises in the UI)

Engineering Work

  • Implement 1-hop .onion services
  • Add a rewrite-to-.onion comonent to TBB or HTTPS Everywhere
  • Maintain, distribute, and (ugh) update the list of domains that need these rewrites

Advantages, Problems

Pro

  • Fewer changes to the Tor network layer itself
  • Scaling is simpler
  • Generates more high-quality .onion traffic

Con

  • Hidden service introduction will add significant latency, which may discourage folks from running these

Plan C

Suggested by Mike...

  • take the routing properties from Plan A (clients are relays)
  • borrow a portion of the anouncement mechanism from hidden services: namely, announce and provide proof of the certification of Secure Server Routings via the DHT.

Engineering Work

  • Repurpose DHT storage for .exit lookups

Advantages, Problems

Pro

  • Obtains the resistance to traffic analysis of plan A
  • Obtains most of latency advantage of Plan A (except the DHT lookup)
  • Obtains similar scalability properties to Plan B

Con

  • Auditing of which X509 certs request SecureServerRouting becomes a completely out-of-band problem, since it is no longer included in either the consensus or matched to a database in the TBB source.
Last modified 3 years ago Last modified on Mar 12, 2015, 3:08:54 AM