E2EE Live

Willy Push

Live

In nessun punto il server sa cosa c’è scritto

Questo è il punto centrale della demo. Tre passaggi da tenere ben presenti:

Cosa invii tu al server: solo i dati già cifrati (enc, ephem per ogni destinatario). Nessun titolo, nessun corpo in chiaro. Il server non riceve mai il testo del messaggio.
Cosa fa il server: non decifra, non apre, non legge il contenuto. Riceve i dati cifrati e li inoltra a Google (FCM) così come sono. In nessun momento il server può sapere cosa c’è scritto nella notifica.
Cosa invia il server a Google: esattamente gli stessi enc ed ephem. Il server è un semplice “inoltro”: prende il pacchetto cifrato e lo passa a FCM. Solo il dispositivo destinatario, con la sua chiave privata, può decifrare e vedere titolo e messaggio.

Nel log vedi esplicitamente “Cosa invii TU al server”, “Il server NON decifra” e “Cosa invia il server a Google”: sono le righe STEP 4 che confermano che il server non sa mai cosa c’è scritto.

5 punti da tenere a mente

Il server non manda mai il testo in chiaro a Google. Titolo e messaggio vengono cifrati prima dell’invio; in rete va solo il pacchetto illeggibile.
Google (FCM) trasporta solo dati cifrati. Non può leggere il contenuto della notifica: riceve e recapita solo enc, ephem e il marcatore e2ee.
Le righe in viola nel log sono i dati cifrati reali (anteprima di enc ed ephem). Sono esattamente ciò che il server invia a FCM e che FCM recapita al dispositivo.
Il dispositivo ha una chiave privata che resta solo lì (nel browser o nel telefono). Senza quella chiave nessuno può decifrare il messaggio; per questo solo il destinatario vede il contenuto.
Il testo torna leggibile solo alla fine — quando il dispositivo decifra con la sua chiave privata e mostra la notifica. Fino a quel momento il contenuto è cifrato ovunque.

Log in tempo reale

[ISCRIZIONE] registrazione · [DISISCRIZIONE] rimozione · STEP 1-6 push · push_token public_key enc ephem = stessi codici per colore

Aggiornamento live — Log controllato alle —

In attesa di eventi.
Apri push-test-cifrato?debug=1, invia una push cifrata (o ricevila sul dispositivo): qui appariranno i 6 passaggi (STEP 1…6) in ordine cronologico e in aggiornamento live.

Apri push-test-cifrato (debug)

Come usare questa pagina: Tieni aperta un’altra tab con push-test-cifrato?debug=1 e invia una push cifrata. Qui il log si aggiorna in tempo reale (circa ogni 400 ms) e vedrai tutti i passaggi in ordine cronologico: cosa ha inviato il dispositivo al server (STEP 1), il messaggio in chiaro (STEP 2), la cifratura e l’invio a Google (STEP 3-4), il recapito da FCM al dispositivo (STEP 5) e la decifratura con il contenuto finale (STEP 6). I dati nel log sono reali (scritti da pannello e da dispositivo), non una simulazione.

I 6 passaggi nel log (cosa significa ogni STEP)

STEP 1 — Dispositivo → Server. Il destinatario, in fase di registrazione, ha inviato al server la propria chiave pubblica. Il server la conserva solo per poter inviare messaggi cifrati a quel dispositivo; non può decifrare nulla.
STEP 2 — Messaggio in chiaro. Titolo e corpo della notifica così come li ha scritti chi invia. In questo momento il contenuto è ancora leggibile; subito dopo verrà cifrato (STEP 3).
STEP 3 — Cifratura. Il sistema genera per ogni destinatario i dati cifrati (enc) e la chiave effimera (ephem). Il messaggio in chiaro non esce mai: viene trasformato in un blocco illeggibile.
STEP 4 — Cosa invii al server, cosa fa il server, cosa invia a Google. Tu invii al server solo enc ed ephem (nessun titolo/corpo in chiaro). Il server non decifra mai: riceve i dati cifrati e li inoltra a FCM così come sono. In nessun punto il server sa cosa c’è scritto. Le righe in viola sono l’anteprima di enc/ephem (ciò che tu mandi al server e che il server manda a Google).
STEP 5 — Google → Dispositivo. FCM ha recapitato al dispositivo lo stesso payload cifrato (enc, ephem). Il dispositivo lo riceve ancora illeggibile; per leggerlo userà la chiave privata (STEP 6).
STEP 6 — Decifratura e contenuto. Il dispositivo usa la chiave privata (solo sua) e trasforma enc/ephem in titolo e corpo leggibili. Qui compare il messaggio in chiaro; la notifica viene mostrata all’utente.

La demo riordina sempre i passaggi in ordine logico (1→2→3→4→5→6). Anche se i dati arrivano in ordine diverso (es. il dispositivo riceve prima che il pannello finisca di scrivere), qui vedi sempre STEP 1, 2, 3, 4, 5, 6 in fila.

Il percorso del messaggio (in sintesi)

Lo stesso flusso che vedi nel log, raccontato in una riga per fase. Ogni punto corrisponde a uno STEP nel log sopra.

1. Il dispositivo ha già inviato al server la chiave pubblica (registrazione). Il server la tiene solo per inviare dati cifrati.
2. Il messaggio viene preparato in chiaro (titolo e corpo). È l’ultimo momento in cui il contenuto è leggibile prima della cifratura.
3. Il contenuto viene cifrato: si generano enc ed ephem. Da qui in poi nessuno in mezzo può leggere il messaggio.
4. Tu invii al server solo enc/ephem. Il server non decifra: inoltra gli stessi dati a Google (FCM). In nessun punto il server sa cosa c’è scritto.
5. FCM recapita lo stesso payload al dispositivo. Il dispositivo lo riceve ancora cifrato.
6. Il dispositivo usa la chiave privata (solo sua) e decifra: titolo e messaggio tornano leggibili e la notifica viene mostrata.

Chi vede cosa (e chi no)

In ogni passaggio chi è coinvolto vede solo ciò che gli serve; il contenuto della notifica in chiaro non esce mai dal mittente e dal destinatario.

Chi invia (pannello mittente): vede il messaggio in chiaro (STEP 2), poi lo cifra e invia al server solo enc/ephem. Non vede le chiavi private dei destinatari.
Il server: riceve e inoltra solo enc, ephem, e2ee. Non decifra nulla e non conosce titolo o corpo della notifica.
Google (FCM): vede solo il pacchetto cifrato da recapitare (enc, ephem, e2ee). Non può leggere il contenuto.
Rete e eventuali intermediari: vedono solo dati cifrati (stringhe illeggibili); nessun titolo o messaggio in chiaro.
Il dispositivo destinatario: è l’unico che possiede la chiave privata e può decifrare. Solo qui il messaggio torna in chiaro (STEP 6) e la notifica viene mostrata.

Come leggere il log (riferimento rapido)

[ISCRIZIONE] — Quando un dispositivo si iscrive (clic su «Genera chiavi e attiva notifiche»): nel log vedi l’avvio (generazione chiavi), il token FCM, tutto il payload inviato al server (domain, push_token, public_key, firebase_project_id) e la conferma. Nel log push_token e public_key (e poi enc/ephem) sono sempre evidenziati con lo stesso colore: così si capisce subito che tutto è cifratura e nessuno vede mai nulla in chiaro. La chiave privata non viene mai inviata; solo la public_key va al server.

[DISISCRIZIONE] — Quando un dispositivo viene rimosso (pulsante «Rimuovi»): nel log vedi l’invio a delete_encrypted_device.php (domain, token_hash) e la conferma di rimozione. Da quel momento quel device non riceve più push cifrate.

STEP 1 e STEP 2 — Ti dicono cosa ha messo a disposizione il dispositivo (la chiave pubblica) e qual è il messaggio in chiaro prima di cifrarlo. Da STEP 3 in poi quel testo non è più visibile a nessuno tranne che al destinatario alla fine.

STEP 3 e STEP 4 — Cifratura e invio (righe in viola). Nel log compaiono esplicitamente: «Cosa invii TU al server» (solo enc/ephem, nessun testo in chiaro), «Il server NON decifra» (inoltra senza mai leggere), «Cosa invia il server a Google» (gli stessi dati cifrati). Così è chiaro che in nessun punto il server sa cosa c’è scritto. enc è il messaggio già cifrato; ephem è la chiave effimera. Le righe in viola sono l’anteprima di enc/ephem (ciò che tu mandi al server e che il server manda a FCM).

STEP 5 e STEP 6 — Ricezione e decifratura. STEP 5 conferma che FCM ha recapitato il payload cifrato al dispositivo. STEP 6 è il momento in cui il dispositivo usa la chiave privata e trasforma enc/ephem in titolo e corpo leggibili; nel log vedi anche il contenuto in chiaro (title="...", body="..."). Solo qui il messaggio torna leggibile.

In una frase: il messaggio parte in chiaro (STEP 2), viene cifrato (STEP 3-4), viaggia cifrato (STEP 4→5), e torna in chiaro solo sul dispositivo (STEP 6). È la crittografia end-to-end (E2EE): server e Google non vedono mai il contenuto.