Commit d079557e authored by Burnleydev's avatar Burnleydev
Browse files

Add Onion service v3 support for arti notes

parent bfa22950
# 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.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment