Requisitos de Autenticação de Relay no Mastodon: Configuração de HTTP Signature
🔍 WiseChecker

Requisitos de Autenticação de Relay no Mastodon: Configuração de HTTP Signature

Ao configurar um relay no Mastodon para impulsionar a federação entre instâncias, o servidor relay precisa se autenticar na sua instância antes de entregar postagens públicas. Sem autenticação adequada, a conexão falha silenciosamente ou gera um erro 401 nos logs. Essa autenticação depende de HTTP Signatures, um handshake criptográfico que prova que o servidor relay é quem diz ser. Este artigo explica o que são HTTP Signatures para relays do Mastodon, por que são necessárias e como configurar tanto o servidor relay quanto sua instância para estabelecer uma configuração funcional de assinatura.

Principais Conclusões: Configuração de HTTP Signature para Relay no Mastodon

  • HTTP Signatures (RFC 9421): Método criptográfico que anexa um cabeçalho assinado a cada requisição ActivityPub enviada pelo relay.
  • Registro da chave pública do relay: O servidor relay deve expor sua chave pública por meio de seu próprio objeto Actor para que sua instância possa verificar as assinaturas recebidas.
  • WHITELIST_MODE e AUTHORIZED_FETCH: Duas configurações do servidor Mastodon que podem bloquear conexões de relay se não forem ajustadas para permitir o tráfego do relay.

ADVERTISEMENT

Por que Relays do Mastodon Exigem HTTP Signatures

Relays do Mastodon são atores ActivityPub que coletam postagens públicas de instâncias inscritas e as redistribuem para todas as outras instâncias inscritas. Quando um relay envia uma postagem para sua instância, ele faz uma requisição HTTP POST para o endpoint inbox da sua instância. O Mastodon verifica toda requisição ActivityPub recebida checando o cabeçalho HTTP Signature. Se a assinatura estiver ausente, inválida ou assinada com uma chave que sua instância não reconhece, a requisição é rejeitada com um código de status 401 ou 403.

A causa raiz das falhas de autenticação de relay é quase sempre um de três problemas:

  • O servidor relay não gera HTTP Signatures.
  • O servidor relay usa uma chave privada que não corresponde à chave pública anunciada em seu perfil Actor.
  • Sua instância Mastodon não consegue buscar o objeto Actor do relay para obter a chave pública.

HTTP Signatures funcionam fazendo o servidor relay criar uma string com valores de cabeçalho da requisição (como data, digest e destino da requisição), assinar essa string com sua chave privada e anexar a assinatura resultante no cabeçalho Signature. Sua instância então busca a chave pública do relay no endpoint Actor do próprio relay, descriptografa a assinatura e compara o resultado. Se o hash descriptografado corresponder aos cabeçalhos, a requisição é autenticada.

O Papel do Objeto Actor do Relay

Todo relay do Mastodon deve expor um objeto Actor em uma URL como https://relay.example.com/actor. Esse objeto Actor contém um campo publicKey com uma propriedade publicKeyPem. O Mastodon lê essa chave pública para verificar assinaturas. Se o objeto Actor não estiver acessível, retornar um 404 ou conter uma string PEM inválida, a autenticação falha.

Passos para Configurar HTTP Signatures para um Relay do Mastodon

Método 1: Configurar o Servidor Relay para Gerar HTTP Signatures

A maioria dos softwares de relay do Mastodon, como a gem oficial mastodon-relay (Ruby) ou Pub-Relay, suporta HTTP Signatures nativamente. Você precisa garantir que o servidor relay tenha uma chave privada válida e que seu objeto Actor seja servido corretamente.

  1. Gerar um par de chaves RSA dedicado para o relay
    No servidor relay, execute openssl genrsa -out relay-private.pem 2048 e openssl rsa -in relay-private.pem -pubout -out relay-public.pem. Armazene a chave privada em um local que o software do relay possa ler, como /etc/relay/keys/.
  2. Apontar o software do relay para a chave privada
    No arquivo de configuração do relay, defina private_key_path como o caminho completo do arquivo de chave privada. Para Pub-Relay, isso é tipicamente a variável de ambiente PRIVATE_KEY. Para o relay Ruby, é a configuração private_key em config.yml.
  3. Verificar se o objeto Actor está sendo servido na URL correta
    Acesse https://relay.example.com/actor em um navegador ou com curl. A resposta deve ser JSON com um objeto publicKey contendo id, owner e publicKeyPem. O valor de publicKeyPem deve corresponder exatamente ao conteúdo de relay-public.pem.
  4. Testar a geração de assinatura pela CLI do relay
    Muitas ferramentas de relay incluem um comando de teste. Para o relay Ruby, execute ruby bin/test_signature. Procure por saída que diga “Signature valid” ou mostre uma resposta HTTP 200 bem-sucedida de uma instância de teste.

Método 2: Configurar Sua Instância Mastodon para Aceitar Assinaturas do Relay

Sua instância Mastodon deve ser capaz de buscar o objeto Actor do relay e confiar em sua chave pública. Se sua instância estiver atrás de um firewall ou usar políticas de busca restritivas, você deve ajustar essas configurações.

  1. Garantir que conexões HTTPS de saída sejam permitidas para o domínio do relay
    Verifique as regras de firewall do seu servidor. O Mastodon deve poder fazer uma requisição HTTP GET para https://relay.example.com/actor. Se você usar um proxy como Nginx ou Apache, verifique se o proxy não bloqueia ou modifica os cabeçalhos de resposta.
  2. Desabilitar AUTHORIZED_FETCH na sua instância se estiver bloqueando o tráfego do relay
    No seu arquivo .env.production, defina AUTHORIZED_FETCH=false e reinicie o Mastodon. Quando AUTHORIZED_FETCH é true, o Mastodon exige HTTP Signatures em todas as requisições de saída, incluindo as de relays. Essa configuração pode causar uma dependência circular onde o relay não consegue buscar seu Actor porque sua instância exige uma assinatura de um relay que ainda não foi autenticado.
  3. Adicionar o domínio do relay ao WHITELIST_MODE se você usar esse recurso
    Se WHITELIST_MODE=true no seu ambiente, apenas instâncias listadas na tabela whitelist podem federar. Adicione o domínio do relay executando RAILS_ENV=production bin/tootctl domain add relay.example.com no seu servidor Mastodon.
  4. Monitorar os logs do Mastodon em busca de erros de assinatura
    Execute journalctl -u mastodon-sidekiq -f e procure por linhas contendo HTTP Signature ou signature_verification_failure. Esses logs informam se a verificação de assinatura passou ou falhou e geralmente incluem o key ID do relay.

ADVERTISEMENT

Se o Relay Ainda Falhar na Autenticação

Objeto Actor do Relay Retorna Erro 404 ou 500

Se https://relay.example.com/actor não retornar uma resposta JSON válida, o Mastodon não consegue obter a chave pública. Verifique a configuração do servidor web do relay. O endpoint Actor geralmente é servido por um servidor web separado, como Caddy ou Nginx. Certifique-se de que o proxy reverso está configurado para passar requisições para a porta interna do software relay. Para Pub-Relay, a porta interna padrão é 8080. Adicione um bloco de localização no Nginx que faça proxy de /actor para http://127.0.0.1:8080/actor.

Cabeçalho Signature Contém um Key ID Errado

O cabeçalho HTTP Signature inclui um parâmetro keyId que aponta para a URL da chave pública. O Mastodon usa essa URL para buscar a chave. Se o keyId for uma URL absoluta que não corresponde à URL do Actor do relay, a busca falha. Por exemplo, se o relay enviar keyId="https://relay.example.com/actor#main-key" mas o endpoint Actor real for https://relay.example.com/actor, o Mastodon pode não conseguir analisar a chave. Muitos relays usam o fragmento #main-key para identificar a chave. Verifique se o JSON do Actor inclui um objeto publicKey cujo campo id corresponde exatamente ao keyId.

Diferença de Horário Entre Servidores

HTTP Signatures incluem um cabeçalho date que o Mastodon compara com seu próprio relógio do sistema. Se o relógio do servidor relay estiver com uma diferença superior a 30 segundos, a assinatura é rejeitada. Sincronize ambos os servidores com o mesmo pool NTP. Execute timedatectl set-ntp true tanto no relay quanto nos servidores Mastodon. Depois verifique a diferença com timedatectl show --property=NTPSynchronized.

Item Configuração do Servidor Relay Configuração da Instância Mastodon
Chave privada Chave RSA de 2048 bits armazenada em um arquivo que o software do relay possa ler Não necessária; o Mastodon só precisa da chave pública do relay
Exposição da chave pública Servida pelo endpoint JSON do Actor Buscada automaticamente da URL keyId no cabeçalho Signature
Algoritmo de assinatura rsa-sha256 conforme especificado no campo algorithm do cabeçalho Signature Verifica usando o mesmo algoritmo
Sincronização de relógio NTP habilitado, diferença inferior a 30 segundos NTP habilitado, diferença inferior a 30 segundos
Política de busca Nenhuma necessária AUTHORIZED_FETCH=false ou domínio do relay permitido na lista de fetch autorizado

Com ambos os lados configurados corretamente, o relay pode enviar payloads ActivityPub assinados e sua instância Mastodon os aceitará. Após configurar HTTP Signatures, inscreva-se no relay a partir da sua instância navegando até Preferências > Administração > Relays e inserindo a URL do inbox do relay. Em seguida, observe o painel do Sidekiq para verificar a entrega bem-sucedida de postagens federadas. Para solução de problemas avançada, use curl -v para reproduzir manualmente uma requisição do relay e inspecionar o formato do cabeçalho Signature.

ADVERTISEMENT