Confusion & Diffusion

The Token Zoo is now open!

2021-05-17T00:00:00+00:00

We recently launched the Token Zoo!

The Token Zoo is a knowledge base of various published (and unpublished) anonymous credential schemes and their properties. It might prove useful to you, if - like me - you’ve spent months going through the vast anonymous credential literature and you feel like you need some hand holding!

How to stop the onion denial (of service)

2020-08-18T00:00:00+00:00

[Post originally appeared on the Tor blog]

As you might have heard, some onion services have been experiencing issues with denial-of-service (DoS) attacks over the past few years.

The attacks exploit the inherent asymmetric nature of the onion service rendezvous protocol, and that makes it a hard problem to defend against. During the rendezvous protocol, an evil client can send a small message to the service while the service has to do lots of expensive work to react to it. This asymmetry opens the protocol to DoS attacks, and the anonymous nature of our network makes it extremely challenging to filter the good clients from the bad.

For the past two years, we’ve been providing more scaling options to onion service operators, supporting more agile circuit management and protecting the network and the service host from CPU exhaustion. While these don’t fix the root problem, they provide a framework to onion service operators to build their own DoS detection and handling infrastructure.

Even though the toolbox of available defenses for onion service operators has grown, the threat of DoS attacks still looms large. And while there is still a bunch of smaller-scale improvements that could be done, we believe that this is not the kind of problem that a parameter tweak or small code change will make it disappear. The inherent nature of the problem makes us believe that we need to make fundamental changes to address it.

In this post, we would like to present you with two options that we believe can provide a long-term defense to the problem while maintaining the usability and security of onion services.

The intuition to keep in mind when considering these designs is that we need to be able to offer different notions of fairness. In today’s onion services, each connection request is indistinguishable from all the other requests (it’s an anonymity system after all), so the only available fairness strategy is to treat each request equally – which means that somebody who makes more requests will inherently get more attention. The alternatives we describe here use two principles to change the balance: (1) the client should have the option to include some new information in its request, which the onion service can use to more intelligently prioritize which requests it answers; and (2) rather than a static requirement in place at all times, we should let onion services scale the defenses based on current load, with the default being to answer everything.

Defenses based on anonymous tokens

Anonymous tokens are hot lately, and they fit Tor like a glove. You can think of anonymous tokens as tickets, or passes that are rewarded to good clients. In this particular context, we could use anonymous tokens as a way to prioritize good clients over malicious clients when a denial of service attack is happening.

A major question here is how good clients can acquire such tokens. Typically, token distribution happens using a scarce resource that a DoS attacker does not have ample: CAPTCHAs, money, phone numbers, IP addresses, goodwill. Of course, the anonymous nature of our network limits our options here. Also, in the context of the DoS problem, it’s not a huge deal if an evil client acquires some tokens, but it’s important that they are not able to acquire enough tokens to sustain a DoS attack.

One reasonable approach for bootstrapping a token system is to setup a CAPTCHA server (perhaps using hCaptcha) that rewards users with blinded tokens. Alternatively, the onion service itself can reward trusted users with tokens that can later be used to regain access. We can also give users tokens with every donation to the Tor Project. There are many different types of tokens we can use and different user workflows that we can support. We have lots of ideas on how these tokens can interact with each other, what additional benefits they can provide, and how the “wallets” could look (including Tor Browser integration).

An additional benefit of a token-based approach is that it opens up a great variety of use cases for Tor in the future. For example, in the future tokens could be used to restrict malicious usage of Tor exit nodes by spam and automated tools hence reducing exit node censorship by centralized services. Tokens can also be used to register human-memorable names for onion services. They can also be used to acquire private bridges and exit nodes for additional security. Lots of details need to be ironed out, but anonymous tokens seem like a great fit for our future work.

In terms of cryptography, anonymous tokens at their basic form are a type of anonymous credential and use similar technology and UX to PrivacyPass. However, we can’t use PrivacyPass as is, because we want to be able to have one party issue tokens while another party verifies them – a functionality not currently supported by PrivacyPass. For example, we want to be able to setup a token issuing server on some separate or independent website, and still have onion services (or their introduction points) be able to verify the tokens issued by that server.

Of course, when most tech people hear the word “token” in 2020, their mind directly skips to blockchains. While we are definitely monitoring the blockchain space with great interest, we are also cautious about picking a blockchain solution. In particular, given the private nature of Tor, it’s hard finding a blockchain that satisfies our privacy requirements and still provides us with the flexiblity required to achieve all our future goals. We remain hopeful.

Defenses based on Proof-of-Work

Another approach to solving the DoS problem is using a Proof-Of-Work system to reduce the computational asymmetry gap between the service and the attacker.

In particular, onion services can ask the client to solve a Proof-of-Work puzzle before allowing entry. With the right Proof-of-Work algorithm and puzzle difficulty, this can make it impossible for an attacker to overwhelm the service, while still making it reachable by normal clients with only a small delay. Similar designs have also been proposed for TLS.

We have already started writing a proposal for this system (with the great help of friends and volunteers) and we are reasonably confident that existing proof-of-work algorithms can fit our use case while providing the right level of protection. Given the complexity of the system there is still work to be done on the parameter tuning as well as on tuning the Tor introduction scheduler, but initial analysis seems very fruitful.

The great benefit of this approach is that the proposed PoW system is dynamic and automatically adapts its difficulty based on the volume of malicious activity that is hitting the service. Hence, when there is a big attack wave the difficulty increases, but it also scales down automatically when the wave has passed. Furthermore, if we pick a proof-of-work system where doing more work creates a better proof, motivated clients can “bid” for attention by spending time to create an extra-good proof, which would let the onion service prioritize it over the other requests. This approach turns the asymmetry to our advantage: good clients make a small number of connections and they need a way to stand out amid an attacker pretending to be many clients.

Conclusion

We believe that the above two schemes provide a concrete framework that will strengthen the resilience of onion services in a fundamental way.

Both proposals can be applied together and they are complementary to each other. It’s worth pointing out that both proposals are technically and cryptographically heavy and have their own drawbacks and limitations. Nobody wants a Tor network full of CAPTCHAs or mobile-prohibiting PoW puzzles. Parameter tuning and careful design is vital here. After all, DoS-resilience is a game of economics: the goal is not to be perfect; the goal is to raise the bar enough so that the attacker’s financial cost of maintaining an attack is higher than the gain. Or said another way, the steady-state we want to reach is that you typically don’t need to present a captcha or token to visit an onion service, and the reason is that nobody is attacking them because the attacks don’t work.

We hope that our post inspired you to think about our ideas and come up with your own attacks and improvements. This is not a problem we can solve over a day, and we appreciate all the research and help we can get. Please get in touch!

Cooking With Onions: Reclaiming the Onionbalance

2020-03-17T00:00:00+00:00

[Post originally appeared on the Tor blog]

Welcome to another issue of Cooking with Onions!

Onionbalance is one of the standard ways onion service administrators can load balance onion services, but it didn’t work for v3 onions. Until now. We just released a new version of Onionbalance that supports v3 onion services.

The core functionality remains the same: Onionbalance allows onion service operators to achieve the property of high availability by allowing multiple machines to handle requests for an onion service.

If you are already familiar with configuring Tor onion services, setting up Onionbalance is simple. Check the precise setup instructions on our documentation page.

What took you so long?

We deployed next generation v3 onions two years ago, but we just added v3 support for Onionbalance. This took a while…

Introducing v3 functionality to Onionbalance wasn’t easy. The v3 protocol is more secure and robust than v2, but those benefits come with a more complicated protocol. That made Onionbalance integration harder.

To implement v3 support for Onionbalance, we had to jump through various hoops, and in some cases, we had to take the more complicated scenic route.

In particular, some of the advanced v3 crypto was not allowing us to pull the classic Onionbalance trick of making a user think they are going to the frontend service but in reality visiting a backend service. To work around this, we were forced to make the OnionBalance setup procedure a bit more complicated: operators now need to explicitly configure their backend services to act as Onionbalance instances via the torrc.

Finally, as part of our work on Onionbalance v3, we also had to implement v3 descriptor support for Stem, a Python controller library for Tor.

What’s next?

We’re still missing Onionbalance packages for Debian and pip. We want to conduct more tests before replacing the existing packages with the new Onionbalance, so we expect these to be ready in April. The current version of Onionbalance is 0.1.9, and our plan is to create the packages when 0.2.0 is released.

Additionally, these features are still to come:

Support for v3 “distinct descriptor” mode. 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.
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.

Right now, any sort of testing and feedback would be really helpful for us. Also, if you are in the mood for coding or fixing bugs, it would be great if you could provide patches for any of the above missing features or any other feature you might need: We also have a GitHub mirror for people who feel more comfortable there.

We hope this new flavor gives the transition to v3 onion services a boost. And now that Onionbalance is back in active development, maybe you’ll join us in kitchen and write some code?

Until next time! :)

Announcing the Vanguards Add-On for Onion Services

2018-07-20T00:00:00+00:00

[Post originally appeared on the Tor blog]

An Intro to Onion Service Security

Earlier this year, the Tor Project released its first stable Tor and Tor Browser releases with the new v3 onion service protocol. The protocol features many improvements, including longer and more secure onion addresses, service enumeration resistance, improved authentication, and upgraded cryptography.

However, while this new protocol closes off some attacks (particularly enumeration and related targeted DoS attacks), it does not solve any attacks that could lead to service deanonymization.

We believe that the most serious threat that v3 onion services currently face is guard discovery. A guard discovery attack enables an adversary to determine the guard node(s) that are in use by a Tor client and/or Tor onion service. Once the guard node is known, traffic analysis attacks that can deanonymize an onion service (or onion service user) become easier.

The most basic form of this attack is to make many connections to a Tor onion service, in order to force it to create circuits until one of the adversary’s nodes is chosen for the middle hop next to the guard. That is possible because middle hops for rendezvous circuits are picked from the set of all relays:

A traffic analysis side channel can be used to confirm that the malicious node is in fact part of the rendezvous circuit, leading to the discovery of that onion service’s guard node. From that point, the guard node can be compromised, coerced, or surveilled to determine the actual IP address of the onion service or client.

The Vanguards Control Port Add-On

Fixing the guard discovery problem in Tor itself is an immense project – primarily because it involves many trade-offs between performance and scalability versus path security, which makes it very hard to pick good defaults for every onion service.

Because of this, we have created an add-on that can be used in conjunction with a Tor onion service server or a Tor client that accesses Tor onion services.

The add-on uses our Control Port Protocol and the corresponding Stem Library to defend against these attacks. The hope is that it will we will be able to study the performance and functionality of this feature and gather feedback before we deploy these changes in Tor for all onion services and clients.

Vanguards, Bandguards, and a Rendguard, oh my!

Our add-on has three components:

Vanguards

The core functionality is provided by the Vanguards component which implements the Mesh Vanguards (Proposal 292). This ensures that all onion service circuits are restricted to a set of second and third layer guards, which have randomized rotation times as defined in that proposal. Basically, now all the hops of onion service circuits are pinned to specific nodes instead of sampling random ones from the whole network every time.

This change to fixed nodes for the second and third layer guards is designed to force the adversary to have to run many more nodes, and to execute both an active sybil attack, as well as a node compromise attack. In particular, the addition of second layer guard nodes means that the adversary goes from being able to discover your guard in minutes by running just one middle node, to requiring them to sustain the attack for weeks or even months, even if they run 5% of the network.

The analysis behind our choice for the number of guards at each layer, and for rotation duration parameters is available on GitHub. Here is how our current vanguard 2-3-8 topology looks like:

Furthermore, to better protect the identity of these new pinned guard nodes the circuit lengths have been altered for rendezous point circuits, hidden service directory circuits, and introduction point circuits. You can see them here (where L1 is the first layer guard, L2 is second layer guard, L3 is third layer guard, M is random middle):

Bandguards

Additionally, the Bandguards component of the add-on also checks for evidence of bandwidth side channel attacks, which may be used by the adversary to aid/amplify traffic analysis attacks.

When these attacks are detected, the circuit is (optionally) closed.

Note that the Bandguards component also closes any circuit older than 24 hours (the circ_max_age_hours setting), and has an option (off-by-default) to close circuits that transmit more than a certain number of megabytes (the circ_max_megabytes option).

If your service requires large file uploads, or very long-lived circuits, set these options to 0 in your vanguards.conf.

Rendguards

Finally, the Rendguards component of the add-on performs analysis on the prevalence of rendezvous points on the onion service side. The rendezvous point is chosen by the client when it connects to an onion service, and some attacks rely on the use of a malicious rendezvous point to aid in traffic analysis.

This component tracks the frequency of rendezvous point use, and when it finds overuse, it optionally closes circuits from that rendezvous point and emits a log message.

Each of these components is configurable. Please see the README for more information.

Requirements, Installation, Usage, and Caveats

The Vanguards add-on is primarily for high-risk onion service operators at this point. In order for the Bandguards side channel detection features to be enabled, Tor 0.3.4.4 or above is required, but the script will run with Tor 0.3.3.x+. Earlier Tors do not have sufficient Control Port support for the script, however.

Additionally, while they have been thoroughly tested by us, the parameters for the various detection mechanisms of the Bandguards and Rendgaurd components are still experimental and may need fine tuning for your service or scenario, especially if it differs from our testing environment.

If you notice log messages or alarms from these components, it does not necessarily mean that you are under attack. If you can, please report frequent log messages to the GitHub issue tracker.

Thank you and let us know if you have any questions or concerns! :)

The Wilmington Watch: A Tor Network Team Hackfest

2017-07-05T00:00:00+00:00

[Post originally appeared on the Tor blog]

The Tor network team is a small team responsible for developing the core Tor daemon. We’re located around the globe, so we periodically meet in person for team hackfests to keep our team fresh and up to date with all things Tor, and to fast-track features and improvements. Previously, we’ve met for hackfests in Arlington and Montreal, and for our latest meeting, we met in Wilmington, Delaware, a town revered for its yearly Italian Festival.

To better understand the geographical setting of this meeting, go to Trenton, New Jersey, USA, hop into a Delaware river riverboat, then follow the flow south; after about 60 miles you will eventually see a town named Wilmington on your right. This small town hosted us for a few days while we worked on making Tor stronger and safer.

What went down

We worked intensely for several days and nights, researching, planning, and cooking meals for each other. Here is a small fraction of the topics we worked on:

We schemed on about the Tor modularization project which aims to clean up and organize our codebase into nice and tidy abstract modules. Cleaning and modularizing our code not only reduces technical debt, but also allows us to eventually rewrite those submodules into higher-level languages such as Rust, D or APL.

That last part is not science-fiction; as of a month ago, Tor’s build system is capable of building and linking code modules written in Rust. We are now actively working on implementing the protover subsystem into Rust as our first prototype module.
As part of the security discussion, we talked about the new padding defenses that were recently added to Tor and provide cover to Tor circuits against traffic analysis. We made plans for future padding techniques and defenses.
We also briefed up the whole team on how our new entry guard picking algorithm works to enhance the security of Tor clients and protects them against local network attacks. We planned various defenses against hidden service guard discovery attacks, as well as alternative onion routing path algorithms. Our next step for improving guard security is to simulate alternative path construction algorithms and evaluate their performance and security guarantees.
We discussed KIST, an alternative network scheduler and congestion management logic for Tor which offers improved circuit performance and cleaner network tubes. KIST is currently under active development, so we roadmapped and planned for how to get it included upstream.
We talked about our code testing techniques and how to improve them. We discussed the necessity of regression tests, the need to improve our integration tests, and also the future of our fuzzing framework. (Feel free to get in touch if you want to help improve our tests!)
We all shared our experiences and thoughts on our beloved tool for ticket tracking and project management: Trac. We discussed ways we could improve our Trac workflows and also alternative tools we could potentially try (e.g. Gitlab). Transitioning to another tool is not so easy, though; since our Trac instance contains 10+ years of Tor history, we need to make sure we don’t lose any information.

We stayed for about 5 days in town doing all these things and more. Then on a Friday afternoon as the Wilmington Italian Festival was setting up for yet another day, we jumped on trains, planes, and buses and moved on to other places and stories. Life goes on, and the same goes for Tor development.

We’re committed to being open and transparent about our work, and we hope you enjoyed this post. Keep on hacking.

Cooking With Onions: Names for your onions

2017-04-30T00:00:00+00:00

[Post originally appeared on the Tor blog]

Hello again, this blog post is the second issue of the Cooking with Onions series which aims to highlight interesting aspects of the onion space. Check-out our first issue as well!

Onion addresses are weird…

This post is about onion addresses being weird and the approaches that can be taken to improve onion service usability. In particular, if you’ve cruised around the onionspace, you must have noticed that onion services typically have random-looking addresses that look like these:

3g2upl4pq6kufc4m.onion
33y6fjyhs3phzfjj.onion
propub3r6espa33w.onion

So for example, if you wanted to visit the Tor website onion service, you would have to use the address http://expyuzz4wqqyqhjn.onion/ instead of the usual https://www.torproject.org. To better understand why onion addresses are so strange, it helps to remember that onion services don’t use the insecure Domain Name System (DNS), which means there is no organization like ICANN to oversee a single root registry of onion addresses or to handle ownership dispute resolution of onion addresses. Instead, onion services get strong authentication from using self-authenticating addresses: the address itself is a cryptographic proof of the identity of the onion service. When a client visits an onion service, Tor verifies its identity by using the address as ground truth. In other words, onion services have such absurd names because of all the cryptography that’s used to protect them. Cryptographic material are basically huge numbers that look meaningless to most humans, and that’s the reason onion addresses tend to look random as well. To motivate this subject further, Tor developers have medium-term future plans for upgrading the cryptography of onion services, which has the side-effect of increasing onion address length to 54 characters! This means that in the future onion addresses will look like this:

llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymlead.onion
lfels7g3rbceenuuqmpsz45z3lswakqf56n5i3bvqhc22d5rrszzwd.onion
odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion

Remembering onions

Over the years the Tor community has come up with various ways of handling these large and non-human-memorable onion addresses. Some people memorize them entirely or scribe them into secret notebooks, others use tattoos, third-party centralized directories or just google them everytime. We’ve heard of people using decks of cards to remember their favorite onion sites, and others who memorize them using the position of stars and the moon. We believe that the UX problem of onion addresses is not actually solved with the above ad-hoc solutions and remains a critical usability barrier that prevents onion services from being used by a wider audience. The onion world never had a system like DNS. Even though we are well aware that DNS is far from the perfect solution, it’s clear that human memorable domain names play a fundamental role in the user experience of the Internet. In this blog post we present you a few techniques that we have devised to improve the usability of onion addresses. All of these ideas are experimental and come with various fun open questions, so we are still in exploration mode. We appreciate any help in prototyping, analyzing and finding flaws in these ideas.

Idea 1) A modular name system API for Tor onion services

During the past years, many research groups have experimented and designed various secure name systems (e.g. GNS, Namecoin, Blockstack). Each of these systems has its own strengths and weaknesses, as well as different user models and total user experience. We are not sure which one works best for the onion space, so ideally we’d like to try them all and let the community and the sands of time decide for us. We believe that by integrating these experimental systems into Tor, we can greatly strengthen and improve the whole scientific field by exposing name systems to the real world and an active and demanding userbase. For this reason and based on our experience with modular anti-censorship techniques, we designed a generic & modular scheme through which any name system can be integrated to Tor: Proposal 279 defines A Name System API for Tor Onion Services which can be used to integrate any complex name system (e.g. Namecoin) or even simple silly naming schemes (e.g. a local /etc/tor-hosts file). Here is a graphical depiction of the Name System API with a Namecoin module enabled and resolving the domain sailing.tor for a user:

It’s worth pointing out that proposal 279 is in draft status and we still need to incorporate feedback received in the mailing list. Furthermore, people have pointed out simple ways through which we can fast-track and prototype the proposal faster. Help in implementing this proposal is greatly appreciated (find us in IRC!).

Idea 2) Using browser extensions to improve usability

Other approaches for improving the usability of onion addresses use the Tor Browser as a framework: think of browser extensions that map human memorable names to onion addresses. There are many variants here so let’s walk through them:

Idea 2.1) Browser Extension + New pseudo-tld + Local onion registry

A browser extension like HTTPS-everywhere, uses an onion registry to map human-memorable addresses from a new pseudo-tld (e.g. “.tor”) to onion addresses. For example, it maps “watchtower.tor” to “fixurqfuekpsiqaf.onion” and “globaleconomy.tor” to “froqh6bdgoda6yiz.onion”. Such an onion registry could be local (like HTTPS-everywhere) or remote (e.g. a trusted append-only database). Even an extension with a local onion registry would be a very effective improvement to the current situation since it would be pretty usable and its security model is easy to understand: an audited local database seems to work well for HTTPS-everywhere. However, there are social issues here: how would the onion registry be operated and how should name registrations be handled? I can see people fighting for who will get bitcoin.tor first. That said, this idea can be beneficial even with a small onion database (e.g. 50 popular domains). Here is a graphical depiction of a browser extension with a local onion registry resolving the domain sailing.tor for a user:

Idea 2.2) Browser extension + New pseudo-tld + Remote onion registries

A more dynamic alternative here involves multiple trusted remote onion registries that the user can add to their torrc. Imagine a web-of-trust based system where you add your friend’s Alice onion registry and then you can visit facebook using facebook.alice.onion. A similar more decentralized alternative could be a browser addon that uses multiple remote onion registries/notaries to resolve a name, employing a majority or supermajority rule to decide the resolution results. Such a system could involve notary nodes similar to SSL schemes like Convergence.

Idea 2.3) Browser extension redirects existing DNS names

An easier but less effective approach would be for the browser extension to only map DNS domain names to onion names. So for example, it would map “duckduckgo.com” to “3g2upl4pq6kufc4m.onion”. That makes the job of the name registrar easier, but it also heavily restricts users only to services with a registered DNS domain name. Some attempts have already been made in this area but unfortunately they never really took off.

Idea 2.4) Automatic Redirection using HTTP

The Alt-Svc HTTP header defines a way for a website to say “I’m facebook.com but you should talk to me using fbcdn.com.” If we replace that fbcdn.com address with facebookcorewwi.onion - then when you typed in Facebook, the browser would, under the covers, use the .onion address. And this can be done without any browser extension whatsoever. One problem is that the browser has to remember this mapping, and in Tor Browser that mapping could be used to track or correlate you. Preloading the mapping would solve this, but how to preload the mapping probably brings us back into the realm of a browser extension.

Idea 2.5) Smart browser bookmarks for onion addresses

Talking about random addresses, it’s funny how people seem to be pretty happy handling phone numbers (big meaningless random numbers) using a phone book and contacts on their devices. On the same note, an easier but less usable approach would be to enhance Tor Browser with some sort of smart bookmark/petname system which allows users to register custom names for onion sites, and allows them to trust them or share them with friends. Unfortunately, it’ unclear whether the user experience of this feature would make it useful to anyone but power users. Of course it’s important to realize that any approach that relies on a browser extension will only work for the web, and you wouldn’t be able to use it for arbitrary TCP services (e.g. visiting an IRC server)

Idea 3) Embed onion addresses in SSL certificates

So let’s shift back to non-browser approaches! Let’s Encrypt is an innovative project which issues free SSL certificates in an automated fashion. It has greatly improved Internet security since now anyone can freely acquire an SSL certificate for their service and provide link security to their users. Now let’s imagine that Let’s Encrypt embedded onion address information into the certificates it issues, for clients with both a normal service and an onion service. For example, the onion address could be embedded into a custom certificate extension or in the C/ST/L/O fields. Then Tor Browser, when visiting such an SSL-enabled website, would parse and validate the certificate and if an onion address is included, the browser would automagically redirect the user. Take a look at this paper for some more neat ideas on this area.

Idea 4) Embed onion addresses in DNS/DNSSEC records

A similar approach could use the DNS system instead of the SSL CA system. For example, site owners could add their onion address into their TXT or SRV DNS records and Tor could learn to redirect users to the onion address. Of course this approach only applies to operators that can afford a DNS domain. Oh yeah DNS also has zero security…

Conclusion

As you can see there are many approaches that we should explore to improve usability in this area. Each of them comes with its own tradeoffs and applies to different users, so it’s important that we allow users to experiment with various systems and let each community decide which approach works best for them. It’s also worth pointing out that some of these approaches are not that hard to implement technically, but they still require lots of effort and community building to really take off and become effective. Involving and pairing with other friendly Internet privacy organizations is essential to achieve our goals. Furthermore, we should think carefully of unintended usability and security consequences that come with using these systems. For example, people are not used to their browser automagically redirecting them from one domain to another: this can seriously freak people out. It’s also not clear how Tor Browser should handle these special names to avoid SSL certificate verification issues and hostname leaks. One thing is for sure: even though onion services are used daily by thousand of people, the random addresses confuse casual users and prevent the ecosystem from maturing and achieving widespread adoption. We hope that this blog post inspires researchers and developers to toy around with naming systems and take the initiative in building and experimenting with the various approaches. Please join the [tor-dev] mailing list and share your thoughts and projects with us!

And this brings us to the end of this post. Hope you enjoyed this issue of Cooking With Onions! We will be back soon, always with the finest produce and the greatest cooking tips! What would you like us to cook next? _

[Thanks to Philipp Winter and Tom Ritter for the feedback on this blog post, as well as to everyone who has discussed and helped develop these ideas.]

Mission: Montreal! (Building the Next Generation of Onion Services)

2016-05-25T00:00:00+00:00

[Post originally appeared on the Tor blog]

A few weeks ago, a small group of Tor developers got together in Montreal and worked on onion services for a full week. The event was very rewarding and we wrote this blog post to share with you how we spent our week! For the record, it was our second onion service hackfest, following the legendary Arlington Accords of July 2015. Our main goal with this meeting was to accelerate the development of the Next Generation Onion Services project (aka proposal 224). We have been working on this project for the past several months and have made great progress. However, it’s a huge project! Because of its volume and complexity, it has been extremely helpful to meet and work together in the same physical space as we hammer out open issues, review each other’s code, and quickly make development decisions that would take days to coordinate through mailing lists. During the hackfest, we did tons of work. Here is an incomplete list of the things we did:

In our previous hidden service hackfest, we started designing a system for distributed random number generation on the Tor network. A “distributed random number generator” is a system where multiple computers collaborate and generate a single random number in a way that nobody could have predicted in advance (not even themselves). Such a system will be used by next generation onion services to inject unpredictability into the system and enhance their security.

Tor developers finished implementing the protocol several months ago, and since then we’ve been reviewing, auditing, and testing the code.

As far as we know, a distributed random generation system like this has never been deployed before on the Internet. It’s a complex system with multiple protocol phases that involves many computers working together in perfect synergy. To give you an idea of the complexity, here are the hackfest notes of a developer suggesting a design improvement to the system:

Complicated protocols require lots of testing! So far, onion service developers have been testing this system by creating fake small virtual Tor networks on their laptops and doing basic tests to ensure that it works as intended. However, that’s not enough to properly test such an advanced feature. To really test something like this, we need to make a Tor network that works exactly like the real Tor network. It should be a real distributed network over the Internet, and not a virtual thing that lives on a single laptop!

And that’s exactly what we did during the Montreal hackfest! Each Tor developer set up their own Tor node and enabled the “distributed random number generation” feature. We had Tor nodes in countries all around the world, just like the real Tor network, but this was a network just for ourselves! This resulted in a “testing Tor network” with 11 nodes, all performing the random number generation protocol for a whole week.

This allowed us to test scenarios that could make the protocol burp and fail in unpredictable ways. For example, we instructed our testing Tor nodes to abort at crucial protocol moments, and come back in the worst time possible ways, just to stress test the system. We had our nodes run ancient Tor versions, perform random chaotic behaviors, disappear and never come back, etc.

This helped us detect various bugs and edge cases. We also confirmed that our system can survive network failures that can happen on the real Internet. All in all, it was a great educational experience! We plan to keep our testing network live, and potentially recruit more people to join it, to test even more features and edge cases!

For what it’s worth, here is a picture of the two first historic random values that our Tor test network generated. The number “5” means that 5 Tor nodes contributed randomness in generating the final random value:
We also worked to improve the design of next generation onion services in other ways. We improved the clarity of the specification of proposal 224 and fixed inconsistencies and errors in the text (see latest prop224 commits).

We designed various improvements to the onion service descriptor download logic of proposal 224 as well as ways to improve the handling of clients with skewed clocks. We also brainstormed ways we can improve the shared randomness protocol in the future.

We discussed ways to improve the user experience of the 55-character-long onion addresses for next generation onion services (compared to the 16-character-long onion addresses used currently). While no concrete design has been specified yet, we identified the need for a checksum and version field on them. We also discussed modifications to the Tor Browser Bundle that could improve the user experience of long onion addresses.
We don’t plan to throw away the current onion service system just yet! When proposal 224 first gets deployed, the Tor network will be able to handle both types of onion services: the current version and the next generation version.

For this reason, while writing the code for proposal 224, we’ve been facing the choice of whether to refactor a particular piece of code or just rewrite it completely from scratch. The Montreal hackfest allowed us to make quick decisions about these, saving tons of time we would have spent trying to decide over mailing lists and bug trackers.

We also worked on breaking down further the implementation plan for proposal 224. We split each task into smaller subtasks and decided how to approach them. Take a look at our notes.

Be seeing you!

Flute: A simple secure multiparty messaging system

2016-05-02T00:00:00+00:00

[Post originally appeared on the messaging mailing list]

Hello messaging wizards,

I’d like to present you a first version of Flute: a secure multiparty messaging system. It has been a side-project for the past month, and I’m glad to finally push it out to the world :)

You can find the code repository here: https://github.com/asn-d6/flute

The flute protocol

You can find the protocol spec here: https://github.com/asn-d6/flute/blob/master/flute_spec.txt

The primary aim of the flute protocol has been to offer the basic security properties while keeping the protocol easy to understand, analyze and implement. Essentially, everytime I was faced with a design decision I picked the simplest design possible. At its present form, I consider it an educational and experimentation tool for multiparty messaging, but it also has potential to grow into a powerful messaging system.

The current protocol offers end-to-end confidentiality of messages as well as entity authentication. It does not offer security properties like deniability or transcript/room consistency yet.

The flute protocol does not use a (multiparty) key exchange protocol to generate group encryption keys. Instead the flute protocol uses a room captain and a key transport protocol to ship encryption keys to the room participants. For more information, please read the protocol spec.

The flute codebase:

I decided there would not be much benefit in designing yet another multiparty messaging protocol without first building it to see how well it works.

So I implemented a prototype of Flute for use over IRC with Weechat. I used Python and the Weechat python bindings which allowed me to prototype pretty quickly.

The current code is far from user-ready and should not be used for anything sensitive. The weechat UX still sucks, and there are dozens of XXXs sprinkled around the code. However the basic functionality seems to work fine and that’s what’s important at this stage.

Future steps:

I don’t have much spare time these days, so I don’t know how much time I will have for Flute. Now that I managed to publish the first version of the protocol I’m going to take a step back and wait for feedback and suggestions before acting further.

My secret hope is that people will find interest in this project and will submit patches, bug fixes and UX improvements. If you want to help out but you are not sure how, please read TODO.txt or check all those XXXs in the codebase; some are dead simple to solve, some are harder. Also, testing Flute yourself for a few minutes should give you plenty of ideas on things to improve on the UX.

On the protocol side, if you take a minute and understand the flute spec, you will realize that it’s actually a quite simple protocol with great potential for improvements in every step. If you have a flute improvement in mind, I invite you to hack the spec and the code, and actually implement and test the improvement yourself. If you find a great improvement that works, please let me know!

I also hope that more people will help with breaking the protocol, and conducting missing security analysis. For example, please read the “Security discussion” section in the spec and all the XXXs.

Furthermore, the current flute codebase works over IRC powered by weechat and Python. However, I actually don’t think that Python or Weechat or IRC are necessarily the best tools for this sort of protocol. I’m definitely open to alternative implementations, or extending flute to more chat clients and frameworks.

Feel free to use github for any flute patches that I should look at, or use this mailing list thread for any design suggestions you might have. Also, if you are interested in helping, but you are missing required documentation or help to get started, let me know as well.

Testing flute:

If you find this project interesting, please give Flute a try. Read the README file to get started with testing flute.

You can test flute on real IRC networks or just setup your own testing IRC server and test it out offline. I’ve been using hybrid-ircd for local testing which only takes 20 seconds of setup time. You can also create weechat aliases that allow you to join the server, and start flute with just one command.

Finally, if you follow the README instructions you will end up in the #flute_test IRC channel of baconsvin. I have parked a room captain there that will accept any room joins, so feel free to join that flute room for testing.

Acknowledgments

As always, Flute would not be here if it was not for the celo crew: joe, ahf and infinity0.

Have fun playing with Flute and please provide feedback!!!

My MSc thesis on group messaging and group key exchange protocols

2015-06-15T00:00:00+00:00

(Post originally appeared on the [messaging] mailing list)

I just finished my MSc thesis which you can find here.

It all started as an attempt to design a secure messaging protocol, but because of the nature of my degree it became more theoretical and cryptographic so I ended up looking at group key exchange protocols and provable security.

Still, the document contains some information about group messaging and of previous work on this space. However the content is incomplete and a bit outdated; if you are looking for a robust survey on messaging protocols I would suggest the recent paper by Bonneau et al.

We also present a key integrity attack on the group key exchange protocol from the paper “Flexible group key exchange with on-demand computation of subgroup keys”. That’s the paper that the (n+1)sec key exchange protocol is based on, however the (n+1)sec protocol itself is not affected.

Finally, we present a toy new key exchange protocol based on a paper by Bresson et al., slightly modified to make it nicer, and then prove it secure using a sequence-of-games proof. Finally, in Appendix B, there is some research-level simulation source code of the “Deniable Group Key Agreement” by Bohli et al.

It’s worth mentioning that halfway into writing my thesis, I got convinced that key exchanges might not be the best way to do cryptography in the group messaging setting. Discussions with Trevor and Ximin helped me realize that pairwise crypto and some kind of group key (à la sender-keys) might be the way forward since it’s more asynchronous, making it more useful for mobile platforms.

That said, it was a fun thesis to write and I learned lots about provable security. I believe that key exchange security models and proof techniques are still very useful for demonstrating security even on pairwise sender-key type of constructions.

Big thanks to my supervisor Kenny Paterson and to the various friends that talked group messaging with me over the past years!

Some statistics about onions

2015-02-26T00:00:00+00:00

[Post originally appeared on the Tor blog]

Hello,

over the past months we’ve been working on hidden service statistics. Our goal has been to answer the following questions:

“Approximately how many hidden services are there?”
“Approximately how much traffic of the Tor network is going to hidden services?”

We chose the above two questions because even though we want to understand hidden services, we really don’t want to harm the privacy of Tor users. From a privacy perspective, the above two questions are relatively easy questions to answer because we don’t need data from clients or the hidden services themselves; we just need data from hidden service directories and rendezvous points. Furthermore, the measurements reported by each relay cannot be linked back to specific hidden services or their clients. Our first move was to research various ways we could collect these statistics in a privacy-preserving manner. After days of discussions on obfuscating statistics, we began writing a Tor proposal with our design, as well as code that implements the proposal. The code has since been reviewed and merged to Tor! The statistics are currently disabled by default so we asked volunteer relay operators to explicitly turn them on. Currently there are about 70 relays publishing measurements to us every 24 hours:

So as of now we’ve been receiving these measurements for over a month, and we have thought a lot about how to best use the reported measurements to derive interesting results. We finally have some preliminary results we would like to share with you:

How many hidden services are there?

All in all, it seems that every day about 30000 hidden services announce themselves to the hidden service directories. Graphically:

By counting the number of unique hidden service addresses seen by HSDirs, we can get the approximate number of hidden services. Keep in mind that we can only see between 2% and 5% of the total HSDir space, so the extrapolation is, naturally, messy.

How much traffic do hidden services cause?

Our preliminary results show that hidden services cause somewhere between 400 to 600 Mbit of traffic per second, or equivalently about 4.9 terabytes a day. Here is a graph:

We learned this by getting rendezvous points to publish the total number of cells transferred over rendezvous circuits, which allows us to learn the approximate volume of hidden service traffic. Notice that our coverage here is not very good either, with a probability of about 5% that a hidden service circuit will use a relay that reports these statistics as a rendezvous point. A related statistic here is “How much of the Tor network is actually hidden service usage?”. There are two different ways to answer this question, depending on whether we want to understand what clients are doing or what the network is doing. The fraction of hidden-service traffic at Tor clients differs from the fraction at Tor relays because connections to hidden services use 6-hop circuits while connections to the regular Internet use 3-hop circuits. As a result, the fraction of hidden-service traffic entering or leaving Tor is about half of the fraction of hidden-service traffic inside of Tor. Our conclusion is that about 3.4% of client traffic is hidden-service traffic, and 6.1% of traffic seen at a relay is hidden-service traffic.

Conclusion and future work

In this blog post we presented some preliminary results that could be extracted from these new hidden service statistics. We hope that this data can help us better gauge the future development and maturity of the onion space as well as detect potential incidents and bugs on the network. To better present our results and methods, we wrote a short technical report that outlines the exact process we followed. We invite you to read it if you are curious about the methodology or the results. Finally, this project is only a few months old, and there are various plans for the future. For example:

There are more interesting questions that we could examine in this area. For example: “How many people are using hidden services every day?” and “How many times does someone try to visit a hidden service that does not exist anymore?.” Unfortunately, some of these questions are not easy to answer with the current statistics reporting infrastructure, mainly because collecting them in this way could reveal information about specific hidden services but also because the results of the current system contain too much obfuscating data (each reporting relay randomizes its numbers a little bit before publishing them, so we can learn about totals but not about specific events). For this reason, we’ve been analyzing various statistics aggregation protocols that could be used in place of the current system, allowing us to safely collect other kinds of statistics.
We need to incorporate these statistics in our Metrics portal so that they are updated regularly and so that everyone can follow them.
Currently, these hidden service statistics are not collected in relays by default. Unfortunately, that gives us very small coverage of the network, which in turn makes our extrapolations very noisy. The main reason that these statistics are disabled by default is that similar statistics are also disabled (e.g. CellStatistics). Also, this allows us more time to consider privacy consequences. As we analyze more of these statistics and think more about statistics privacy, we should decide whether to turn these statistics on by default. It’s worth repeating that the current results are preliminary and should be digested with a grain of salt. We invite statistically-inclined people to review our code, methods, and results. If you are a researcher interested in digging into the measurements themselves, you can find them in the extra-info descriptors of Tor relays. Over the next months, we will also be thinking more about these problems to figure out proper ways to analyze and safely measure private ecosystems like the onion space.

Till then, take care, and enjoy Tor!