Logo

Livre blanc sur la sécurité et la confidentialité (présentation)Chapitre 12

Chapitre 12 : Preuves vérifiables par des tiers et page d'état

Au-delà de nos affirmations de conception interne, FileBolt fournit des preuves tierces publiquement reproductibles (Evidence) pour vérifier les propriétés de sécurité visibles (comme la configuration TLS, les politiques d'en-têtes de sécurité, etc.). Ce chapitre définit les types de preuves, la portée applicable, les liens d'accès et les principes de correspondance entre les preuves et les identifiants d'affirmation.

12.0 Résumé

  • DEVRAIT : fournir des liens publics et reproductibles vers des preuves tierces afin de vérifier les bases de sécurité visibles (TLS, en-têtes, etc.).
  • DOIT : les liens de preuves ne pointent que vers des sources faisant autorité, jamais vers des captures d'écran ou des republications secondaires.
  • DOIT : définir explicitement la portée des preuves : les analyses externes ne peuvent pas vérifier directement tous les détails d'implémentation du Zero-Knowledge/E2EE.
  • DEVRAIT : utiliser la page d'état pour regrouper les liens de preuves, tandis que les champs de preuve des affirmations doivent pointer directement vers la source tierce d'origine.

12.1 Types de preuves et portée

12.1.1 Ce qui peut être vérifié

Les preuves tierces permettent généralement de vérifier :

  • La configuration de la couche transport : versions de TLS, chaînes de certificats, suites de chiffrement, HSTS, etc. (selon les capacités de l'outil d'analyse).
  • Les politiques de sécurité HTTP : existence et configuration de base d'en-têtes tels que CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, etc.
  • La surface Web publiquement visible : erreurs de configuration courantes, points d'accès exposés et scores de sécurité de base.

12.1.2 Ce qui ne peut pas être vérifié directement

Les preuves tierces ne permettent généralement pas de vérifier directement :

  • L'exactitude du Zero-Knowledge : par exemple, « le serveur ne peut pas accéder à la CEK », les flux de chiffrement côté client et les détails de dérivation des clés.
  • Les opérations internes et le contrôle d'accès : par exemple, les autorisations internes, les processus de gestion des clés, l'assainissement des journaux et l'audit des accès.
  • La sécurité absolue : les analyses ne couvrent que leurs jeux de règles spécifiques et les surfaces visibles ; elles ne remplacent ni l'ingénierie de sécurité continue ni la réponse aux incidents.

C'est pourquoi ce livre blanc distingue les « bases de sécurité visibles » des « frontières du protocole et de l'implémentation » : les bases visibles sont vérifiables via les preuves ; les frontières du Zero-Knowledge/E2EE sont régies par les spécifications du protocole et les contraintes du client (voir le chapitre 5 et les sections associées).

12.2 La page d'état comme point d'agrégation

FileBolt utilise /status comme point d'agrégation des liens de preuves. Elle ne remplace pas les rapports tiers eux-mêmes, mais offre une navigation unifiée permettant aux utilisateurs et aux auditeurs de répéter les vérifications.

  • DOIT : les liens de preuves de la page d'état pointent vers des sources tierces faisant autorité (reproductibles).
  • DEVRAIT : la page d'état peut indiquer une « date/horodatage de dernière vérification », mais ne doit pas la présenter comme une conclusion permanente et immuable.
  • DEVRAIT : si des chemins spécifiques (par ex. les pages de téléchargement/déchiffrement) utilisent des en-têtes plus stricts, des preuves au niveau du chemin peuvent être fournies sur la page d'état (si les outils tiers le permettent).

12.3 Preuves de la configuration TLS

Les preuves TLS vérifient la configuration HTTPS, les versions du protocole, les chaînes de certificats et les attributs visibles. Exemples :

Remarque : les preuves TLS reflètent la configuration visible « au moment de l'analyse » ; elles ne prouvent ni les frontières du contenu de bout en bout ni si le serveur peut accéder à la CEK.

12.4 Preuves des en-têtes de sécurité

Les preuves sur les en-têtes de sécurité vérifient l'existence et la configuration de politiques de base telles que CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy, etc.

Recommandation : si les pages de téléchargement/déchiffrement (par ex. /transfer, /d/**) utilisent des politiques plus strictes, la documentation interne devrait indiquer « les chemins critiques sont plus stricts » et, lorsque c'est possible, il convient de choisir des outils prenant en charge l'analyse de chemins spécifiques comme preuves complémentaires.

12.5 Analyses complètes des bonnes pratiques

Les analyses complètes couvrent des vérifications de bonnes pratiques plus larges (par ex. configuration HTTP, faiblesses courantes, combinaisons de politiques de cache et de sécurité). Elles apportent une vérification complémentaire des bases du site, mais ne sont pas équivalentes à des audits de l'implémentation du protocole.

12.6 Principes de correspondance : preuves et identifiants d'affirmation

  • DOIT : chaque affirmation vérifiable (Claim) possède un identifiant unique et une ancre stable dans la liste maîtresse des identifiants d'affirmation.
  • DOIT : le champ Preuve (Evidence) d'une affirmation ne pointe que vers des sources faisant autorité (pages de rapports tiers ou pages officielles reproductibles) et NE DOIT PAS pointer vers des captures d'écran, des résumés ou des republications sans autorité.
  • DEVRAIT : la page d'état peut servir de « collection de navigation » pour les preuves, mais le champ de preuve principal d'une affirmation devrait, autant que possible, pointer vers la source tierce d'origine.
  • DOIT : la formulation des affirmations doit rester alignée sur la portée des preuves, en évitant de présenter à tort des « bases visibles » comme des « garanties de sécurité absolues ».

Liste maîtresse des identifiants d'affirmation (autorité unique) : /security-privacy-appendix-claim-ids

12.7 Temporalité et langage normatif

Les résultats des analyses tierces évoluent avec le temps (mises à jour des règles de l'outil, changements de configuration du site, rotation des certificats, etc.). Les références aux preuves doivent employer une formulation du type « vérifiable mais non absolu ».

  • DEVRAIT : consigner la « date/heure de dernière vérification » (le cas échéant) sur la page d'état ou dans la documentation et permettre aux utilisateurs de refaire la vérification.
  • DOIT : éviter les formulations « permanent/absolu » ; employer un langage correspondant à la portée de la preuve, par exemple « l'analyse indique activé/conforme ».
  • DEVRAIT : lorsque des politiques de sécurité critiques changent (par ex. durcissement de la CSP, mises à jour TLS), l'enregistrer dans le journal des modifications et lier les identifiants d'affirmation concernés.

12.8 Identifiants d'affirmation associés (réservé)

Ce chapitre couvre les « preuves tierces et principes de correspondance ». Les identifiants d'affirmation correspondants sont tenus à jour dans l' Annexe : liste maîtresse des identifiants d'affirmation qui constitue l'unique source faisant foi.