💾 Archived View for pulham.info › projects › tor-gateway.gmi captured on 2022-03-01 at 15:02:57. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Libera Tor registration gateway

One of my ongoing, low level tasks is the development of a tor-accessible gateway to register on Libera. Why this is something I'm working on requires a little background.

Tor access to Libera, the story so far

Tor access to freenode - and later Libera - hasn't always been something we've been able to provide. While in the past it was accessible, it became the source of a torrent (pun intended) of abuse. To mitigate this, we now require that tor users have an account registered with us, and connect with SASL - a method that includes identification (logging in) in the early connection process. This allows us to reject users with no account, or tainted accounts, before they can ever use the network.

The problem

We have always enjoyed the openness of IRC, and includes being able to connect anonymously, with no account required. When users connect in this fashion, if they are abusive, we can ban their IP for some time, encouraging reflection, and protecting honest users while they go about their usual business on the network.

As suggested, we do also have accounts. These provide a number of benefits, chiefly being that of a relatively secure, persistent identity that can be trusted. While anyone can use any nick, if I see the same account on several occasions, I can be confident it is actually the same person. Again, channel and network ops can sanction these identities as required.

In both of these models, there is some cost for dishonest users: anonymous users must have a steady stream of untainted IPs if they are to continually reconnect to the network. Accounts require a verification email, which again, must be sent to an untainted email address. These costs are what we use to essentially rate limit or outright deny the network to persistent abusers.

How tor fits in

Now that we see that we cannot rate limit dishonest users by IP if they are using tor, and if we are to impose a cost, it must be through having an account. But this presents two problems:

A tor user must give us an working email address
To register an account with this address, they must connect at least once over the clearnet (as connections are denied from tor until they have such an account)

With this in mind, we need to provide some way to generating accounts that has a non-email cost to attackers, and can be completed over tor.

A solution?

A tor accessible website with a registration form would eliminate the clearnet trip.

To replace the need for an email, we can require that users complete some work that is a reasonable one-off cost for honest users, but does not scale easily and becomes a serious headache for attackers who want accounts in bulk.

The design

A user connects to our tor hidden web service at the same address as the hidden irc service (just different port+protocol).
They are presented with a page explaining the scheme: their browser will do some work which will generate a ticket that can be exchanged for an account.
Once their browser has generated such a ticket, a html form can post their requested username and password to be registered, along with the ticket.
If the ticket is unused, and the username is available, the registration is completed, and they can then log in to tor with sasl as normal.
If either of the above are untrue, the appropriate error is returned. The ticket submitted is returned unspent for another attempt if appropriate.

The implementation will probably be a wasm module implementing hashcash, a system designed originally to help reduce email spam. Senders are required to generate a string with a number of fixed elements, followed by a random element. The sender must try many combinations of the fixed+random strings to find a hash output that matches a certain pattern. This is expensive, and may take thousands to millions of attempts. The receiver, however, needs check only that a single string hashes to the correct output pattern.

Challenges

The biggest challenge is that the cost must be high enough to deter or limit attackers with significant resources while remaining low enough for honest users. Compounding this is that honest users will probably use the browser ticket generator we present, whereas an attacker will likely use an optimised implementation of the same challenge, but running natively and the results fed via curl/wget.

To mitigate this, the ratio between browser and native performance must be kept as low as possible. It's likely that anything above 2:1 will become unworkable. With this in mind, there's not much to do but hope and pray that browsers' wasm implementations continue to improve in performance.

Additionally, we still don't resolve the issue of users who view javascript/wasm as intolerable to their threat model. It's likely we will never be able to please all of these users, and they are unfortunatley going to be more concentrated in the tor userbase than elsewhere.

Status:

[✔] High level design

[✔] Ticket validation/database

[.] wasm ticket generator

[ ] Web frontend

[ ] Services integration

[ ] Deployment