Samstag, 20. Mai 2017

Mitleser


Über die Sicherheit des PIWI-Servers, betrieben von der Stadt Wiesbaden, hatte ich mich ja schon ausgelassen: TLS, TLS (2) und TLS (3). Leider hat sich am Status dieses Servers in den vergangenen Monaten nichts geändert, deshalb möchte ich auf das Thema zurückkommen.

In der Vergangenheit hatte ich dargestellt, wie man in diesen Server eindringen kann, um diesen Server für fremde Zwecke einzuspannen, ihn zu mißbrauchen. Und heute möchte ich Ihnen einen Weg präsentieren, wie man die Daten, die zwischen diesem Server und dem Computer eines Besuchers hin- und hergeschickt werden, mitlesen kann, d.h. die Sicherheit, die der Server vorgibt, kann ausgehebelt werden. Dazu muß man an diesem Server nichts verändern, man benötigt nur die Daten, die von diesem Server kommen bzw. an ihn gerichtet sind.

Aber ich werde Ihnen nicht zeigen, wie man das macht, denn das kann ich nicht und wenn ich es könnte, würde ich es Ihnen nicht zeigen. Aber ich werde Ihnen zeigen, an welchem Punkt man den Hebel ansetzen kann.

Das Internet ist ein offenes Netz, jeder kann mitlesen, wenn er einen Zugriff auf das richtige Kabel bzw. einen Computer auf dem Weg der Daten hat. Einen solchen Angriff nennt man Man-in-the-Middle-Angriff. Es gibt nur einen Schutz gegen solche Versuche:

Gegenmaßnahmen


Sicherung vor Mitlesen


Am effektivsten lässt sich diese Angriffsform mit einer Verschlüsselung der Datenpakete entgegenwirken

Quelle: angegebener Artikel in der Wikipedia

Genau dies macht der PIWI-Server, er verschlüsselt die Daten, die zwischen dem Computer eines Besuchers und diesem Server hin- und hergeschickt werden. Aber er macht dies schlecht, sehr schlecht. Und diese Aussage will ich mit diesem Text begründen.


Status

In meinem ersten Text zum Thema PIWI hatte ich bereits auf das Unternehmen Quality SSL Labs hingewiesen, dessen Geschäftsfeld die Sicherheit solcher Server ist. Auf der Seite dieses Unternehmens kann man eine Serveradresse eingeben und danach wird dieser Server automatisiert auf Sicherheit geprüft. Dies hatte ich für meinem ersten Text getan und das damalige Ergebnis dargestellt: Stand damals und Stand heute. Aus der Vielzahl der Informationen, die auf dieser Seite zum PIWI-Server präsentiert werden, hatte ich nur die Zusammenfassung dargestellt. Und mit diesem Text möchte ich eine weitere Angabe von dieser Seite hier präsentieren und Ihnen die dargestellten Informationen ein wenig erläutern. Und das sind die Informationen, dich ich in diesem Text behandle:

Wenn ein Anwender sich auf diesem Server anmeldet, dann werden die Daten, die zwischen dem Computer des Anwenders und dem Server hin- und hergeschickt werden, verschlüsselt. Soweit so gut. Es gibt verschiedene Verfahren zur Verschlüsselung von Daten, die sich über die Jahrzehnte entwickelt haben; manche sind gut, andere sind schlecht, die meisten Verfahren aus der Vergangenheit sind heute einfach überholt.

In der abgebildeten Liste finden Sie die 8 Verfahren, die der PIWI-Server anbietet, und zu jedem Verfahren finden Sie eine Bewertung. Sie sehen diese beiden Worte: INSECURE und WEAK. Nach Meinung der Fa. Quality SSL Labs sind diese Verfahren entweder unsicher oder schwach, wobei schwache Verschlüsselung noch die beste Note ist, die in dieser Liste auftaucht.

In der Reihenfolge, in der der Server die Verschlüsselungsverfahren anbietet, möchte ich einige Worte zu diesen Verfahren verlieren. Aber einige Worte vorweg.

Hervorhebungen

Die in diesem Text angegebenen Zitate enthalten Hervorhebungen, die im Original nicht vorhanden sind, d.h. ich habe einzelne Worte eines Zitats besonders markiert.

INSECURE

Also unsicher, das ist die Bewertung des eingesetzten Verfahrens. Eine unsichere Verschlüsselung ist so gut wie keine Verschlüsselung, anders formuliert, man sollte ein so bewertetes Verfahren nicht mehr verwenden.

WEAK

Also weich. Das ist besser als unsicher, aber kein stabiles (=hartes) Verfahren. Das sollte man besser nicht mehr verwenden.

Welches Verfahren bleibt da noch übrig? Auf diesem Server keins.

RC4

Das ist die Abkürzung für ein Verschlüsselungsverfahren, dessen Beschreibung Sie hier finden: RC4. Es gilt heute als nicht sicher:
Der erste praktische Angriff auf die RC4-Chiffre gelang Scott Fluhrer, Itsik Mantin und Adi Shamir im Jahr 2001.

Quelle: Wikipedia-Artikel zu RC4

Bitte beachten Sie die Jahreszahl: 2001. Inzwischen ist viel passiert, die Computer wurden weiterentwickelt und haben heute eine höhere Leistungsfähigkeit. Es steht die Aussage im Raum, daß man Daten, die nach diesem Verfahren verschlüsselt wurden, heute in Echtzeit (also praktisch sofort) entschlüsseln kann. Weitere Details dazu finden Sie hier: Let me GOOGLE this for you.

Die Entscheidung bezüglich dieses Verschlüsselungsverfahrens ist gefallen:
Im Februar 2015 wurde mit RFC 7465 der Einsatz von RC4 im Rahmen von TLS verboten, da es erhebliche Sicherheitsmängel aufweist.

Quelle: RC4-Artikel in der Wikipedia

This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions.
Quelle: Prohibiting RC4 Cipher Suites

Die Stadt Wiesbaden beachtet diese Vorgabe nicht.

Nun zu den einzelnen angebotenen Verfahren.

Fragestellung

Damit Sie sich ein Bild von Verschlüsselungen machen können, präsentiere ich Ihnen hier ein Beispiel eines verschlüsselten Textes.
iQEcBAABCgAGBQJZGdA8AAoJELtGpOiAUdjoVMEIAIw+vnVwnaNnTTq4pu3E8w25
riDTELoVxazvBzcTRoRuwbCjjXxR8d+pZgmhe2Lf9WRtp3i7UfHC1CIwb7CbJTMm
hpMpIbls60cljKrxcUn3lnC8GmYsbeGLdNjBEhN0PYX2YqnzMeIHuDzkLH6u04eE
u+w5bEUtfuCqi5KuuakaKCVKo4eoP3/5PQ5WX7PaLx4rJ96YrFplkOi9RG4kTY7q
MxhcEz3e+JiEq9aT27EC3fb07PKF5bEd/08XrAPpn3NLqHkNuDIXJKiATEv8w58V
SJ3lBz4PBdOgxGQPa68Z2en/76Wp6UmJx6Km5IVCB4AQkiFlW/A7WwzCnYtBgO4=

Quelle: irgendeine verschlüsselte Mail, die ich mal schrieb

Das können Sie nicht lesen? Das sollen Sie auch nicht lesen können! Das ist der Sinn einer Verschlüsselung. Aber irgendwie wollen Sie das doch lesen, denn Sie haben diesen Server (=PIWI) aufgerufen, damit Sie die Seite auch angezeigt bekommen und den Inhalt der Seite lesen können. Und dafür benötigen Sie:
  • den verschlüsselten Text (siehe dieses Beispiel)
  • die Information, mit welchem Verfahren dieser Text verschlüsselt wurde
  • den Schlüssel, denn ohne Schlüssel können Sie (genauer: Ihr Computer) diesen Text nicht lesbar machen
Für den Austausch eines solchen Schlüssels zwischen dem Server und Ihrem Computer gibt es feste Regeln: Schlüsselaustauschprotokoll. Dieser Austausch des notwendigen Schlüssels wird aufwändig abgesichert, sollte also in einer Form geschehen, daß ein Mitleser dies nicht versteht, denn mit diesem Schlüssel und dem Wissen, welches Verfahren verwendet wurde, kann jeder Mitleser die Nachricht in lesbaren Text umwandeln.

Das reicht aber noch nicht. Irgendwie muß auch sichergestellt sein, daß die Daten auf dem Weg zu Ihrem Computer nicht nur nicht mitgelesen sondern auch nicht verändert wurden. Sagt Ihnen das Schlagwort Emser Depesche etwas? Damals führte die Veränderungen an der Nachricht zum Krieg; soweit wird es wohl nicht kommen, wenn eine PIWI-Nachricht verändert wird, aber trotzdem will ich keine Veränderungen an einem Text haben. Diese Fragestellung nennt sich Nachrichten-Authentifizierung.

Zurück zum PIWI-Server, hin zu den einzelnen Verfahren, die dieser Server als seine Fähigkeiten anbietet.

TLS_RSA_WITH_RC4_128_MD5

Dies ist das erste Verfahren, das dieser Server anbietet. Es wird als INSECURE bewertet.

Es besteht aus diesen Teilen:
  • Verschlüsselung nach dem Verfahren RC4
  • der Austausch der Schlüssel erfolgt nach dem RSA-Verfahren
  • der übermittelte Text wird nach dem Verfahren MD5 geprüft, ob er unterwegs verändert wurde

TLS_RSA_WITH_RC4_128_SHA

Dies ist das nächste Verfahren, das dieser Server anbietet. Auch dieses wird als INSECURE bezeichnet.

Es besteht aus den Teilen: Verschlüsselung nach RC4, Schlüsselaustausch nach RSA und Integritätsprüfung nach SHA-1.

TLS_RSA_WITH_3DES_EDE_CBC_SHA

Dies Verfahren wird als WEAK bewertet. Es ist somit das beste der angebotenen Verfahren. Es besteht aus den Teilen: Verschlüsselung nach 3DES, Integritätsprüfung nach SHA-1 und Schlüsselaustausch nach RSA.

TLS_RSA_WITH_DES_CBC_SHA

Das Verfahren wird als INSECURE bewertet. Es besteht aus folgenden Teilen: Verschlüsselung nach DES, Integritätsprüfung nach SHA-1 und Schlüsselaustausch nach RSA.

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

Das Verfahren gilt als INSECURE. Es besteht aus folgenden Teilen: Verschlüsselung nach RC4, Integritätsprüfung nach SHA-1 und Schlüsselaustausch nach RSA.

In diesem Wort taucht der Ausdruck EXPORT1024 auf. Ist Ihnen dies aufgefallen? Er besagt, daß dieses Verfahren und die entsprechende Software aus den USA exportiert werden darf. Es gab einmal Zeiten, da haben die USA den Export von Verschlüsselungsverfahren und entsprechender Software verboten und diese Version war erlaubt, das wurde durch diesen Ausdruck gekennzeichnet. Im Jahre 1999 wurde dieses Verbot aufgehoben, warum wohl? Honi soit qui mal y pense. Dieses Verfahren erfüllt somit die Vorgaben der US-Regierung, die 1999 aufgehoben wurden.

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

Dieses Verfahren gilt als INSECURE. Es besteht aus folgenden Teilen: Verschlüsselung nach DES, Integritätsprüfung nach MD5 und Schlüsselaustausch nach RSA.

Auch dieses Verfahren durfte aus den USA exportiert werden und das bereits vor 1999. Sie erkennen daran, wie schwach die Verschlüsselung ist.

TLS_RSA_EXPORT_WITH_RC4_40_MD5

Auch dieses Verfahren gilt aus INSECURE. Es besteht aus folgenden Teilen: Verschlüsselung nach RC4, Integritätsprüfung nach MD5 und Schlüsselaustausch nach RSA. Das Verfahren durfte bereits vor 1999 aus den USA exportiert werden.

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

Auch dieses Verfahren wird als INSECURE bewertet. Es besteht aus den Teilen: Verschlüsselung nach RC2, Integritätsprüfung nach MD5 und Schlüsselaustausch nach RSA.

Der Server bietet dieses Verfahren als letztes an, es gilt allgemein als unsicher. Bereits 1997 wurde vorgeführt, wie man damit verschlüsselt Daten knacken kann.


Bewertung

Der Server verwendet Methoden zur Verschlüsselung von Daten, die grösstenteils aus den 1990er Jahren stammen und heute überholt sind, da sie unsicher sind. Für die meisten der angebotenen Verfahren gilt diese Aussage:
Die Internet Engineering Task Force (IETF) lässt keinen Zweifel an ihren Absichten: Mit dem Request for Comment 7465 verbietet sie den Einsatz des Verschlüsselungsverfahrens RC4 im Rahmen der Transport-Verschlüsselung TLS. Die IETF ist das wichtigste Standardisierungsgremium des Internets, hat allerdings keine Möglichkeit, die Einhaltung seiner Standards zu erzwingen.

Quelle: IETF verbietet RC4-Verschlüsselung in TLS

Und bei diesem Server setzt die Stadt Wiesbaden weiterhin dieses Verfahren ein. Die übrigen Verfahren dieses Servers sind besser, aber heute auch überholt.


Fazit

Die Sicherheit dieses Servers ist nicht gegeben, der Server gaukelt Sicherheit nur vor.

Natürlich kann man argumentieren, daß sich auf diesem Server nur Stadtpolitiker anmelden, Sie als normaler Bürger also nicht betroffen sind. Aber neben den Gefahrenpunkten, die ich in der Vergangenheit bereits beschrieben habe, gibt es einen weiteren Aspekt: Wie geht die Stadt Wiesbaden mit den Daten ihrer Bürger um, wenn sie mit den Daten aus der Stadtpolitik schon so sträflich umgeht? Wie sicher sind unsere Daten bei der Stadt Wiesbaden?