Il nostro firewall blocca attualmente il traffico QUIC (UDP 443) che sembra essere abilitato di default in Google Chrome. È sicuro abilitare il QUIC o devo aspettare che venga implementato in tutti i principali browser?
Capisco che sia stato sviluppato come una sperimentazione da parte di Google al fine di migliorare le prestazioni delle applicazioni web.
QUIC di per sé non è più pericoloso di TCP, UDP, HTTP .... Ciò che importa è il contenuto trasferito con il protocollo. Se si utilizza il firewall solo come un semplice filtro di pacchetti e non si esegue alcuna ispezione del contenuto (ad esempio malware, filtro URL ecc.), Non importa molto se si abilita o meno QUIC. Se invece il tuo firewall viene utilizzato per analizzare il traffico di HTTP (s), potrebbe essere una buona idea eliminare il traffico QUIC in modo che il browser continui a utilizzare HTTP (s) e non ignorare l'analisi con un protocollo che il firewall non capisce.
"Gli attacchi possono essere usati per negare ai clienti l'accesso a qualsiasi applicazione di scelta e causare ai server di sprecare risorse!" A partire da ora, non particolarmente pericoloso. Tutto ciò che viene indicato di seguito può solo causare negazioni del servizio (connessione) e connessioni interrotte, questo è tutto.
QUIC utilizza 0-rtt (riavvio sessione / ticket) che è potenzialmente vulnerabile agli attacchi di riproduzione, come indicato qui ; così fa tls; tls 0-rtt può essere disabilitato in firefox, anche se non sono sicuro che ci siano opzioni per disabilitare 0-rtt per quic nei browser in questo momento. Dopo un po 'di ulteriori scavi, anche quic 1-rtt (handshake di connessione) è / era (2015 al momento dell'articolo) vulnerabile anche al MITM, Server Config Replay Attacks, Source-Address Token Replay Attacks e Packet Manipulation Attacks:
We target the Chromium implementation of QUIC7 in our attacks, as this is the canonical implementation. Our attacks were developed in python using the scapy library. We summarize our attacks, their properties, and impacts in Table 1. Replay Attacks. Server Config Replay Attack. To conduct this attack, an attacker must first collect a copy of the target server’s scfg. This can be done either by actively establishing a connection to the server or by passively listening for a client to attempt a connection. In either case, the server’s scfg can be readily collected from a full, 1-RTT QUIC connection handshake. Once the attacker has scfg, he waits for the target client to attempt to start a connection. When the attacker sees a c hello message from the client, he can respond with a spoofed srejectmessage using the collected scfg and randomly generated stk and sno values:
SRC link
Ricorda che l'articolo è stato scritto nel 2015 e il protocollo è probabilmente evoluto da allora.
Sono d'accordo con Steffan sul fatto che QUIC non è più pericoloso di TCP o UDP o HTTP o di qualsiasi altro protocollo di comunicazione. Penso che per il tuo caso d'uso ciò che conta davvero è il trasferimento dei dati attraverso il protocollo.
Come ha detto Steffan, in realtà dipende dal firewall e dalle preoccupazioni che stai cercando di affrontare usando quel firewall. Fare una modellizzazione delle minacce informali (quale tipo di attacchi / attori delle minacce sono la tua principale preoccupazione? Che tipo di risorse stai cercando di proteggere usando il firewall?) E condividere alcune delle tue preoccupazioni specifiche nelle domande relative a QUIC potrebbe effettivamente aiutare gli altri per fornire risposte certe.
Parlando di sicurezza del protocollo stesso - Non sono esperto in sicurezza del protocollo, ma sulla base della mia comprensione, tutti i protocolli di comunicazione passano attraverso un esame accurato da ricercatori ed esperti di sicurezza prima di essere dichiarato come standard (di solito attraverso RFC). A questo proposito, QUIC non è maturo come TCP o UDP o HTTP, ma sono state fatte molte ricerche sulla sicurezza attorno al protocollo.
La ricerca più pertinente che sono riuscito a recuperare è Quanto è sicuro e veloce QUIC? Analisi della sicurezza e delle prestazioni disponibili - di Lychev et al . Gli autori introducono fondamentalmente un modello di sicurezza per l'analisi di protocolli basati sulle prestazioni come il QUIC e dimostrano che QUIC soddisfa la loro definizione in base a presupposti ragionevoli sui blocchi costitutivi del protocollo.