nginx und TLS Kompression

  • Guten Morgen


    Ich bin mich aktuell mit Themen wie DANE, DNSSEC und Co am beschäftigen, da ich dies mal in einem produktiven System einsetzen möchte. Unteranderme habe ich dafür folgenden Test gefunden: https://en.internet.nl


    Dort wird auch ein Punkt "HTTP compression" angezeigt, welcher eigentlich überal als Fehlerhaft angezeigt wird. Selbst Seiten wie google.de haben diese aktiv. Ich habe dazu reichtlich wenig gefunden. Es stand das nginx glaub ab 10.3 das Standardmässig deaktiviert hat. Ich setze 1.15.8 ein.


    Gerne würde ich wissen, ob ich dies irgendwie prüfen kann oder an dem Test einfach was "faul" ist. Ich denke Seiten wie google oder auch netcup müsste das doch sicher korrekt haben. Aber auch dort wird es "bemängelt"


    Gruss


    Oliver

  • Schnell nach GZIP Test gegoogelt. Lt. einer anderen Seite wird google.de komprimiert. Deine Testseite bestätigt das Ergebnis.

    Danke. Ich habe gzip (gzip off;) auch bereits in der nginx.conf sowie den Host Dateien deaktiviert und wird dort trotzdem bemängelt. Aber wenn ich mich so umschaue haben die meisten Seiten GZIP aktiviert

  • Ich kann das für einen aktuellen Nginx (mainline) ebenfalls bestätigten.

    In einem vHost die Compression aktiv konfiguriert, wird angemäkelt, in einem vHost ohne explizite Konfiguration kommt keine Meldung.

    Abgesehen davon gibt es für beide vHosts einen Score von 100% ....

  • In einem vHost die Compression aktiv konfiguriert, wird angemäkelt, in einem vHost ohne explizite Konfiguration kommt keine Meldung.

    Hast du einfach direkt in der Seitenkonfiguration gzip off;? Ich habe dies mal in der nginx.conf sowie der seiten Konfiguration und bekomme es bemängelt.


    Habe es jetzt auch mal gelöscht aber habe das selbe.

    Abgesehen davon gibt es für beide vHosts einen Score von 100% ....

    Gut zu wissen. Wäre aber natürlich noch Interessant weshalb dies bemängelt wird.

  • Ich include solche Konfigurationen immer nur. Für den mit Compression getesteten vHost schaut die Konfiguration so aus.

    Code
    1. gzip on;
    2. gzip_vary on;
    3. gzip_comp_level 4;
    4. gzip_min_length 256;
    5. gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    6. gzip_disable "MSIE [1-6]\.";
    7. gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;


    Es wird bemängelt wegen einer potentiellen Angriffsfläche, welche sich BREACH nennt. Eigentlich sollte das aber mittlerweile behoben sein?

  • Nur einmal zur Klarstellung:


    • BREACH ist ein Angriff auf HTTP-Kompression. Da kann man TLS-Kompression an- und ausschalten wie man will. Es ändert sich nichts. Konkret ist BREACH ein Angriff auf gzip/DEFLATE. Wie es mit dem neueren Brotli aussieht – keine Ahnung, aber nach kurzer Recherche scheint auch Brotli (teils auch als „br“ abgekürzt) angreifbar. Was man gegen BREACH machen kann, steht direkt auf der Webseite des Angriffs: http://www.breachattack.com/#mitigations
    • CRIME (CVE-2012-4929) ist ein vorheriger Angriff auf TLS-Kompression, aber nur beim Zusammenspiel von SPDY (heute weiterentwickelt als HTTP/2 im Einsatz) und HTTPS nachgewiesen worden. Hier wird allgemein empfohlen, TLS-Kompression immer client- und serverseitig zu deaktivieren (ist heute oft der Standard).