commit db3e2355c4592471126916729a3c99e99fb63a84 Author: Pili Guerra pili@piliguerra.com Date: Mon Mar 8 13:18:24 2021 +0100
Add Onion Balance v3 enhancements project to list of GSoC projects --- content/gsoc/onion-balance-v3/contents.lr | 57 +++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+)
diff --git a/content/gsoc/onion-balance-v3/contents.lr b/content/gsoc/onion-balance-v3/contents.lr new file mode 100644 index 0000000..53cb558 --- /dev/null +++ b/content/gsoc/onion-balance-v3/contents.lr @@ -0,0 +1,57 @@ +_model: project +--- +_template: layout.html +--- +html: two-columns-page.html +--- +active: True +--- +section: GSoC +--- +section_id: gsoc +--- +color: primary +--- +key: 3 +--- +languages: +Python +--- +mentors: +asn +--- +difficulty: medium +--- +title: Onion Balance V3 Enhancements +--- +subtitle: + +OnionBalance allows Tor onion service requests to be distributed across multiple backend Tor instances. OnionBalance provides load-balancing while also making onion services more resilient and reliable by eliminating single points-of-failure. +--- +body: + +# Problem + +Onion services have been around for a while. During the past few years, they have been deployed by many serious websites like major media organizations (like the Washington Post), search engines (such as DuckDuckGo) and critical Internet infrastructure (e.g. PGP keyservers). This has been a great opportunity for us, the onion balance development team, since our code has been hardened and tested by the sheer volume of clients that use it every day. + +Onionbalance is one of the standard ways onion service administrators can load balance onion services, but it didn't work for v3 onions. Until [recently](https://blog.torproject.org/cooking-onions-reclaiming-onionbalance) when we released a new version of Onionbalance that supports v3 onion services. + +# Proposal + +We would like someone to help us implement some of the currently [open feature requests](https://github.com/asn-d6/onionbalance/labels/patches-welcome). + +In particular, we would like to implement some or all of the following features: + +- Support for v3 ["distinct descriptor" mode](https://onionbalance-v3.readthedocs.io/en/latest/v2/design.html#choice-of-in...). +This mode allows Onionbalance v2 to load-balance more than 10 backend instances, whereas currently Onionbalance v3 has a limit of 8 backend instances. In theory, Onionbalance could load-balance hundreds of backend instances by publishing descriptors at small time intervals that contain introduction points from a different subset of those instances each time. +- Minimize the differences between both v3 and other descriptors. +Currently Onionbalance v3 descriptors can look different from other descriptors, which makes it possible for clients and HSDirs to learn that a service is using Onionbalance. This can be an issue for more [advanced onion service threat models](https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md#ho...). +- Enable client authorization on the frontend service. +This may be needed in specialized use cases. Adding this feature would first require implementing client authorization support to Stem v3 descriptors and then using that feature in Onionbalance. +- Allow the ability to transfer your existing v3 onion service to Onionbalance. + + +# Resources + +- [OnionBalance v3 repo on github](https://github.com/asn-d6/onionbalance) +- [OnionBalance Documentation](https://onionbalance-v3.readthedocs.io/en/latest/v3/tutorial-v3.html#tutoria...) \ No newline at end of file