In den letzten Jahren hat die Unterstützung von Transportverschlüsselung bei Webseiten stark zugenommen. Dies hat sicherlich eine Vielzahl von Gründen: Die Webseitenbetreiber werden stärker für IT-Sicherheit sensibilisiert und werden selbst tätig, die Webseitenbesucher werden durch Hinweise im Browser stärker auf unsichere Webseiten hingewiesen und passen ihr Verhalt entsprechend an und die Verfügbarkeit von Verschlüsselung stellt auch ein gewisses Qualitätsmerkmal dar, dass z.B. von Suchmaschinen beim Ranking der Suchergebnisse berücksichtigt wird.

Für die Webseitenbetreiber ist es aber mit dem Angebot einer Verschlüsselung nicht getan. Denn gemäß § 13 Abs. 7 Telemediengesetze (TMG) muss die Verschlüsselung auch dem „Stand der Technik“ entsprechen. Daher stellt sich natürlich die Frage, was denn bei Transportverschlüsselung dem „Stand der Technik“ entspricht?

Welche TLS Version sollte genutzt werden?

Transportverschlüsselung für Webseitenbetreiber bedeutet den Einsatz von Transport Layer Security (TLS). Aktuell wird nur noch TLS 1.2 als Stand der Technik eingestuft. Der Einsatz von TLS 1.2 wurde zwar schon längere Zeit grundsätzlich empfohlen, aber bis vor kurzem galt auch noch der Einsatz der älteren TLS 1.0 und 1.1 als akzeptabel.  Aber da diese beiden Protokollversionen mit SHA-1 auf einen unsicheren Hash-Algorithmus zur Signatur angewiesen sind, sind diese Versionen nun nicht mehr einsetzbar. Erst recht nicht einsetzbar sind die älteren Secure Socket Layer (SSL)-Protokolle wie SSLv3. In diesen Protokollen gibt es bekannte und ausnutzbare Schwachstellen (siehe hier), die Protokolle auch nicht mehr von den aktuellen Browsern unterstützt.

Allerdings ist nicht nur die eingesetzte Protokollversion bei TLS wichtig, sondern auch die verwendeten kryptografischen Algorithmen spielen eine entscheidende Rolle. Denn TLS ist nur das Protokoll, über das Webseite und Browser kommunizieren, um z.B. den zu verwendenden Verschlüsselungsalgorithmus auszuhandeln. Mit diesem Algorithmus erfolgt dann die eigentliche Absicherung der ausgetauschten Daten.

In der konkreten Umsetzung bedeutet dies, dass der Client bei der Anfrage zur TLS-Verbindung eine Liste der unterstützen kryptografischen Algorithmen mitsendet. Von diesen wählt der Server dann einen passenden Algorithmus aus, mit dem der Datenaustausch verschlüsselt werden soll. Wie sicher die Daten übertragen werden, ist also von den durch Webserver und Browser unterstützten Algorithmen abhängig und eine allgemeine Aussage kann bloß auf Basis der Information „TLS 1.2 wird verwendet“ nicht getroffen werden.

Für eine möglichst sichere Übertragung der Daten sollten kryptografisch starke Algorithmen unterstützt werden. Der aktuelle Entwurf zu TLS 1.3 schreibt z.B. mindesten die Umsetzung von TLS_AES_128_GCM_SHA256 vor und empfiehlt u.a. die Implementierung von TLS_AES_256_GCM_SHA384. Das bedeutet, es muss mindestens AES-128 und SHA-256 zum Einsatz kommen und am besten werden AES-256 mit SHA-384 oder andere gleichwertige kryptografische Algorithmen unterstützt. Leider ist es nicht ausreichend, nur den Einsatz von starken kryptografischen Algorithmen zu ermöglichen. Es gibt auch Angriffe, bei denen versucht wird, den Einsatz möglichst schwacher bzw. geknackter Algorithmen auszuhandeln. Daher sollten Webserver so konfiguriert werden, dass schwache Algorithmen gar nicht angeboten und angenommen werden.

Natürlich ist nicht jedem bewusst, welche Algorithmen nun als stark oder schwach eingestuft werden. Als Abhilfe kann z.B. die Technische Richtlinie TR-02102-2 des BSI genutzt werden. In der Richtlinie werden Empfehlung zum Einsatz von kryptografischen Algorithmen bei TLS ausgesprochen und u.a. die zurzeit als kryptografisch stark geltenden Algorithmen aufgelistet. Andere Algorithmen sollten nach Empfehlung des BSI nicht verwendet werden.

So eine pauschale Aussage ist natürlich erstmal recht einfach zu treffen. Aber in der Praxis kommt es immer mal wieder vor, dass auf schwache Algorithmen nicht verzichtet werden kann. In diesen Fällen sollte geprüft werden, warum der schwache Algorithmus noch eingesetzt werden muss, welche Risiken für die ausgetauschten Daten entstehen und wie eine möglichst zeitnahe Migration auf stärkere Algorithmen realisiert werden kann.

… und warum Perfect Forward Secrecy?

Auch der Einsatz von Perfect Forward Secrecy gehört zur Umsetzung einer Transportverschlüsselung nach Stand der Technik. Um den Mehrwert von Perfect Forward Secrecy verstehen zu können, ist ein kurzer Exkurs zum Aufbau von TLS-Verbindungen erforderlich: TLS-Verbindungen werden auf Basis von TLS-Zertifikaten aufgebaut. In den TLS-Zertifikaten sind asymmetrische Langzeitschlüssel hinterlegt, die über das Zertifikat mit der Adresse der Webseite verknüpft werden.  Beim Aufbau einer Verbindung zwischen Browser und Webseite wird auf Basis des Langzeitschlüssels ein temporärer Sitzungsschlüssel (für diesen Schlüssel wird der ausgehandelte kryptografische Algorithmus genutzt), üblicherweise ein symmetrischer Schlüssel, erzeugt, mit dem die eigentliche Verbindung zwischen Browser und Webseite verschlüsselt wird. Nach dem Austausch der Sitzungsschlüssel können verschlüsselte Verbindungen aufgebaut und die zu schützenden Daten ausgetauscht werden.

Ohne Perfect Forward Secrecy besteht die Gefahr, dass durch das Bekanntwerden des Langzeitschlüssels, z. B. durch einen Hackerangriff auf den Webserver, auch auf Sitzungsschlüssel zugegriffen werden könnte. Diese Gefahr entsteht z. B. dann, wenn der Sitzungsschlüssel über eine mit dem Langzeitschlüssel verschlüsselte Verbindung ausgetauscht wird. Sofern der Datenverkehr im Voraus mitgeschnitten wurde, könnten mit dem Langzeitschlüssel zunächst alle ausgetauschten Sitzungsschlüssel ermittelt und anschließend auch der restliche Datenverkehr entschlüsselt werden.

Dieses Angriffsszenario wird durch Perfect Forward Secrecy verhindert, indem bei Perfect Forward Secrecy durch das Bekanntwerden des Langzeitschlüssels kein Rückschluss mehr auf die bisher verwendeten Sitzungsschlüssel möglich ist. Was bedeutet dies in der Praxis?

Perfect Forward Secrecy wird bei TLS z.B. umgesetzt, indem der Langzeitschlüssel nicht zur Verschlüsselung, sondern nur zur Signatur von Nachrichten verwendet wird. Die Sitzungsschlüssel werden dann z.B. über Diffie-Hellman ausgehandelt und anschließend mit dem Langzeitschlüssel signiert. Schlüsselaustauschprotokolle wie Diffie-Hellman basieren auf mathematischen Problemen, mit denen ein Schlüssel zwischen Parteien ausgehandelt werden kann, ohne das der konkrete Schlüssel zwischen den Kommunikationspartnern ausgetauscht werden muss (eine genauere Beschreibung findet sich auch hier).

Wenn ein Server, der Perfect Forward Secrecy umgesetzt hat, angegriffen wird, können daher nur der Langzeitschlüssel und die Sitzungsschlüssel von gerade aktiven Verbindungen kompromittiert werden. Die Sitzungsschlüssel von vergangenen Verbindungen sind sicher, da über diese keine Informationen auf den Webserver vorliegen.

Fazit

Zurzeit kann TLS durch den Einsatz von TLS 1.2 mit starken kryptografischen Algorithmen, z.B. aus der TR-02102-2, und Perfect Forward Secrecy umgesetzt werden. Allerdings handelt es sich beim „Stand der Technik“ natürlich um einen dynamischen Begriff, der ständig an aktuelle Gegebenheit angepasst wird. Wenn als Webseitenbetreiber also Empfehlungen zum Stand der Technik umgesetzt werden sollen, muss auch immer mitgeprüft werden, wann diese Empfehlungen ausgesprochen wurden und ob sie noch aktuell sind.