Redazione RHC : 2 Maggio 2024 15:20
Alcuni utenti di Google Chrome hanno segnalato problemi di connessione a siti, server e firewall da quando Chrome è stato rilasciato la scorsa settimana. La nuova versione del browser presenta il nuovo motore di incapsulamento resistente ai quanti X25519Kyber768 abilitato per impostazione predefinita.
Google ha iniziato a testare un nuovo meccanismo di incapsulamento della chiave TLS resistente ai quanti lo scorso agosto e nell’ultima versione di Chrome lo ha abilitato per tutti gli utenti del browser. La nuova versione di Chrome utilizza l’algoritmo di accordo chiave Kyber768 per le connessioni TLS 1.3 e QUIC per proteggere il traffico TLS di Chrome da futuri attacchi post-quantici.
“Dopo diversi mesi di esperimenti di compatibilità e prestazioni, stiamo lanciando lo scambio di chiavi TLS ibrido post-quantistico per desktop in Chrome 124”, ha scritto il team di sicurezza di Chrome. “Ciò proteggerà il traffico degli utenti dagli attacchi chiamati – archivia ora, e decritta in seguito – in cui un futuro computer quantistico sarà in grado di decrittografare il traffico crittografato registrato oggi.”
La NIS2 è complessa da capire?
Non perdere tempo, segui l'anteprima gratuita del corso che stiamo preparando.Accedi quindi alla nostra Academy e segui l'anteprima del corso della durata di 30 minuti per comprendere i contenuti esclusivi che tratteremo nel corso.per ulteriori informazioni, scrivici ad [email protected] oppure scrivici su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Gli attacchi “Store now, decrypt later” coinvolgono gli aggressori che raccolgono dati crittografati e li archiviano per un uso futuro, fino a quando non saranno disponibili nuovi metodi di decrittografia come i computer quantistici (o le chiavi di crittografia).
Per proteggersi da tali attacchi futuri, le aziende (tra cui Apple, Signal e Google) hanno già iniziato ad aggiungere la crittografia resistente ai quanti al proprio stack per impedire l’utilizzo di tali tattiche.
Tuttavia, dal rilascio di Google Chrome 124 e Microsoft Edge 124, alcune applicazioni Web, firewall e server interrompono le connessioni dopo l’handshake TLS. Il problema riguarda anche hardware di sicurezza, firewall, middleware di rete e altri dispositivi di rete di vari fornitori (ad esempio Fortinet, SonicWall, Palo Alto Networks, AWS).
“Sembra che questo rompa l’handshake TLS per i server che non sanno cosa fare con i dati extra nel messaggio di saluto del client”, afferma un amministratore interessato. “Stesso problema dalla versione 124 Edge, qualcosa sembra andare storto con la decrittografia SSL sul mio PaloAlto”, ha scritto un altro amministratore.
Sembra che questi errori non siano dovuti a un bug di Chrome, ma al fatto che i server web non possono implementare correttamente TLS e non sono in grado di elaborare l’aumento dei messaggi richiesti per la protezione quantistica. Finiscono per rifiutare le connessioni utilizzando l’algoritmo Kyber768 resistente ai quanti invece di passare alla crittografia classica se X25519Kyber768 non è supportato.
Gli amministratori dei siti sono incoraggiati a testare i propri server attivando manualmente la nuova funzionalità in Google Chrome 124 utilizzando il flag chrome://flags/#enable-tls13-kyber. Una volta abilitata la funzione, gli amministratori possono connettersi ai propri server e verificare se ciò sta attivando un errore “ERR_CONNECTION_RESET”.
Gli amministratori possono anche disabilitare questa funzionalità utilizzando la policy PostQuantumKeyAgreementEnabled o contattando i fornitori per ottenere aggiornamenti per l’hardware che non è pronto per il post-quantum. Microsoft ha già pubblicato istruzioni dettagliate su come gestire questa funzionalità utilizzando i criteri di gruppo Edge.
Tuttavia, i giornalisti notano che a lungo termine sarà necessaria una protezione post-quantistica per TLS e che la politica aziendale di Chrome per disabilitare questa funzionalità verrà rimossa in futuro.