Resumen

  • El contenido 4984 de LACNIC imprime dos direcciones bajo /rpki/, aunque los atributos de los enlaces conservan dos destinos bajo /innovaportal/file/4983/1/.
  • El 30 de agosto, las direcciones impresas respondieron 200 con text/html, 7.014 bytes y un único SHA-256. Los destinos reales sirvieron archivos TAL distintos de 502 y 518 bytes.
  • Cada TAL nombra su propio certificado y ambos certificados fueron recuperables. No hay base para afirmar que un validador falló, que el repositorio estuvo caído o que una ruta cambió.
  • Una prueba de publicación debería comparar el texto que se copia y el destino que se pulsa, además del tipo, la sintaxis TAL, el hash, el certificado y la memoria de cualquier corrección.

La diferencia aparece antes de la criptografía

La página RPKI Trust Anchors - TAL explica qué información permite a un validador iniciar la validación y expone los bloques del TAL ordinario y del TAL de AS0. Después ofrece dos enlaces de descarga.

Los nombres visibles son /rpki/lacnic.tal y /rpki/lacnic-as0.tal en el host público de LACNIC. Sin embargo, el registro de contenido 4984 guarda como destinos /innovaportal/file/4983/1/lacnic.tal y /innovaportal/file/4983/1/lacnic-as0.tal. A su vez, el entorno público del frontend declara innova.lacnic.net/innovaportal como base de ese servicio histórico.

El navegador puede convertir correctamente la ruta relativa y descargar el fichero. Pero una persona que copia el texto no copia el href. Una automatización que toma el URL de una guía tampoco reproduce el clic. Así, la divergencia ocurre antes de leer una clave: está en la identidad de la entrega.

No hay nada intrínsecamente defectuoso en usar un almacén heredado. Un alias, una redirección o un servicio de descarga pueden ser diseños razonables. Lo que exige control es que la página no presente como dirección del archivo una ruta que produce otra clase de contenido.

Un código 200 no respondió la pregunta correcta

La captura sin caché se realizó el 30 de agosto de 2026 a las 04:48 UTC. Tanto la dirección visible ordinaria como la dirección visible de AS0 devolvieron HTTP 200 y text/html.

Las dos respuestas midieron 7.014 bytes y tuvieron exactamente el mismo SHA-256: 7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416. También compartieron Last-Modified: Fri, 28 Aug 2026 13:20:15 GMT. Eran la carcasa de la aplicación web de LACNIC.

Ese encabezado no fecha el inicio de la divergencia. Tampoco demuestra que la conducta haya sido continua ni que un usuario se haya visto afectado. Solo fija lo que contestaron esos dos URL en el momento de la observación.

Sí demuestra por qué una sonda basada en disponibilidad puede engañar. El servidor estaba disponible y entregó bytes. Pero los bytes no tenían la gramática prometida por la extensión .tal. Una comprobación de formato habría separado la salud del servidor de la identidad del artefacto.

Detrás del href, las dos piezas siguen separadas

El destino del TAL ordinario devolvió 502 bytes, application/aux y SHA-256 d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a. Contiene una localización HTTPS, otra rsync y material de clave pública.

El destino del TAL AS0 devolvió 518 bytes y SHA-256 671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff. No es una copia del primero: usa otra ruta de repositorio, otro certificado y otra clave.

También se recuperaron el certificado ordinario, de 1.166 bytes, y el certificado de AS0, de 1.160. El propósito de esta comprobación no es certificar toda la RPKI de LACNIC, sino impedir una inferencia excesiva. La ruta de documentación y la ruta del repositorio son superficies distintas.

La propia página señala que la mayoría de los validadores ya incluyen los TAL necesarios. Por ello, no es válido convertir una anomalía de distribución separada en una estimación de alcance. No se observó ningún validador, ninguna decisión de origen y ninguna tabla de rutas.

La prueba mínima ya está en el estándar

El RFC 8630 ordena el contenido de un TAL: una o más URI del certificado, una línea vacía y el SubjectPublicKeyInfo codificado en Base64. Luego exige recuperar un certificado de CA RPKI autofirmado vigente y verificar que la clave coincide.

De ahí sale una cadena de evidencia muy concreta. Primero se resuelve una dirección. Después llega una representación. Luego se analiza como TAL. A continuación se obtiene el certificado. Por último se compara la clave. El éxito en una etapa no puede suplir las siguientes.

La página de LACNIC añade otra comparación necesaria: ¿la dirección que el editor decidió mostrar coincide con el destino que el navegador activa? Si no coincide, la entidad debe declarar la relación. De lo contrario, un informe de soporte puede citar un URL y una configuración otro, aunque ambos equipos crean estar trabajando con el mismo artefacto.

La lectura benigna sigue siendo la más fuerte

Los datos encajan con una migración o enrutamiento de frontend incompleto. Las rutas /rpki/ caen en la aplicación general, mientras los enlaces del CMS conservan un mecanismo de descarga funcional. Los TAL y sus certificados no desaparecieron.

LACNIC podría igualar el texto al destino histórico o convertir los URL visibles en alias efectivos. No hace falta imponer qué capa debe ser canónica. Hace falta que pulsar, copiar y verificar produzcan el mismo objeto declarado.

Si la corrección es silenciosa, los futuros usuarios quedarán protegidos, pero las capturas previas perderán contexto. Una nota breve puede explicar que dos etiquetas fueron realineadas. Un recibo técnico puede conservar el hash de la página anterior y la relación de reemplazo sin divulgar ninguna clave privada ni datos de operadores.

Un recibo de entrega, no un dictamen de seguridad

El control debería registrar, para cada elemento, versión de página, texto visible, href sin resolver, destino absoluto, función ordinaria o AS0, tipo esperado y estado de alias. La sonda pediría tanto el URL visible como el destino efectivo.

Para cada respuesta guardaría código, tipo, longitud y hash. Después validaría la estructura TAL, extraería URI y clave, recuperaría el certificado preferido y anotaría correspondencia. Si encuentra HTML, debe abrir un incidente de publicación, no declarar inválida una infraestructura criptográfica.

El historial es parte del control: momento de detección, hash anterior, corrección, razón general y sucesor. Ese registro permite que un tercero explique una respuesta antigua después de que el sitio cambie.

La diferencia observada cabe en una frase: los clics entregaron los archivos; las direcciones que el texto invitaba a copiar no. Precisamente por ser una diferencia tan pequeña, puede probarse y corregirse sin exageración.

Fuentes