Documento técnico sobre seguridad y privacidad (resumen)Capítulo 12
Capítulo 12: Evidencia verificable por terceros y página de estado
Más allá de nuestras afirmaciones de diseño internas, FileBolt ofrece evidencia de terceros reproducible públicamente (Evidence) para verificar propiedades de seguridad visibles (como la configuración de TLS, las políticas de cabeceras de seguridad, etc.). Este capítulo define los tipos de evidencia, su ámbito de aplicación, los enlaces de acceso y los principios para relacionar la evidencia con los ID de afirmaciones.
12.0 Resumen
- DEBERÍA: ofrecer enlaces públicos y reproducibles a evidencia de terceros para verificar las bases de seguridad visibles (TLS, cabeceras, etc.).
- DEBE: los enlaces de evidencia apuntan solo a fuentes autorizadas, nunca a capturas de pantalla ni a republicaciones secundarias.
- DEBE: definir explícitamente el alcance de la evidencia: los análisis externos no pueden verificar directamente los detalles completos de la implementación de conocimiento cero y E2EE.
- DEBERÍA: usar la página de estado para agrupar los enlaces de evidencia, mientras que los campos de evidencia de las afirmaciones deberían apuntar directamente a la fuente original de terceros.
12.1 Tipos de evidencia y alcance
12.1.1 Qué se puede verificar
La evidencia de terceros suele verificar:
- Configuración de la capa de transporte: versiones de TLS, cadenas de certificados, conjuntos de cifrado, HSTS, etc. (según las capacidades del analizador).
- Políticas de seguridad HTTP: existencia y configuración básica de cabeceras como CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, etc.
- Superficie web visible públicamente: errores de configuración habituales, endpoints expuestos y puntuaciones de seguridad de referencia.
12.1.2 Qué no se puede verificar directamente
La evidencia de terceros normalmente no puede verificar directamente:
- Corrección del conocimiento cero: p. ej., «el servidor no puede acceder a la CEK», los flujos de cifrado del lado del cliente y los detalles de la derivación de claves.
- Operaciones internas y control de acceso: p. ej., permisos internos, flujos de gestión de claves, depuración de registros y auditoría de accesos.
- Seguridad absoluta: los análisis solo cubren sus conjuntos de reglas concretos y las superficies visibles; no sustituyen a la ingeniería de seguridad continua ni a la respuesta a incidentes.
Por ello, este documento técnico distingue entre «bases de seguridad visibles» y «límites del protocolo y de la implementación»: las bases visibles se pueden verificar mediante evidencia; los límites del conocimiento cero y del E2EE se rigen por las especificaciones del protocolo y las restricciones del cliente (consulta el capítulo 5 y las secciones relacionadas).
12.2 La página de estado como centro de agregación
FileBolt usa /status como centro de agregación de los enlaces de evidencia. No sustituye a los propios informes de terceros, sino que ofrece una navegación unificada para que usuarios y auditores puedan repetir la verificación.
- DEBE: los enlaces de evidencia de la página de estado apuntan a fuentes autorizadas de terceros (reproducibles).
- DEBERÍA: la página de estado puede indicar la «fecha y hora de la última comprobación», pero no debería presentarla como una conclusión permanente e inmutable.
- DEBERÍA: si rutas concretas (p. ej., las páginas de descarga y descifrado) emplean cabeceras más estrictas, puede ofrecerse en la página de estado evidencia a nivel de ruta (si las herramientas de terceros lo admiten).
12.3 Evidencia de la configuración de TLS
La evidencia de TLS verifica la configuración de HTTPS, las versiones del protocolo, las cadenas de certificados y los atributos visibles. Algunos ejemplos:
- Índice de la página de estado: /status#tls-configuration
- Fuente autorizada de terceros (ejemplo): Informe TLS de SSL Labs
Nota: la evidencia de TLS refleja la configuración visible en el «momento del análisis»; no demuestra los límites del contenido de extremo a extremo ni si el servidor puede acceder a la CEK.
12.4 Evidencia de las cabeceras de seguridad
La evidencia de las cabeceras de seguridad verifica la existencia y la configuración de políticas básicas como CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy, etc.
- Índice de la página de estado: /status#security-headers
- Fuente de terceros (ejemplo): Informe de SecurityHeaders
Recomendación: si las páginas de descarga y descifrado (p. ej., /transfer, /d/**) usan políticas más estrictas, la documentación interna debería indicar que «las rutas críticas son más estrictas» y, cuando sea viable, deberían elegirse herramientas que admitan análisis de rutas concretas como evidencia complementaria.
12.5 Análisis integrales de buenas prácticas
Los análisis integrales cubren comprobaciones de buenas prácticas más amplias (p. ej., configuración HTTP, debilidades habituales y combinaciones de políticas de caché y seguridad). Aportan una verificación auxiliar de las bases del sitio, pero no equivalen a una auditoría de la implementación del protocolo.
- Índice de la página de estado: /status#http-observatory
- Fuente de terceros (ejemplo): Mozilla Observatory
12.6 Principios de correspondencia: evidencia e ID de afirmaciones
- DEBE: cada afirmación verificable (Claim) tiene un ID único y un ancla estable en el índice de ID de afirmaciones.
- DEBE: el campo de evidencia de una afirmación apunta solo a fuentes autorizadas (páginas de informes de terceros o páginas oficiales reproducibles) y NO DEBE apuntar a capturas de pantalla, resúmenes ni republicaciones no autorizadas.
- DEBERÍA: la página de estado puede servir como «colección de navegación» de la evidencia, pero el campo de evidencia principal de una afirmación debería apuntar siempre que sea posible a la fuente original de terceros.
- DEBE: la redacción de las afirmaciones debe ajustarse al alcance de la evidencia, evitando presentar las «bases visibles» como «garantías de seguridad absolutas».
Índice de ID de afirmaciones (única fuente de referencia): /security-privacy-appendix-claim-ids
12.7 Temporalidad y lenguaje normativo
Los resultados de los análisis de terceros cambian con el tiempo (por actualizaciones de las reglas del analizador, cambios en la configuración del sitio, rotación de certificados, etc.). Las referencias a la evidencia deben usar una redacción del tipo «verificable pero no absoluta».
- DEBERÍA: registrar la «fecha y hora de la última verificación» (si procede) en la página de estado o en la documentación y permitir que los usuarios repitan la verificación.
- DEBE: evitar la redacción «permanente» o «absoluta»; usar un lenguaje acorde con el alcance de la evidencia, como «el análisis indica que está activado o es conforme».
- DEBERÍA: cuando cambien políticas de seguridad críticas (p. ej., endurecimiento de la CSP, actualizaciones de TLS), registrarlo en el registro de cambios y enlazar los ID de afirmaciones pertinentes.
12.8 ID de afirmaciones relacionados (reservado)
Este capítulo trata sobre la «evidencia de terceros y los principios de correspondencia». Los ID de afirmaciones correspondientes se mantienen en el Apéndice: índice de ID de afirmaciones como única fuente de referencia.