7. Considerazioni di sicurezza
7. Considerazioni di sicurezza
Le considerazioni su privacy e sicurezza di [RFC8030] si applicano tutte all'uso di questo meccanismo.
La sezione Security Considerations di [RFC8188] descrive i limiti della codifica di contenuto. In particolare, nessun campo di intestazione HTTP è protetto dalla codifica di contenuto. Un user agent MUST considerare i campi di intestazione HTTP come provenienti dal push service.
Sebbene i campi di intestazione possano essere necessari per elaborare correttamente una risposta HTTP, non sono richiesti per il corretto funzionamento del protocollo. Un'applicazione sull'user agent che usa informazioni dalle intestazioni per modificare l'elaborazione di un messaggio push è esposta al rischio di attacco da parte del push service.
La tempistica e la lunghezza della comunicazione non possono essere nascoste al push service. Un osservatore esterno potrebbe vedere messaggi mescolati, ma il push service vede quale application server parla con quale user agent e quale subscription è usata. Inoltre, la lunghezza dei messaggi potrebbe essere rivelata a meno che non si usi il padding fornito dalla codifica di contenuto per offuscare la lunghezza.
L'user agent e l'applicazione MUST verificare che la chiave pubblica ricevuta sia sulla curva P-256. La mancata validazione può consentire a un attaccante di estrarre una chiave privata. Le procedure di validazione appropriate sono definite nella Sezione 4.3.7 di [X9.62] e, in alternativa, nella Sezione 5.6.2.3 di [KEYAGREEMENT]. Il processo consta di tre passi:
-
Verificare che Y non sia il punto all'infinito (O),
-
Verificare che per Y = (x, y) entrambi gli interi siano nell'intervallo corretto,
-
Assicurarsi che (x, y) sia una soluzione corretta dell'equazione della curva ellittica.
Per queste curve, gli implementatori non devono verificare l'appartenenza al sottogruppo corretto.
Qualora questo schema di crittografia dovesse essere sostituito, si potrebbe definire una nuova codifica di contenuto. Per una distribuzione progressiva del nuovo schema, l'user agent può esporre le codifiche di contenuto supportate. Il parametro « supportedContentEncodings » della Push API [API] è un esempio.