Vor zwei Jahren hatte ich mich projektbedingt mit diesem Thema beschäftigen dürfen – umso neugieriger war ich auf den Mitschnitt dieses Vortags. tl;dr: Anschau-Empfehlung für alle, die irgendwie etwas mit SSL und Performance-Themen zu tun haben (insbesondere Webmaster), eine sehr schöne Zusammenfassung der verschiedenen Aspekte.

Is TLS Fast Yet?

Dazugehörige Ressourcen: Die Folien sowie die Webseite „Is TLS Fast Yet?“, auf der nochmals alle Fakten zusammengetragen sind (einschließlich der Möglichkeit zum Mitmachen und Ergänzen in Form von Pull Requests auf github).

Kurz zusammengefaßt die Punkte des Talks:

• Auf modernen Standard-CPUs ist die symmetrische Krypto vom Aufwand her vernachlässigbar, lediglich der Handshake zu Beginn ist „spürbar“. Bei geeigneter Konfiguration gibt es aber keinen Grund, auf spezielle Krypto-Hardware zurückzugreifen.
• Erste Optimierung: Session Resume (am besten mittels Client-seitigen Session Tickets, um den serverseitigen Speicherbedarf pro Session zu reduzieren).
• Abschalten von TLS-Compression: Abgesehen von Angriffsmöglichkeiten wie z.B. CRIME vergrößert TLS den Speicherbedarf pro Verbindung erheblich. Sinnvoller ist es, den höherliegenden Protokollen (z.B. http) die Komression zu überlassen.
• Konfiguration der Key Rotaiton überprüfen. Ist leider per Default bei vielen Servern nicht korrekt konfiguriert, und ohne Key Rotation keine Perfect Forward Secrecy.
• Ich ergänze an dieser Stelle: Durch Wahl geeigneter Verfahren aus der SSL Suite erreicht man neben Perfect Forward Secrecy auch unter Umständen kleinere Zertifikate, was sich in Datenmenge und Übertragungsdauer bemerkbar macht.
• Das für das Überprüfen der Zertifikatsgültigkeit verwendete OCSP ist ein Quell steter Schmerzen. Wenn möglich: OCSP Stapling verwenden und die Revocation Info durch den Server mit ausliefern.
• Die Größe des TCP Congestion Window kann performancetechnisch beißen, wenn die Zertifiaktskette so groß ist, daß zwischenrein auf ein ACK gewartet werden muß.
• Perfect Forward Secrecy zusammen mit ALPN ermöglichen False Starts (hier wird die erste Payload mit letztem Handshake-Block mitgesendet).

Bei unterschiedlichen Webservern (und dort auch innerhalb von Versionen) gibt es wohl erhebliche Unterschiede, es lohnt sich, die Tabellen zum Vortrag anzusehen – und am Ende selbst zu testen und nachzumessen.

Ein sauber optimiertes OpenSSL schafft den erstrebten „One Roundtrip Handshake“ und benötigt pro Connection ca. 100 kb RAM. Googles intern verwendet SSL-Bibliothek reduziert den Speicherbedarf bis auf 10 kb, vielleicht dürfen wir hoffen, diese Optimierungen in Zukunft zumindest auch in BoringSSL, Goolges OpenSSL-Fork, wiederzufinden.