disclaimer

this project might be a silly waste of time

SITE

CODE

what

onion.monster is a tor2web style proxy but intended to only expose ActivityPub hidden services. This allows them to federate with all other servers without them having to set up their own tor proxy + routing AND it allows for https requests to be made to the hidden service. The ability to receive incoming HTTPS requests is very important because a lot (if not all) of ActivityPub implementations are HTTPS only.

how

onion.monster arch

why

This lets people spin up their own ActivityPub server without having to disclose their server location or have knowledge of where their clients are connecting from. Edgy Boys/Girls can use this to (kinda) improve the opsec of their little larps.

Additionally, as a project, it is also something fun + limited to implement in my spare time.

security problems

early HTTPS termination

HTTPS is terminated at proxy level, and a HTTP request is made to the hidden service. while the http connection is safe to move through the tor network (due to onion routing), it is exposed to the proxy. the proxy could inspect the contents of the request (severity of this depends if the message is intended to be private or public and how the server is intended to be operated)

As a publisher/user, connecting to the server through onion.monster is riskier since there is no mechanism to guarantee that the request has not been modified by the server. Even more concerning, the user passwords are exposed to the proxy (where they could be logged) and not all servers support 2fa.

At the end of the day, the proxy does not need to inspect the contents of the request, only hostname. Ideally, it would be best if the proxy could not access the contents of the request.

Since all servers are running under same root domain, they have the ability to muck around with cookies on the root domain.

attack details

things that work fine otherwise

  • incoming federation requests - http signature ensures that they have not been tamper with by the proxy
  • outgoing federation requests - they do not go back out through onion.monster (but ideally their own tor client)
  • very limited amount of code - reduces attack surfaces + easy to audit

TODO - confirm publishers should/could connect to their server either locally OR directly through their onion domain

federation problem/risk

Randos are operating under the same root domain, if someone finds a problem with a single server, they may just blacklist the entire root domain. If this blacklisting grows to be included in the shared blacklists, then all servers (including future ones) will never been seen by a good chunk of the “fedi verse”

This is why running a server using one of the existing tor2web services, would not be a good idea (since they are mostly unmoderated). onion.monster operates on a whitelist model, where only known servers are allowed to be served through it. Ideally, if someone starts to cause trouble, only their server will be removed -> this does still have the ‘someone else’ can kick me off a fedi server if they dont like me BUT said bad actor would still process their data, and they could move their server elsewhere.

next steps

would be really cool if the proxy did not have to know about the contents of the request. There are possible 2 ways of achieving this:

  1. HTTPS onion domains, as of 2024 they are expensive, rare, and difficult to get. MAYBE this will change in the future. -> request is still terminated at the proxy so this wouldnt get us much (if anything)
  2. e2e encryption on the publisher messages to the server BUT that requires a custom client + server. this does not exist today AND it would require a custom implementation. since I see this as a very small niche (and kinda against the intent of activity pub with servers + server administration being very important) I dont see anyone implementing this this does start sounding more like Nostr….
  3. ActivityPub relay? If this could be more easily exposed through a relay, do let me know. -> relays are more of a server admin level thing, rather than individual user thing.