Il protocollo Web Push

Abbiamo visto come una libreria può essere utilizzata per attivare messaggi push, ma cosa fanno esattamente queste librerie?

Eseguono richieste di rete assicurandosi che abbiano il formato corretto. La specifica che definisce questa richiesta di rete è il protocollo Web Push.

Questa sezione descrive in che modo il server può identificarsi con le chiavi del server delle applicazioni e come vengono inviati il payload criptato e i dati associati.

Questo non è un aspetto piacevole delle notifiche push web e non sono un esperto di crittografia, ma esaminiamo ogni parte, perché è utile sapere cosa fanno queste librerie internamente.

Chiavi del server delle applicazioni

Quando abboniamo un utente, trasmettiamo un applicationServerKey. Questa chiave viene trasmessa al servizio push e utilizzata per verificare che l'applicazione che ha eseguito la registrazione dell'utente sia anche l'applicazione che attiva i messaggi push.

Quando attiviamo un messaggio push, inviamo un insieme di intestazioni che consentono al servizio push di autenticare l'applicazione. (Questo è definito dalla specifica VAPID.)

Che cosa significa tutto questo e cosa succede esattamente? Ecco i passaggi eseguiti per l'autenticazione del server delle applicazioni:

1. Il server delle applicazioni firma alcune informazioni JSON con la chiave privata dell'applicazione.
2. Queste informazioni firmate vengono inviate al servizio push come intestazione in una richiesta POST.
3. Il servizio push utilizza la chiave pubblica memorizzata ricevuta da pushManager.subscribe() per verificare che le informazioni ricevute siano firmate dalla chiave privata relativa alla chiave pubblica. Ricorda: la chiave pubblica è il applicationServerKey passato nella chiamata di iscrizione.
4. Se le informazioni firmate sono valide, il servizio push invia il messaggio push all'utente.

Di seguito è riportato un esempio di questo flusso di informazioni. (Nota la legenda in basso a sinistra per indicare le chiavi pubblica e privata.)

Le "informazioni firmate" aggiunte a un'intestazione nella richiesta sono un token web JSON.

JSON Web Token

Un token web JSON (o JWT in breve) è un modo per inviare un messaggio a una terza parte in modo che il destinatario possa convalidare chi lo ha inviato.

Quando una terza parte riceve un messaggio, deve ottenere la chiave pubblica del mittente e utilizzarla per convalidare la firma del JWT. Se la firma è valida, il JWT deve essere stato firmato con la chiave privata corrispondente, quindi deve provenire dal mittente previsto.

Su jwt.io/ sono disponibili numerose librerie che possono eseguire la firma per te. Ti consiglio di utilizzarle quando possibile. Per completezza, vediamo come creare manualmente un JWT firmato.

Notifiche push web e JWT firmati

Un JWT firmato è solo una stringa, anche se può essere considerato come tre stringhe unite da punti.

La prima e la seconda stringa (le informazioni JWT e i dati JWT) sono parti di JSON con codifica Base64, il che significa che sono leggibili pubblicamente.

La prima stringa contiene informazioni sul JWT stesso, indicando l'algoritmo utilizzato per creare la firma.

Le informazioni JWT per le notifiche push web devono contenere i seguenti dati:

{
  "typ": "JWT",
  "alg": "ES256"
}

La seconda stringa è JWT Data. Fornisce informazioni sul mittente del JWT, sul destinatario e sulla durata della validità.

Per le notifiche push web, i dati avrebbero questo formato:

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:example@web-push-book.org"
}

Il valore aud è il "pubblico", ovvero a chi è destinato il JWT. Per le notifiche push web, il pubblico è il servizio push, quindi lo impostiamo sull'origine del servizio push.

Il valore exp è la scadenza del JWT, il che impedisce agli spioni di riutilizzare un JWT se lo intercettano. La scadenza è un timestamp in secondi e non deve superare le 24 ore.

In Node.js la scadenza viene impostata utilizzando:

Math.floor(Date.now() / 1000) + 12 * 60 * 60;

Sono 12 ore anziché 24 per evitare problemi con le differenze di orologio tra l'applicazione di invio e il servizio push.

Infine, il valore sub deve essere un URL o un indirizzo email mailto. In questo modo, se un servizio push deve contattare il mittente, può trovare i dati di contatto nel JWT. Ecco perché la libreria web-push aveva bisogno di un indirizzo email.

Come le informazioni JWT, i dati JWT sono codificati come stringa base64 sicura per gli URL.

La terza stringa, la firma, è il risultato dell'unione delle prime due stringhe (le informazioni JWT e i dati JWT) con un carattere punto, che chiameremo "token non firmato", e della sua firma.

La procedura di firma richiede la crittografia del "token non firmato" utilizzando ES256. Secondo la specifica JWT, ES256 è l'abbreviazione di "ECDSA che utilizza la curva P-256 e l'algoritmo hash SHA-256". Utilizzando Web Crypto puoi creare la firma nel seguente modo:

// Utility function for UTF-8 encoding a string to an ArrayBuffer.
const utf8Encoder = new TextEncoder('utf-8');

// The unsigned token is the concatenation of the URL-safe base64 encoded
// header and body.
const unsignedToken = .....;

// Sign the |unsignedToken| using ES256 (SHA-256 over ECDSA).
const key = {
  kty: 'EC',
  crv: 'P-256',
  x: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(1, 33)),
  y: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(33, 65)),
  d: window.uint8ArrayToBase64Url(applicationServerKeys.privateKey),
};

// Sign the |unsignedToken| with the server's private key to generate
// the signature.
return crypto.subtle.importKey('jwk', key, {
  name: 'ECDSA', namedCurve: 'P-256',
}, true, ['sign'])
.then((key) => {
  return crypto.subtle.sign({
    name: 'ECDSA',
    hash: {
      name: 'SHA-256',
    },
  }, key, utf8Encoder.encode(unsignedToken));
})
.then((signature) => {
  console.log('Signature: ', signature);
});

Un servizio push può convalidare un JWT utilizzando la chiave pubblica del server delle applicazioni per decriptare la firma e assicurarsi che la stringa decriptata sia uguale al "token non firmato" (ovvero le prime due stringhe del JWT).

Il JWT firmato (ovvero tutte e tre le stringhe unite da punti) viene inviato al servizio push web come intestazione Authorization con WebPush anteposto, come segue:

Authorization: 'WebPush [JWT Info].[JWT Data].[Signature]';

Il protocollo Web Push indica anche che la chiave del server delle applicazioni pubblico deve essere inviata nell'intestazione Crypto-Key come stringa con codifica base64 sicura per URL con p256ecdsa= anteposto.

Crypto-Key: p256ecdsa=[URL Safe Base64 Public Application Server Key]

Crittografia del payload

Vediamo ora come inviare un payload con un messaggio push in modo che quando la nostra app web riceve un messaggio push, possa accedere ai dati che riceve.

Una domanda comune che sorge per chi ha utilizzato altri servizi push è perché il payload push web deve essere criptato? Con le app native, i messaggi push possono inviare dati come testo normale.

Uno dei vantaggi delle notifiche push web è che, poiché tutti i servizi push utilizzano la stessa API (il protocollo push web), gli sviluppatori non devono preoccuparsi di chi sia il servizio push. Possiamo fare una richiesta nel formato corretto e aspettarci che venga inviato un messaggio push. Lo svantaggio è che gli sviluppatori potrebbero inviare messaggi a un servizio push non affidabile. Crittografando il payload, un servizio push non può leggere i dati inviati. Solo il browser può decriptare le informazioni. In questo modo, i dati dell'utente vengono protetti.

La crittografia del payload è definita nella specifica di crittografia dei messaggi.

Prima di esaminare i passaggi specifici per criptare il payload di un messaggio push, dobbiamo esaminare alcune tecniche che verranno utilizzate durante la procedura di criptaggio. (Un ringraziamento speciale a Mat Scales per il suo eccellente articolo sulla crittografia push).

ECDH e HKDF

Sia ECDH che HKDF vengono utilizzati durante il processo di crittografia e offrono vantaggi per lo scopo di criptare le informazioni.

ECDH: scambio di chiavi Diffie-Hellman a curva ellittica

Immagina di avere due persone che vogliono condividere informazioni, Alice e Bob. Sia Alice che Bruno hanno le proprie chiavi pubbliche e private. Alice e Bob condividono le rispettive chiavi pubbliche.

La proprietà utile delle chiavi generate con ECDH è che Alice può utilizzare la sua chiave privata e la chiave pubblica di Bob per creare il valore segreto "X". Bruno può fare lo stesso, prendendo la sua chiave privata e la chiave pubblica di Alice per creare in modo indipendente lo stesso valore "X". In questo modo "X" diventa un segreto condiviso e Alice e Bob hanno dovuto condividere solo la loro chiave pubblica. Ora Bob e Alice possono utilizzare "X" per criptare e decriptare i messaggi tra loro.

Per quanto mi risulta, ECDH definisce le proprietà delle curve che consentono questa "funzionalità" di creare un segreto condiviso "X".

Questa è una spiegazione generale di ECDH. Se vuoi saperne di più, ti consiglio di guardare un video più dettagliato sulla panoramica di ECDH.

In termini di codice, la maggior parte dei linguaggi / piattaforme include librerie che semplificano la generazione di queste chiavi.

Nel nodo, eseguiamo le seguenti operazioni:

const keyCurve = crypto.createECDH('prime256v1');
keyCurve.generateKeys();

const publicKey = keyCurve.getPublicKey();
const privateKey = keyCurve.getPrivateKey();

HKDF: funzione di derivazione della chiave basata su HMAC

Wikipedia fornisce una descrizione succinta di HKDF:

HKDF è una funzione di derivazione delle chiavi basata su HMAC che trasforma qualsiasi materiale della chiave debole in materiale della chiave crittograficamente sicuro. Può essere utilizzato, ad esempio, per convertire i secret condivisi scambiati con Diffie-Hellman in materiale della chiave adatto all'uso per la crittografia, il controllo dell'integrità o l'autenticazione.

In sostanza, HKDF prende un input non particolarmente sicuro e lo rende più sicuro.

La specifica che definisce questa crittografia richiede l'utilizzo di SHA-256 come algoritmo hash e le chiavi risultanti per HKDF in web push non devono superare i 256 bit (32 byte).

Nel nodo, questa operazione può essere implementata nel seguente modo:

// Simplified HKDF, returning keys up to 32 bytes long
function hkdf(salt, ikm, info, length) {
  // Extract
  const keyHmac = crypto.createHmac('sha256', salt);
  keyHmac.update(ikm);
  const key = keyHmac.digest();

  // Expand
  const infoHmac = crypto.createHmac('sha256', key);
  infoHmac.update(info);

  // A one byte long buffer containing only 0x01
  const ONE_BUFFER = new Buffer(1).fill(1);
  infoHmac.update(ONE_BUFFER);

  return infoHmac.digest().slice(0, length);
}

Un ringraziamento speciale a Mat Scale per l'articolo che ha fornito questo codice di esempio.

che copre approssimativamente ECDH e HKDF.

ECDH è un modo sicuro per condividere le chiavi pubbliche e generare un segreto condiviso. HKDF è un modo per prendere materiale non sicuro e renderlo sicuro.

Verrà utilizzato durante la crittografia del payload. Ora vediamo cosa prendiamo come input e come viene criptato.

Input

Quando vogliamo inviare un messaggio push a un utente con un payload, abbiamo bisogno di tre input:

1. Il payload stesso.
2. Il secret auth da PushSubscription.
3. La chiave p256dh di PushSubscription.

Abbiamo notato che i valori auth e p256dh vengono recuperati da un PushSubscription, ma per un rapido promemoria, per un abbonamento abbiamo bisogno di questi valori:

subscription.toJSON().keys.auth;
subscription.toJSON().keys.p256dh;

subscription.getKey('auth');
subscription.getKey('p256dh');

Il valore auth deve essere trattato come un segreto e non deve essere condiviso al di fuori dell'applicazione.

La chiave p256dh è una chiave pubblica, a volte indicata come chiave pubblica client. Qui ci riferiremo a p256dh come chiave pubblica dell'abbonamento. La chiave pubblica dell'abbonamento viene generata dal browser. Il browser manterrà segreta la chiave privata e la utilizzerà per decriptare il payload.

Questi tre valori, auth, p256dh e payload, sono necessari come input e il risultato del processo di crittografia sarà il payload criptato, un valore salt e una chiave pubblica utilizzata solo per criptare i dati.

Salt

Il sale deve essere composto da 16 byte di dati casuali. In Node.js, per creare un sale, procedi nel seguente modo:

const salt = crypto.randomBytes(16);

Chiavi pubbliche / private

Le chiavi pubblica e privata devono essere generate utilizzando una curva ellittica P-256, che in Node si fa così:

const localKeysCurve = crypto.createECDH('prime256v1');
localKeysCurve.generateKeys();

const localPublicKey = localKeysCurve.getPublicKey();
const localPrivateKey = localKeysCurve.getPrivateKey();

Ci riferiremo a queste chiavi come "chiavi locali". Vengono utilizzate solo per la crittografia e non hanno nulla a che fare con le chiavi del server delle applicazioni.

Con il payload, il segreto di autenticazione e la chiave pubblica dell'abbonamento come input e con un nuovo sale e un nuovo insieme di chiavi locali, siamo pronti per eseguire la crittografia.

Secret condiviso

Il primo passaggio consiste nel creare un segreto condiviso utilizzando la chiave pubblica dell'abbonamento e la nostra nuova chiave privata (ricordi la spiegazione di ECDH con Alice e Bob? Proprio così.

const sharedSecret = localKeysCurve.computeSecret(
  subscription.keys.p256dh,
  'base64',
);

Viene utilizzato nel passaggio successivo per calcolare la chiave pseudo casuale (PRK).

Chiave pseudo-casuale

La chiave pseudo casuale (PRK) è la combinazione del secret di autenticazione della sottoscrizione push e del secret condiviso che abbiamo appena creato.

const authEncBuff = new Buffer('Content-Encoding: auth\0', 'utf8');
const prk = hkdf(subscription.keys.auth, sharedSecret, authEncBuff, 32);

Ti starai chiedendo a cosa serve la stringa Content-Encoding: auth\0. In breve, non ha uno scopo chiaro, anche se i browser potrebbero decriptare un messaggio in arrivo e cercare la codifica dei contenuti prevista. \0 aggiunge un byte con valore 0 alla fine del buffer. Questo è previsto dai browser che decriptano il messaggio e si aspettano tanti byte per la codifica dei contenuti, seguiti da un byte con valore 0, seguito dai dati criptati.

La nostra chiave pseudo casuale esegue semplicemente l'autenticazione, il secret condiviso e un'informazione di codifica tramite HKDF (ovvero, la rende crittograficamente più sicura).

Contesto

Il "contesto" è un insieme di byte utilizzato per calcolare due valori in un secondo momento nel browser di crittografia. Si tratta essenzialmente di un array di byte contenente la chiave pubblica dell'abbonamento e la chiave pubblica locale.

const keyLabel = new Buffer('P-256\0', 'utf8');

// Convert subscription public key into a buffer.
const subscriptionPubKey = new Buffer(subscription.keys.p256dh, 'base64');

const subscriptionPubKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = subscriptionPubKey.length;

const localPublicKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = localPublicKey.length;

const contextBuffer = Buffer.concat([
  keyLabel,
  subscriptionPubKeyLength.buffer,
  subscriptionPubKey,
  localPublicKeyLength.buffer,
  localPublicKey,
]);

Il buffer di contesto finale è un'etichetta, il numero di byte nella chiave pubblica di sottoscrizione, seguito dalla chiave stessa, poi il numero di byte della chiave pubblica locale, seguito dalla chiave stessa.

Con questo valore di contesto possiamo utilizzarlo per creare un nonce e una chiave di crittografia dei contenuti (CEK).

Chiave di crittografia dei contenuti e nonce

Un nonce è un valore che impedisce gli attacchi di replay, in quanto deve essere utilizzato una sola volta.

La chiave di crittografia dei contenuti (CEK) è la chiave che verrà utilizzata per criptare il payload.

Innanzitutto, dobbiamo creare i byte di dati per il nonce e la CEK, ovvero una semplice stringa di codifica dei contenuti seguita dal buffer di contesto che abbiamo appena calcolato:

const nonceEncBuffer = new Buffer('Content-Encoding: nonce\0', 'utf8');
const nonceInfo = Buffer.concat([nonceEncBuffer, contextBuffer]);

const cekEncBuffer = new Buffer('Content-Encoding: aesgcm\0');
const cekInfo = Buffer.concat([cekEncBuffer, contextBuffer]);

Queste informazioni vengono elaborate tramite HKDF combinando il sale e la PRK con nonceInfo e cekInfo:

// The nonce should be 12 bytes long
const nonce = hkdf(salt, prk, nonceInfo, 12);

// The CEK should be 16 bytes long
const contentEncryptionKey = hkdf(salt, prk, cekInfo, 16);

In questo modo, otteniamo il nonce e la chiave di crittografia dei contenuti.

Esegui la crittografia

Ora che abbiamo la chiave di crittografia dei contenuti, possiamo criptare il payload.

Creiamo una crittografia AES128 utilizzando la chiave di crittografia dei contenuti come chiave e il nonce come vettore di inizializzazione.

In Node, questa operazione viene eseguita nel seguente modo:

const cipher = crypto.createCipheriv(
  'id-aes128-GCM',
  contentEncryptionKey,
  nonce,
);

Prima di criptare il payload, dobbiamo definire la quantità di padding da aggiungere all'inizio del payload. Il motivo per cui vogliamo aggiungere il padding è che impedisce il rischio che gli intercettatori possano determinare i "tipi" di messaggi in base alle dimensioni del payload.

Devi aggiungere due byte di padding per indicare la lunghezza di qualsiasi padding aggiuntivo.

Ad esempio, se non hai aggiunto alcun riempimento, avrai due byte con valore 0, ovvero non esiste alcun riempimento, dopo questi due byte leggerai il payload. Se hai aggiunto 5 byte di padding, i primi due byte avranno un valore di 5, quindi il consumatore leggerà altri cinque byte e poi inizierà a leggere il payload.

const padding = new Buffer(2 + paddingLength);
// The buffer must be only zeros, except the length
padding.fill(0);
padding.writeUInt16BE(paddingLength, 0);

Quindi eseguiamo il padding e il payload tramite questa cifra.

const result = cipher.update(Buffer.concat(padding, payload));
cipher.final();

// Append the auth tag to the result -
// https://nodejs.org/api/crypto.html#crypto_cipher_getauthtag
const encryptedPayload = Buffer.concat([result, cipher.getAuthTag()]);

Ora abbiamo il payload criptato. Benissimo!

Non resta che determinare come questo payload viene inviato al servizio push.

Intestazioni e corpo del payload criptati

Per inviare questo payload criptato al servizio push, dobbiamo definire alcune intestazioni diverse nella nostra richiesta POST.

Intestazione di crittografia

L'intestazione "Encryption" (Crittografia) deve contenere il salt utilizzato per criptare il payload.

Il sale di 16 byte deve essere codificato in base64 sicuro per URL e aggiunto all'intestazione di crittografia, come segue:

Encryption: salt=[URL Safe Base64 Encoded Salt]

Intestazione Crypto-Key

Abbiamo notato che l'intestazione Crypto-Key viene utilizzata nella sezione "Chiavi del server delle applicazioni" per contenere la chiave pubblica del server delle applicazioni.

Questa intestazione viene utilizzata anche per condividere la chiave pubblica locale utilizzata per criptare il payload.

L'intestazione risultante ha il seguente aspetto:

Crypto-Key: dh=[URL Safe Base64 Encoded Local Public Key String]; p256ecdsa=[URL Safe Base64 Encoded Public Application Server Key]

Intestazioni di tipo, lunghezza e codifica dei contenuti

L'intestazione Content-Length indica il numero di byte nel payload criptato. Le intestazioni "Content-Type" e "Content-Encoding" sono valori fissi. Questo è mostrato di seguito.

Content-Length: [Number of Bytes in Encrypted Payload]
Content-Type: 'application/octet-stream'
Content-Encoding: 'aesgcm'

Una volta impostate queste intestazioni, dobbiamo inviare il payload criptato come corpo della richiesta. Tieni presente che Content-Type è impostato su application/octet-stream. perché il payload criptato deve essere inviato come flusso di byte.

In NodeJS, questa operazione si esegue nel seguente modo:

const pushRequest = https.request(httpsOptions, function(pushResponse) {
pushRequest.write(encryptedPayload);
pushRequest.end();

Altre intestazioni?

Abbiamo trattato le intestazioni utilizzate per JWT / chiavi del server delle applicazioni (ovvero come identificare l'applicazione con il servizio push) e le intestazioni utilizzate per inviare un payload criptato.

Esistono intestazioni aggiuntive che i servizi push utilizzano per modificare il comportamento dei messaggi inviati. Alcune di queste intestazioni sono obbligatorie, mentre altre sono facoltative.

Intestazione TTL

Obbligatorio

TTL (o durata TTL) è un numero intero che specifica il numero di secondi per cui vuoi che il messaggio push rimanga nel servizio push prima di essere recapitato. Quando TTL scade, il messaggio viene rimosso dalla coda del servizio push e non viene recapitato.

TTL: [Time to live in seconds]

Se imposti un TTL pari a zero, il servizio push tenterà di inviare il messaggio immediatamente, ma se il dispositivo non è raggiungibile, il messaggio verrà immediatamente eliminato dalla coda del servizio push.

Tecnicamente, un servizio push può ridurre il TTL di un messaggio push se lo desidera. Puoi verificare se si è verificato questo problema esaminando l'intestazione TTL nella risposta di un servizio push.

Argomento

Facoltativo

Gli argomenti sono stringhe che possono essere utilizzate per sostituire un messaggio in attesa con un nuovo messaggio se hanno nomi di argomenti corrispondenti.

Ciò è utile in scenari in cui vengono inviati più messaggi mentre un dispositivo è offline e vuoi che un utente veda solo l'ultimo messaggio quando il dispositivo viene acceso.

Urgenza

Facoltativo

L'urgenza indica al servizio push quanto sia importante un messaggio per l'utente. Questo può essere utilizzato dal servizio push per contribuire a preservare la durata della batteria del dispositivo di un utente attivandosi solo per i messaggi importanti quando la batteria è in esaurimento.

Il valore dell'intestazione è definito come mostrato di seguito. Il valore predefinito è normal.

Urgency: [very-low | low | normal | high]

Tutto insieme

Se hai altre domande su come funziona il tutto, puoi sempre vedere come le librerie attivano i messaggi push nell'organizzazione web-push-libs.

Una volta che hai un payload criptato e le intestazioni sopra indicate, devi solo effettuare una richiesta POST a endpoint in un PushSubscription.

Quindi, cosa facciamo con la risposta a questa richiesta POST?

Risposta dal servizio push

Una volta effettuata una richiesta a un servizio push, devi controllare il codice di stato della risposta per sapere se la richiesta è andata a buon fine o meno.

Per saperne di più sui codici di stato HTTP, puoi anche leggere lo standard Web Push (RFC8030).

Passaggi successivi

• Panoramica delle notifiche push web
• Come funziona Push
• Iscrizione di un utente
• Esperienza utente relativa alle autorizzazioni
• Invio di messaggi con le librerie push web
• Protocollo web push
• Gestione degli eventi push
• Visualizzazione di una notifica
• Comportamento delle notifiche
• Pattern di notifica comuni
• Domande frequenti sulle notifiche push
• Problemi comuni e segnalazione di bug

Code lab

• Creare un client di notifiche push
• Crea un server di notifiche push