Resumo

  • O conteúdo 4984 da LACNIC mostra dois URLs completos em /rpki/, mas os hrefs guardados apontam para arquivos distintos em /innovaportal/file/4983/1/.
  • Em 30 de agosto, os dois endereços mostrados responderam HTTP 200, text/html, 7.014 bytes e o mesmo SHA-256; os alvos dos cliques retornaram TALs de 502 e 518 bytes.
  • Cada TAL nomeia um certificado diferente, e ambos os certificados puderam ser obtidos. Isso limita o achado à distribuição pública e não sustenta alegações sobre validador, repositório, certificado, ROA ou rota.
  • Um recibo de publicação deve conferir texto, href resolvido, tipo de mídia, gramática TAL, hash, certificado associado e memória da correção.

A página promete um arquivo de duas maneiras

A página RPKI Trust Anchors - TAL descreve o TAL regular, apresenta um TAL específico para a política AS0 e, ao final, oferece dois links de download. Para o leitor, os endereços são /rpki/lacnic.tal e /rpki/lacnic-as0.tal no host público da LACNIC.

O registro 4984 no CMS conta outra parte da história. Sob o primeiro rótulo está /innovaportal/file/4983/1/lacnic.tal; sob o segundo, /innovaportal/file/4983/1/lacnic-as0.tal. O ambiente público do frontend declara innova.lacnic.net/innovaportal como base do Innovaportal.

Ao clicar, o navegador usa o href e alcança o serviço antigo. Ao copiar, a pessoa leva o texto para outra ferramenta e consulta a rota do site novo. A diferença é invisível para quem testa apenas o botão, mas decisiva para quem prepara um script, uma instrução de suporte ou um registro de auditoria.

Não há obrigação de abandonar o serviço legado. A LACNIC pode mantê-lo, criar aliases ou redirecionar. O requisito mínimo é declarar qual URL identifica o artefato e fazer com que a promessa escrita sobreviva fora do navegador.

Disponibilidade HTTP não foi disponibilidade do TAL

Às 04:48 UTC de 30 de agosto de 2026, requisições sem cache consultaram o URL visível regular e o URL visível AS0. Os dois responderam 200 com text/html.

As respostas tinham 7.014 bytes e o SHA-256 idêntico 7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416. O horário Last-Modified, 28 de agosto às 13:20:15 GMT, também coincidia. Tratava-se da página-base do aplicativo LACNIC.

Esse horário não revela quando o desalinhamento começou. A captura não mostra persistência anterior, uso por terceiros ou comportamento de caches externos. Muito menos demonstra que algum validador aceitou HTML.

Ela mostra, porém, como um monitor pode produzir um verde enganoso. Código 200, TLS e latência medem a entrega de uma representação. Um teste de TAL precisa encontrar URIs de certificado, a separação prevista e material de chave pública. O sufixo no caminho não substitui a análise.

Os alvos reais mantiveram as funções separadas

O alvo regular no Innovaportal respondeu application/aux, 502 bytes e SHA-256 d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a. O arquivo traz localizações HTTPS e rsync para o certificado regular, seguidas da chave pública.

O alvo AS0 respondeu 518 bytes e SHA-256 671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff. Ele aponta para outro caminho e contém outra chave.

O certificado regular, com 1.166 bytes, e o certificado AS0, com 1.160, estavam acessíveis. São objetos binários distintos.

Esses fatos não certificam o estado integral da infraestrutura, mas impedem uma conclusão inflada. A entrega dos arquivos pelo clique funcionava na observação. A página ainda informa que a maioria das ferramentas já inclui os TALs necessários. Não há base para atribuir impacto a operadores ou ao roteamento.

O padrão separa cada etapa da confiança

O RFC 8630 estrutura um TAL como uma ou mais URIs ordenadas, uma linha vazia e o SubjectPublicKeyInfo em Base64. A parte confiante recupera o certificado, verifica que ele é um certificado de CA RPKI atual e autoassinado e compara a chave.

São provas diferentes: o nome resolveu; o servidor respondeu; o conteúdo analisou como TAL; o certificado foi recuperado; a chave coincidiu. Um 200 resolve apenas uma delas.

Antes dessa cadeia há a prova editorial: o que aparece escrito e o que o link executa formam a mesma edição? Uma diferença pode ser intencional, mas precisa ser declarada. Em material de bootstrap, URLs migram para ambientes em que não existe clique e o href fica invisível.

A explicação mais simples não exige alarmismo

O conjunto observado é compatível com uma migração de frontend que passou a tratar /rpki/ como rota da aplicação, enquanto o CMS preservou os downloads antigos. Os dois TALs e os certificados nomeados continuaram disponíveis. Não foi encontrada evidência de ataque, corrupção ou falha de validação.

Uma correção pode alterar os rótulos ou tornar os endereços exibidos aliases reais. O resultado deve ser o mesmo: clicar, copiar e automatizar chegam ao artefato correspondente.

Corrigir em silêncio melhora o futuro, mas deixa as respostas antigas sem explicação. Um aviso curto ou recibo versionado pode registrar o hash da página anterior, os pares de URL, o momento da correção e o novo estado canônico. Isso preserva a confiança sem transformar a diferença em incidente de segurança.

Um canário para o rótulo e outro para o href

Cada item de download deveria ter versão da página, texto exibido, href bruto, destino absoluto, papel regular ou AS0, tipo esperado e estado de alias. O canário consultaria tanto o texto quanto o destino.

Ele guardaria status, mídia, comprimento e digest, validaria a gramática, extrairia as URIs e a chave e buscaria o certificado preferido. Resultado HTML abriria uma falha de publicação. Só evidência posterior permitiria falar de problema criptográfico ou operacional.

O histórico precisa sobreviver à correção: detecção, estado anterior, motivo geral, substituto e aliases mantidos. Assim, uma coleta antiga continua explicável quando a aplicação já mudou.

Os dois cliques entregaram arquivos; os dois endereços visíveis entregaram a mesma página. Um único semáforo de disponibilidade não consegue representar essa diferença.

Fontes