Quindi ho queste poche direttive di compressione a livello http in nginx:
gzip on;
gzip_http_version 1.1;
gzip_vary on;
Ho letto che questo dovrebbe essere evitato a causa di un attacco CRIME / BREACH, è corretto?
Quindi ho queste poche direttive di compressione a livello http in nginx:
gzip on;
gzip_http_version 1.1;
gzip_vary on;
Ho letto che questo dovrebbe essere evitato a causa di un attacco CRIME / BREACH, è corretto?
I read that this should be avoided because of CRIME/BREACH attack, is this correct?
Dipende.
L'attacco CRIME è già stato mitigato nei browser correnti dal momento che non utilizzano la compressione TLS e hanno una gestione speciale dei contesti in HTTP / 2.0. BREACH è rilevante solo nel contesto della compressione del livello HTTP se le due condizioni seguenti si applicano entrambe contemporaneamente (per citare il link ):
Se nessuno o solo uno di questi si applica, è possibile utilizzare gzip senza essere interessati da BREACH. Ciò significa che sei sicuro di usarlo per qualsiasi pagina statica o per qualsiasi pagina che non includa segreti come i token CSRF (sono i segreti che l'aggressore vuole estrarre).
Anche l'autore dell'attacco ha bisogno di più richieste allo stesso sito e deve essere in grado di vedere come cambia la dimensione dei dati trasferiti. Quindi se i tuoi segreti cambiano continuamente o se il sito cambia (come con l'aggiunta di un riempimento casuale con una dimensione casuale) l'autore dell'attacco non sarà in grado di utilizzare BREACH. Vedi anche Difesa contro l'attacco BREACH .
L'utilizzo di dati crittografati con SSL elimina i vantaggi del protocollo SSL in una certa misura. Sì, il ALL contenuto di Gzipping potrebbe aprire il tuo sito web fino alla vulnerabilità di BREACH.
Ma puoi ancora aggiungere alcune risorse per gzipping. Ad esempio, le immagini pubbliche potrebbero essere compresse con gzip o documenti pubblici in generale. Tuttavia dovresti considerare attentamente se vuoi "sabotare" la tua SSL-Protection.
Potrebbe anche valere la pena di leggere questo: link
EDIT: Vorrei aggiungere che usando SPDY si può ottenere una compressione simile attraverso le intestazioni compresse e una negoziazione / rinegoziazione abbreviata delle chiavi. Inoltre è possibile "pre" -comprimere le risorse utilizzate di frequente (ma ciò non è esclusivo di SPDY).
Il modo in cui SSL / TLS e Gzipping funziona è che mappa i dati per ridurre le dimensioni di un pacchetto in un modo prevedibile e ripetibile che può essere annullato. Questo non è un problema se le pagine sono statico e non hanno token o cookie inviati con loro. Questo perché i dati richiesti dal sito saranno sempre gli stessi e quindi la dimensione del pacchetto non cambierà. Tuttavia con una pagina dinamica, il contenuto è sempre cambiato tranne che per un po 'nel CSRF e nei dati dell'utente. Utilizzando tali informazioni possono iniettare dati in una richiesta o corpo. Questo è un problema perché consente loro di modificare il contenuto del pacchetto e vedere come la compressione esegue il mapping. Alla fine hanno accesso a determinate cose nel pacchetto inclusi cookie, password o informazioni utente, Cross Site Richiedi token contraffattori e qualsiasi altra cosa che è stata inviata. Per questo motivo si raccomanda di non utilizzare TLS / SSL per la compressione dinamica dei dati sensoriali, perché alla fine il pacchetto può essere Violato.
Leggi altre domande sui tag compression tls crime beast gzip