Che cosa proteggiamo, e che cosa no

Che cosa significa «end-to-end» qui

Che il testo viene cifrato sul dispositivo di chi lo scrive e decifrato su quello di chi lo legge, e che la chiave non passa mai da noi. Non è una dichiarazione di intenti: è una proprietà misurata a ogni collaudo, e la misura viene a sua volta messa alla prova rompendo il codice apposta per vedere se se ne accorge. Il procedimento è descritto qui.

Non significa che il servizio sia inattaccabile. Significa che l’attacco piu’ ovvio — leggere il database, nostro o rubato — non porta a nulla. I limiti sono elencati più sotto, e uno di essi riguarda proprio la consegna del codice via web.

Scelte crittografiche

Le soglie di entropia, e da dove vengono

Il generatore dichiara un numero di bit e un giudizio in parole. Le soglie sono queste, e sono opinabili come tutte le soglie: le scriviamo perché un’etichetta senza il numero accanto è folclore.

Il numero vale per il procedimento, non per la sequenza: dice quante possibilità equivalenti doveva scartare chi volesse indovinarla. Vale perché la scelta è uniforme e non l’ha fatta una persona: una password inventata da un essere umano ha molta meno entropia di quanta ne suggerisca la sua lunghezza.

Difese sul server

• Consumo atomico. La lettura e il decremento del contatore sono una sola operazione sul database: due richieste simultanee non possono ottenere entrambe l’ultima lettura disponibile.
• Il caricamento della pagina non consuma. Il segreto esce solo da un’azione esplicita.
• Limite di frequenza prima del lavoro costoso. Il limitatore agisce prima che il corpo della richiesta venga letto e prima che il database venga aperto.
• Limite di dimensione che chiude, non apre. Una richiesta che non dichiara la propria lunghezza, o che la dichiara oltre il massimo, viene rifiutata prima di essere letta.
• Content-Security-Policy senza unsafe-inline. Nel sito non esiste un solo script in linea, un solo stile in linea, un solo attributo onclick. Non è una dichiarazione: è un vincolo sul codice, verificato a ogni collaudo.
• Nessun dato sensibile nei registri. Il registro delle richieste conosce il modello del percorso (/s/:id), mai l’identificativo; delle eccezioni registra il tipo, mai il messaggio; l’indirizzo IP non viene raccolto affatto.
• Scadenza e cancellazione. Un segreto scaduto smette di essere consegnabile immediatamente, perché la condizione è nella stessa query che lo consegnerebbe; la riga viene poi rimossa da una pulizia periodica che non fa nulla se non c’è nulla da fare.

I limiti, dichiarati

Questi non sono ipotesi remote: sono le condizioni in cui il servizio non protegge, e vanno conosciute prima di usarlo.

• Chi ha il collegamento ha il segreto. La chiave sta nel collegamento: mandarlo su un canale insicuro equivale a mandare il segreto su quel canale. La distruzione alla prima lettura serve a rendere un’intercettazione visibile, non a impedirla.
• Un server compromesso può servire codice diverso. È la debolezza strutturale di ogni crittografia end-to-end consegnata via web: chi apre un collegamento dopo una compromissione potrebbe ricevere una pagina che, oltre a decifrare, spedisce la chiave altrove. I segreti già consegnati restano illeggibili — la compromissione non è retroattiva — ma questo limite non è eliminabile senza consegnare il codice fuori dal web.
• Il tuo dispositivo è fuori dal nostro perimetro. Un’estensione ostile, un registratore di tastiera o uno schermo condiviso vedono il testo in chiaro prima che venga cifrato.
• Chi riceve il segreto ne fa ciò che vuole. Non esiste un modo di impedirgli di copiarlo, e non fingiamo che esista.
• I metadati restano visibili a noi. Sappiamo che un segreto esiste, quanto è grande e quando è stato creato. Non sappiamo che cosa contiene, chi l’ha scritto e a chi è destinato.

Segnalare un problema

Se trovi un difetto di sicurezza, scrivi a info@aresrls.com descrivendo il comportamento osservato e come riprodurlo. Non pubblicare il dettaglio prima di averci dato modo di correggere.