IETF spezifiziert Richtlinien für den Einsatz von Verschlüsselung
Das Gremium für Internet-Standards dokumentiert Richtlinien für den sinnvollen Einsatz der Transportverschlüsselung TLS. Der RFC 7525 enthält gute Anleitungen, Tipps und Hinweise auf Fallstricke für jeden, der Verschlüsselung selbst einrichtet.
Die Empfehlungen für den sicheren Einsatz von TLS und DTLS beschreiben minutiös den Stand der Technik und geben sinnvolle Vorgaben zu Verfahren, Optionen und Schlüssellängen. Die Herausgeber der Internet-Standards geben dabei einen Ausblick auf wünschenswerte Funktionen und endlich abzuschneidende Zöpfe, ohne dabei die Praxis aus den Augen zu verlieren.
So ächtet der RFC 7525 unter anderem SSLv3, RC4 und für den Export verkrüppelte Verschlüsselung mit weniger als 112 Bit Schlüssellänge. Deren Einsatz verbietet das Dokument mit dem formalisierten "MUST NOT" der IETF-Standards. Von der Verwendung bedenklicher und eigentlich nicht mehr erwünschter Verfahren wie 3DES für die Verschlüsselung und RSA für den Schlüsselaustausch rät die IETF mit dem schwächeren SHOULD NOT deutlich ab.
Bei den von grundsätzlichen Sicherheitsproblemen geplagten, veralteten Standards wie TLS 1.0 und 1.1 geht der RFC noch einen Schritt weiter und gestattet als einzige Ausnahme die Situation, in der kein besseres Verfahren zur Verfügung steht. Insbesondere bei älteren Windows-Systemen ist das leider häufig noch der Fall. Die IETF beweist damit mehr Gespür für die Praxis als etwa das Bundesamt für Sicherheit in der Informationstechnik (BSI), das in seiner Technischen Richtlinie TR-02102-2 kurzerhand schreibt: "TLS 1.0 darf nicht mehr eingesetzt werden." (siehe: Das BSI und der Elfenbeinturm).
Doch der RFC ergeht sich nicht nur in Verboten sondern bewirbt und fordert auch den Einsatz erwünschter Techniken und Optionen. So schreibt er die Unterstützung und sogar Bevorzugung von Forward Secrecy via Diffie-Hellman vor (MUST); als Minimum sollten dabei 2048-Bit-Schlüssel zum Einsatz kommen (SHOULD). Auch hier notiert die IETF praxisnah, dass viele Clients DH nur bis maximal 1024 Bit unterstützen. Als konkrete Cipher-Suites, die jeder TLS-Endpunkt beherrschen sollte, empfiehlt die IETF:
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Alle Verfahren setzen AES im Galois Counter Mode (GCM) ein. Dabei handelt es sich um symmetrische Verschlüsselung, die die Integritätssicherung gleich mit einbezieht (Authenticated Encryption). Das beseitigt das grundlegende Design-Problem der falschen Reihenfolge dieser Operationen bei SSL/TLS (MAC-then-encrypt); AES/GCM ist allerdings erst mit TLS 1.2 verfügbar.
Darüber hinaus fordert die IETF die Unterstützung von HSTS sowohl auf Client- als auch auf Server-Seite ein. Damit kann dann ein Server einem Client signalisieren, dass er in Zukunft alle seine Dienste auch TLS-gesichert nutzen kann. Ein HSTS-fähiger Browser wie die aktuellen Versionen von Firefox, Chrome und IE wird dann etwa http-URLs selbstständig in sichere https-URLs umwandeln. Und schließlich enthält der RRC auch bereits einen Verweis auf das kommende TLS 1.3, das einige Aktualisierungen erfordern wird.
Insgesamt bündelt der RFC tatsächlich realitätsnahe Best Practices ohne dabei das Ziel, die aktuelle Situation deutlich zu verbessern, aus den Augen zu verlieren. Er soll, wie die Autoren erklären, ein unteres Limit aber keine obere Grenze für den sicheren Einsatz von Transportverschlüsselung definieren. Jeder der selbst Systeme einrichtet oder entwickelt, die Verschlüsselung einsetzen, sollte einen Blick darauf werfen. (ju)
