Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

Perfect Forward Secrecy

Eine Möglichkeit, die manche der TLS-Algorithmen bieten, ist ein sogenannter Schlüsselaustausch. Dabei wird gewährleistet, dass der eigentliche Schlüssel für die Datenübertragung nie über die Leitung übertragen wird. Nach der Datenübertragung wird dieser temporäre Schlüssel vernichtet. Der Vorteil: Selbst wenn ein Angreifer die Verbindung belauscht und später in den Besitz des privaten Schlüssels gelangt, kann er den Inhalt nicht entschlüsseln. Diese Eigenschaft heißt Perfect Forward Secrecy. Sie ist generell wünschenswert und das gängigste Verfahren hierfür ist ein Diffie-Hellman-Schlüsselaustausch.

Ärgerlich: TLS bietet diesen zwar an, aber der Apache-Webserver ermöglicht es nicht, die Parameterlänge für den Schlüsselaustausch zu definieren. Als Standard ist eine Länge von 1024 Bit vorgegeben. Eigentlich zu wenig: Bei Verfahren, die wie Diffie-Hellman auf dem diskreten Logarithmus-Problem basieren, sollten Schlüssellängen von 1024 Bit vermieden und mindestens 2048 Bit eingesetzt werden.

Alternativ bietet TLS noch einen Schlüsselaustausch über Diffie-Hellman in elliptischen Kurven. Bei dieser Methode gelten schon deutlich kürzere Schlüssellängen als sicher.

Was ist angesichts der Schwachstellen zu tun?

Zu betonen ist, dass die Wahrscheinlichkeit, dass die vorgestellten Attacken zu Problemen in realen Anwendungen führen, gering ist. Doch die Autoren des Lucky-Thirteen-Angriffs sagen explizit, dass sie mit weiteren Überraschungen bei CBC rechnen. Auch die Autoren der Attacke auf RC4 gehen davon aus, dass es verbesserte Angriffsmethoden geben wird.

Langfristig wünschenswert wäre es daher vermutlich, CBC komplett zu verbannen. Der wahre Zoo an Verschlüsselungsmodi, die von TLS unterstützt werden, schrumpft damit drastisch zusammen. In TLSv1.1 und allen früheren Versionen nutzten sämtliche Blockchiffreverfahren CBC. Alle Verfahren, die 3DES, IDEA oder CAMELLIA einsetzen, fallen damit weg.

Aus Gründen der Abwärtskompatibilität ist es heute in der Regel ausgeschlossen, nur auf TLSv1.2 zu setzen (siehe Abbildung 3). Übrig bleibt lediglich die ebenfalls problematische Stromchiffre RC4.

Abbildung 3: google.de über https – die Verbindung nutzt RC4 mit TLSv1.1, TLSv1.2 unterstützt Chrome noch nicht.

In TLSv1.2 wird nur noch die AES-Verschlüsselung unterstützt – und zwar sowohl im (problematischen) CBC-Modus als auch im moderneren GCM (Galois-/Counter-Mode). Diese werden ebenfalls mit und ohne Perfect Forward Secrecy angeboten.

Im Optimalfall schaltet man alles außer den GCM-Algorithmen ab. Das funktioniert aber nur bei Anwendungen, bei denen man Kontrolle über sämtliche Clients hat und weiß, dass sie TLSv1.2 unterstützen. Der pragmatische Kompromiss: Vorläufig weiter auf die CBC-basierten Verfahren setzen und dafür sorgen, dass die verwendete SSL-Bibliothek – in den meisten Fällen OpenSSL – nur in der aktuellen Version mit allen Sicherheits-Updates eingesetzt wird.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019