Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 12

Capitolo 12: prove verificabili da terze parti e pagina di stato

Oltre alle nostre affermazioni di progettazione interne, FileBolt mette a disposizione prove di terze parti riproducibili pubblicamente (Evidence) per verificare le proprietà di sicurezza visibili (come la configurazione TLS, le policy sugli header di sicurezza, ecc.). Questo capitolo definisce i tipi di prove, l'ambito di applicazione, i link di accesso e i principi per collegare le prove agli ID delle affermazioni.

12.0 Riepilogo

  • DOVREBBE: offrire link pubblici e riproducibili a prove di terze parti per verificare le basi di sicurezza visibili (TLS, header, ecc.).
  • DEVE: i link alle prove rimandano solo a fonti autorevoli, mai a screenshot o a ripubblicazioni secondarie.
  • DEVE: definire esplicitamente l'ambito delle prove: le scansioni esterne non possono verificare direttamente tutti i dettagli di implementazione di zero-knowledge/E2EE.
  • DOVREBBE: usare la pagina di stato per aggregare i link alle prove, mentre i campi Evidence delle affermazioni dovrebbero rimandare direttamente alla fonte originale di terze parti.

12.1 Tipi e ambito delle prove

12.1.1 Cosa si può verificare

Le prove di terze parti in genere verificano:

  • Configurazione del livello di trasporto: versioni di TLS, catene di certificati, suite di cifratura, HSTS, ecc. (in base alle capacità dello scanner).
  • Policy di sicurezza HTTP: presenza e configurazione di base di header come CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, ecc.
  • Superficie web visibile pubblicamente: configurazioni errate comuni, endpoint esposti e punteggi di sicurezza di base.

12.1.2 Cosa non si può verificare direttamente

Le prove di terze parti in genere non possono verificare direttamente:

  • Correttezza dello zero-knowledge: ad es. “il server non può accedere alla CEK”, i flussi di cifratura lato client e i dettagli della derivazione delle chiavi.
  • Operazioni interne e controllo degli accessi: ad es. permessi interni, flussi di gestione delle chiavi, sanificazione dei log e audit degli accessi.
  • Sicurezza assoluta: le scansioni coprono solo i propri insiemi di regole e le superfici visibili; non sostituiscono l'ingegneria della sicurezza continua e la risposta agli incidenti.

Per questo il whitepaper distingue tra “basi di sicurezza visibili” e “confini di protocollo/implementazione”: le basi visibili si possono verificare tramite le prove (Evidence); i confini zero-knowledge/E2EE sono regolati dalle specifiche di protocollo e dai vincoli del client (vedi il capitolo 5 e le sezioni correlate).

12.2 La pagina di stato come hub di aggregazione

FileBolt usa /status come hub di aggregazione dei link alle prove. Non sostituisce i report di terze parti, ma offre una navigazione unificata che permette a utenti e auditor di ripetere la verifica.

  • DEVE: i link alle prove nella pagina di stato rimandano a fonti autorevoli di terze parti (riproducibili).
  • DOVREBBE: la pagina di stato può indicare la “data/ora dell'ultimo controllo”, ma non dovrebbe presentarla come una conclusione permanente e immutabile.
  • DOVREBBE: se percorsi specifici (ad es. le pagine di download/decifratura) usano header più rigorosi, nella pagina di stato si possono fornire prove a livello di percorso (se gli strumenti di terze parti lo supportano).

12.3 Prove sulla configurazione TLS

Le prove TLS verificano la configurazione HTTPS, le versioni del protocollo, le catene di certificati e gli attributi visibili. Alcuni esempi:

Nota: le prove TLS riflettono la configurazione visibile al “momento della scansione”; non dimostrano i confini del contenuto end-to-end né se il server possa accedere alla CEK.

12.4 Prove sugli header di sicurezza

Le prove sugli header di sicurezza verificano la presenza e la configurazione di policy di base come CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy, ecc.

Raccomandazione: se le pagine di download/decifratura (ad es. /transfer, /d/**) usano policy più rigorose, la documentazione interna dovrebbe riportare “i percorsi critici sono più rigorosi” e, ove possibile, andrebbero scelti come prove supplementari strumenti che supportino la scansione di percorsi specifici.

12.5 Scansioni complete delle buone pratiche

Le scansioni complete coprono controlli più ampi sulle buone pratiche (ad es. configurazione HTTP, debolezze comuni, combinazioni di cache e policy di sicurezza). Offrono una verifica ausiliaria delle basi del sito, ma non equivalgono a un audit dell'implementazione del protocollo.

12.6 Principi di corrispondenza: prove e ID delle affermazioni

  • DEVE: ogni affermazione verificabile (Claim) ha un ID univoco e un'ancora stabile nell'elenco principale degli ID delle affermazioni.
  • DEVE: il campo Evidence di un'affermazione rimanda solo a fonti autorevoli (pagine di report di terze parti o pagine ufficiali riproducibili) e NON DEVE rimandare a screenshot, riepiloghi o ripubblicazioni non autorevoli.
  • DOVREBBE: la pagina di stato può servire come “raccolta di navigazione” per le prove, ma il campo Evidence principale di un'affermazione dovrebbe, quando possibile, rimandare alla fonte originale di terze parti.
  • DEVE: la formulazione delle affermazioni deve essere coerente con l'ambito delle prove, evitando di presentare le “basi visibili” come “garanzie di sicurezza assolute”.

Elenco principale degli ID delle affermazioni (unica fonte autorevole): /security-privacy-appendix-claim-ids

12.7 Temporalità e linguaggio normativo

I risultati delle scansioni di terze parti cambiano nel tempo (per aggiornamenti delle regole dello scanner, modifiche alla configurazione del sito, rotazione dei certificati, ecc.). I riferimenti alle prove dovrebbero usare formule come “verificabile ma non assoluto”.

  • DOVREBBE: registrare la “data/ora dell'ultima verifica” (se applicabile) nella pagina di stato o nella documentazione e permettere agli utenti di ripetere la verifica.
  • DEVE: evitare formule “permanenti/assolute”; usare un linguaggio coerente con l'ambito delle prove, come “la scansione indica che è abilitato/conforme”.
  • DOVREBBE: quando cambiano policy di sicurezza critiche (ad es. inasprimento della CSP, aggiornamenti TLS), registrarlo nel changelog e collegare gli ID delle affermazioni pertinenti.

12.8 ID delle affermazioni correlati (riservato)

Questo capitolo tratta di “prove di terze parti e principi di corrispondenza”. Gli ID delle affermazioni corrispondenti sono mantenuti nell' Appendice: elenco principale degli ID delle affermazioni, che resta l'unica fonte autorevole.