Was von TLS übrig bleibt

© Maria Dryfhout, 123RF

Lückenhafte Sicherheit

Zahlreiche Angriffe haben die Sicherheit von SSL/TLS-Verschlüsselungen in den letzten Jahren erschüttert. Abhilfe schaffen würden neuere Standards, doch die sind kaum verbreitet.
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)

Das TLS-Protokoll (früher SSL) ist die Grundlage der sicheren Kommunikation im Internet. Jede Webseite, die über https aufgerufen wird, verwendet im Hintergrund TLS. Doch TLS ist in die Jahre gekommen. Viele Designentscheidungen erwiesen sich nach umfangreichen Analysen als ungünstig und es fanden sich immer wieder Wege, die Sicherheit des Protokolls in Frage zu stellen. Die Reaktionen darauf sind bislang meist Flickwerk. Kleine Änderungen am Protokoll konnten bislang alle Angriffe unterbinden, aber das Problem ist ein Grundsätzliches.

Die kurze Geschichte von SSL

SSL (Secure Socket Layer) wurde ursprünglich von der Firma Netscape entwickelt. 1995, als das World Wide Web noch in seinen Kinderschuhen steckte, veröffentlichte der damalige Browser-Monopolist das Verschlüsselungsprotokoll SSL Version 2.0 (im folgenden SSLv2). Eine Version 1 existierte nur intern bei Netscape.

In SSLv2 wurden schon nach kurzer Zeit zahlreiche Sicherheitslücken entdeckt. SSLv2 unterstützte viele Verschlüsselungsalgorithmen, die schon zur damaligen Zeit als unsicher gelten mussten, darunter etwa der Data Encryption Standard (DES) in seiner ursprünglichen Form mit einer Schlüssellänge von nur 56 Bit.

Der Hintergrund für diese Entscheidung: In den 90ern war die heiße Phase der sogenannten Crypto Wars. In den USA waren starke Verschlüsselungstechniken verboten. Zahlreiche Staaten diskutierten, starke Verschlüsselung nur unter staatlicher Kontrolle zu erlauben – mit einem Drittschlüssel, der beim Geheimdienst zu hinterlegen wäre.

Kurze Zeit später schob Netscape SSLv3 nach, um zumindest die schlimmsten Sicherheitsprobleme zu beheben. Während SSLv2 heute nur noch historische Bedeutung hat und von praktisch allen modernen Browsern abgeschaltet wird, ist der Nachfolger nach wie vor im Einsatz, man findet heute noch Webserver, die ausschließlich SSLv3 unterstützen.

Erst danach wurde aus SSL ein Standard. Damit einher ging die Umbenennung in TLS (Transport Layer Security), die für viel Verwirrung sorgt. Im RFC 2246 veröffentlichte die Standardisierungsorganisation IETF 1999 das Protokoll TLS Version 1.0 (im folgenden TLSv1.0).

Dieses inzwischen vierzehn Jahre alte Protokoll ist nach wie vor die Grundlage der Mehrzahl der verschlüsselten Kommunikationsverbindungen. Bereits kurze Zeit später wurde bekannt, dass die Art und Weise, wie der Verschlüsselungsmodus CBC in TLSv1.0 eingesetzt wurde, fehleranfällig war. Doch die Probleme blieben lange theoretischer Natur.

Im Jahr 2006 folgte dann TLSv1.1, das die gröbsten Schwächen von CBC ausbügeln sollte. Zwei Jahre später trat dann TLSv1.2 auf den Plan, das mit einigen Traditionen von TLS brach. Doch TLSv1.1 und TLSv1.2 fristen bis heute ein Nischendasein. Unterstützung für beide Protokolle ist auch Jahre später kaum vorhanden – und die einst nur als theoretisch geltenden Schwächen feiern inzwischen ein Comeback.

Blockchiffren, Stromchiffren

Bei der Kommunikation über eine TLS-Verbindung kommen grundsätzlich Hybridlösungen zwischen einem Public-Key-Verfahren und einem symmetrischen Verschlüsselungsverfahren zum Einsatz. Zunächst verständigen sich Server und Client über eine in der Regel mit RSA abgesicherte Verbindung auf einen symmetrischen Schlüssel. Dieser wird anschließend zur verschlüsselten und authentifizierten Kommunikation eingesetzt.

Während der initiale Verbindungsaufbau fast immer mit einem RSA-Schlüssel vonstattengeht, gibt es bei der anschließenden Kommunikation einen wahren Zoo an Kombinationen von Algorithmen. Zusätzlich zur Verwirrung trägt bei, dass deren Bezeichnung keinem einheitlichen Schema folgt. Ein möglicher Algorithmus wäre etwa ECDHE-RSA-RC4-SHA. Das bedeutet: Ein initialer Verbindungsaufbau über RSA, anschließend ein Schlüsselaustausch über das Diffie-Hellman-Verfahren mit elliptischen Kurven, die Datenverschlüsselung erfolgt über RC4 und die Datenauthentifizierung über SHA1.

Grundsätzlich zu unterscheiden ist bei der Verschlüsselung zwischen sogenannten Blockchiffren und Stromchiffren. Eine Blockchiffre verschlüsselt zunächst immer nur einen Block einer festen Länge, etwa 256 Bit. Eine Stromchiffre kann direkt auf einen Datenstrom, wie er bei einer Datenverbindung anfällt, angewendet werden.

Die deutlich gängigeren Verfahren sind Blockchiffren. Hierbei wird heute in aller Regel der Advanced Encryption Standard (AES) eingesetzt. Dieser Algorithmus wurde von der US-Standardisierungsbehörde NIST nach einem Wettbewerb unter Kryptografen 2001 veröffentlicht.

Da eine Blockchiffre immer jeweils nur einen Block einer festen Länge verschlüsselt, kann sie nicht direkt auf einen Datenstrom angewandt werden. Hierfür gibt es verschiedene Modi. Im einfachsten Fall verschlüsselt man schlicht einen Block nach dem anderen. Doch dieser sogenannte Electronic Codebook Mode (ECB) ist aus Sicherheitserwägungen wenig empfehlenswert.

Ähnliche Artikel

comments powered by Disqus
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

Ausgabe /2023