Tor Hackweek Project: Onion service v3 support for arti¶
Summary: arti currently does not do v3 onion services. Let's do some solid work towards making that possible.
Skills: Tor protocol, Onion services protocol, Rust, arti
Team¶
- ASN (UTC-3)
Breakdown and suggested hacking order¶
- tor-llcrypto crate: identify low-level operations needed for v3 onion services. (key blinding)
- tor-cell crate: suppport new relay message types. They should get their own module under relaycell::msg. We should have encode, decode, fuzz, and test vector support for them.
- Should we look for ways to make the cell parsing and encoding more generic so that other extensions can define their own cells? I think that would be a good ide eventually, but probably not for now.
- tor-netdoc crate: support v3 service descriptors. This should include outer and inner forms. [asn first target]
- tor-netdir crate: we need support for the hash index ring.
- tor-circmgr crate: **
- need support for building a circuit with a given exit
- need support for saying "nobody else can use this circuit!"
- need support for saying "this circuit is a valid open connection to (x.onion)", and for saying "i am building a connection to (x.onion), please wait.
- tor-dirmgr crate:
- Support for parallel v3 onion descriptor lookup. This involves adding a new ClientRequest type, and probably refactoring the ClientRequest trait so it can handle the things that make onion descriptor lookup different.
- tor-proto crate: we need support for taking a circuit and then doing an arbitrary send-this-cell-then-wait-for-that-cell handshake. **
- tor-proto crate: need support for extending a circuit with an end-to-end encryption hop, as used with onion services. **
- tor-proto crate: possibly, move some or all of crypto module into a different crate? Some might belong in tor-llcryppto, but not all.
- new tor-hsclient crate: given a cirmgr, a dirmgr, and an onion service name, it should be able to it get or construct a completed rendezvous circuit to that onion service. Its interface can be similar to circmgr. Use APIs in tor-retry for anything we want to attempt more than once.
- This is probably where any descriptor cache should live.
- tor-client crate: When told to connect to an onion address, get the circuit from tor-hsclient.
Design notes¶
- Don't do anything with v2 onions at all.
- Client-side support for onion services should be under an hs-client feature; server-side support should be under an hs-server feature. Common code should be under an "hs" feature and enabled by either.
- New functionality in tor-proto should probably NOT be hs-specific. That is, most of the hs-specific protocol handling stuff should be done in a different crate.
- Parsing shouldn't do crypto: decryption and signature-checking should happen in a post-parsing step.
- This means that for many message types, the parse operation will just put the body in a buffer, and the real parsing will happen after the decryption
- Use different types to prevent confusion here: See current use of the SelfSigned triat in tor-netdir to ensure that signatures are explicitly checked or explicitly ignored.