Så jag har de här få kompressionsdirektiven på http-nivå i nginx:
gzip on; gzip_http_version 1.1; gzip_vary on; Jag läste att detta bör undvikas på grund av CRIME / BREACH-attack, är detta korrekt?
Jag läste att detta bör undvikas på grund av CRIME / BREACH-attack, är detta korrekt?
Det beror på.
CRIME-attacken är redan mildras i nuvarande webbläsare genom att de inte använder TLS-komprimering och har speciell hantering av sammanhang i HTTP / 2.0. BREACH är bara relevant i komprimering av HTTP-nivå om följande två villkor gäller samtidigt (för att citera http://www.breachattack.com/):
Om ingen eller endast dessa gäller kan du använda gzip utan att påverkas av BREACH. Det betyder att du är säker på att använda den för statiska sidor eller för sidor som inte innehåller hemligheter som CSRF-tokens (det är hemligheterna som angriparen vill extrahera).
Även angriparen behöver flera förfrågningar till samma webbplats och måste kunna se hur storleken på den överförda datan ändras. Så om dina hemligheter ändras hela tiden eller om webbplatsen ändras (som att lägga till slumpmässig stoppning med en slumpmässig storlek) kan angriparen inte använda BREACH. Se även Försvara mot BREACH Attack.
gzipping av SSL-krypterad data eliminerar i viss mån fördelarna med SSL. Ja, gzipping ALL -innehåll kan öppna din webbplats för BREACH-sårbarheten.
Men du kan fortfarande lägga till några resurser för gzipping. Till exempel kan offentliga bilder gippas eller offentliga dokument i allmänhet. Du bör dock noga överväga om du vill "sabotera" ditt eget SSL-skydd.
Detta kan också vara värt att läsa: https://stackoverflow.com/questions/2767211/can-you -use-gzip-over-ssl-and-connection-keep-alive-headers
EDIT: Jag vill lägga till, att med SPDY kan du uppnå en liknande komprimering genom komprimerade rubriker och en förkortad förhandling / omförhandling av nycklarna. Du kan också "förkomprimera" ofta använda resurser (men det är inte exklusivt för SPDY).
Hur SSL / TLS och Gzipping fungerar är att det kartlägger data för att minska storleken på ett paket på ett förutsägbart och repeterbart sätt som sedan kan ångras. Detta är inte ett problem om sidorna är statisk och inga polletter eller kakor skickas med sig. Det beror på att den begärda informationen från webbplatsen ständigt kommer att vara densamma och paketstorleken ändras inte. Men med en dynamisk sida ändras alltid innehållet förutom en liten bit i CSRF och användardata. Med den informationen kan de injicera data i en begäran eller organ. Detta är ett problem eftersom det gör att de kan ändra innehållet i paketet och se hur komprimeringen kartläggs. De har så småningom tillgång till vissa saker i paketet inklusive cookies, eventuella lösenord eller användarinformation, Cross Site Begär förfalskningstoken och allt annat som har skickats.
På grund av detta rekommenderas det inte att använda TLS / SSL för dynamisk datakomprimering av känslig data, eftersom paketet så småningom kan brytas.