it-swarm.com.de

Können Sie gzip über SSL verwenden? Und Verbindung: Keep-Alive-Header

Ich bewerte die Front-End-Leistung einer sicheren (SSL) Web-App hier bei der Arbeit und frage mich, ob es möglich ist, Textdateien (HTML/CSS/Javascript) über SSL zu komprimieren. Ich habe ein bisschen gegoogelt, aber nichts spezielles zu SSL gefunden. Wenn es möglich ist, sind es sogar die zusätzlichen CPU-Zyklen wert, da Antworten ebenfalls verschlüsselt werden? Würde das Komprimieren der Antworten die Leistung beeinträchtigen?

Außerdem möchte ich sicherstellen, dass wir die SSL-Verbindung aufrechterhalten, sodass wir nicht immer und immer wieder SSL-Handshakes durchführen. Ich sehe keine Connection: Keep-Alive in den Response Headern. Ich sehe Keep-Alive: 115 in den request -Heatern, aber das hält die Verbindung nur für 115 Millisekunden am Leben (scheint, als würde der App-Server die Verbindung schließen, nachdem eine einzige Anfrage verarbeitet wurde) Server, der Antwort Header für das Sitzungsinaktivitätszeitlimit festgelegt wird?

Ich verstehe, dass Browser keine SSL-Inhalte auf dem Datenträger zwischenspeichern, sodass wir bei nachfolgenden Besuchen dieselben Dateien immer wieder bereitstellen, auch wenn sich nichts geändert hat. Die wichtigsten Optimierungsempfehlungen sind die Verringerung der Anzahl von HTTP-Anforderungen, die Minifizierung, das Verschieben von Skripts nach unten, die Bildoptimierung, das mögliche Domain-Sharding (obwohl die Kosten eines weiteren SSL-Handshakes abgewogen werden müssen), Dinge dieser Art.

31
magenta

Ja, die Komprimierung kann über SSL verwendet werden. Es findet statt, bevor die Daten verschlüsselt werden, um langsame Verbindungen zu unterstützen. Es sei darauf hingewiesen, dass dies eine schlechte Idee ist: dies öffnet auch eine Sicherheitsanfälligkeit.

Nach dem ersten Handshake ist SSL weniger Aufwand, als viele denken * - selbst wenn der Client sich wieder verbindet, gibt es einen Mechanismus, um vorhandene Sitzungen ohne Neuverhandlung der Schlüssel fortzusetzen, was zu weniger CPU-Auslastung und weniger Roundtrips führt.

Lastverteiler können jedoch mit dem Fortsetzungsmechanismus verschrauben: Wenn Anforderungen zwischen Servern abwechseln, sind mehr vollständige Handshakes erforderlich, was eine spürbare Auswirkung haben kann (~ einige hundert ms pro Anforderung). Konfigurieren Sie Ihren Load Balancer so, dass alle Anforderungen von derselben IP-Adresse an denselben App-Server weitergeleitet werden.

Welchen App-Server verwendest du? Wenn es nicht für die Verwendung von Keep-Alive konfiguriert werden kann, komprimieren Sie Dateien und so weiter, und ziehen Sie in Betracht, es hinter einen Reverse-Proxy zu setzen, der can ist. Der verknüpfte Artikel von HttpWatchSupport enthält einige nützliche Hinweise.

(* SSL-Hardwarehersteller sagen Dinge wie "bis zu 5-mal mehr CPU"), aber einige chaps von Google gaben an, dass Gmail bei der Standardeinstellung von SSL nur ~ 1% CPU-Last ausmachte.

28
SimonJ
  1. Sie sollten wahrscheinlich niemals die TLS-Komprimierung verwenden. Einige Benutzeragenten (zumindest Chrome) werden es trotzdem deaktivieren. 

  2. Sie können die HTTP-Komprimierung selektiv verwenden

  3. Sie können immer minimieren

  4. Sprechen wir auch über das Caching

Ich gehe davon aus, dass Sie eine HTTPS Everywhere-Website verwenden.

Szenario:

  1. Statischer Inhalt wie css oder js:

    • Verwenden Sie die HTTP-Komprimierung
    • Minifizierung verwenden
    • Lange Cache-Zeit (wie ein Jahr)
    • etag ist nur bedingt nützlich (wegen langem Cache)
    • Fügen Sie eine Art Versionsnummer in die URL in Ihrem HTML-Code ein, die auf dieses Asset verweist, damit Sie das Cache-Problem lösen können
  2. HTML-Inhalt mit ZERO-vertraulichen Informationen (wie eine Seite über uns):

    • Verwenden Sie die HTTP-Komprimierung
    • Verwenden Sie die HTML-Minifizierung
    • Verwenden Sie eine kurze Cache-Periode
    • Verwenden Sie etag
  3. HTML-Inhalt mit JEDEN sensiblen Informationen (wie ein CSRF-Token oder eine Bankkontonummer):

    • KEINE HTTP-Komprimierung
    • Verwenden Sie die HTML-Minifizierung
    • Cache-Control: no-store, must-revalidate
    • etag hat hier keinen Sinn (aufgrund von Revalidierung)
    • eine Logik zum Umleiten der Seite nach dem Sitzungszeitlimit (unter Berücksichtigung mehrerer Registerkarten). Wenn jemand auf die Zurück-Schaltfläche des Browsers drückt, werden die vertraulichen Informationen aufgrund des Cache-Headers nicht angezeigt. 

Sie können die HTTP-Komprimierung mit vertraulichen Daten IF verwenden:

  1. Sie geben niemals Benutzereingaben in der Antwort zurück (haben ein Suchfeld? Verwenden Sie keine HTTP-Komprimierung).
  2. Oder Sie geben Benutzereingaben in die Antwort zurück, füllen die Antwort jedoch zufällig auf
17
Neil McGuigan

Durch die Komprimierung mit SSL können Sie Schwachstellen wie BREACH, CRIME oder andere ausgewählte Klartextangriffe ausnutzen.

Sie sollten die Komprimierung deaktivieren, da SSL/TLS derzeit keine Möglichkeit hat, Oracle-Angriffe dieser Länge abzuschwächen.

11
Rodney

Zu Ihrer ersten Frage: SSL arbeitet auf einer anderen Ebene als die Komprimierung. In gewissem Sinne sind dies zwei Merkmale eines Webservers, die zusammenarbeiten können und sich nicht überschneiden. Ja, durch die Aktivierung der Komprimierung verwenden Sie mehr CPU auf Ihrem Server, haben jedoch weniger ausgehenden Datenverkehr. Es ist also eher ein Kompromiss.

Zu Ihrer zweiten Frage: Das Verhalten von Keep-Alive hängt wirklich von der HTTP-Version ab. Sie könnten statische Inhalte auf einen Nicht-SSL-Server verschieben (möglicherweise Bilder, Filme, Audio usw.).

0
Zepplock

Ja, die gzip-Komprimierung und Keep-Alive können mit HTTPS/SSL verwendet werden. Browser können auch SSL-Inhalte zwischenspeichern.

Dieser Blogbeitrag enthält weitere Informationen zum Optimieren einer Website für HTTPS/SSL:

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

0