Suchergebnisse:

SSL, TLS, HSTS, SHA1, SHA2, AES, RC4.... Sicherheit durch Abkürzungen?

Fast alle meine IT Kollegen reden immer noch von SSL Verschlüsselung wenn sie über sichere Verbindungen im Internet reden. Dabei wurde SSL eigentlich schon 1999 durch den TLS Standard abgelöst. Seit 2008 gilt gar der aktuelle Standard TLS 1.2.
Die Wahrheit ist aber leider, dass viele Webseiten nie auf TLS umgestiegen sind. Über die Jahre wurden im SSL/TLS Standard immer wieder Schwachstellen gefunden, trotzdem hielten viele bis zu Letzt an SSL (hoffentlich zumindest in Version 3) fest. In 2014 wurde SSL3 dann doch komplett geknackt und keine Webseite sollte diesen Standard mehr einsetzten. Als User sollte ich auch keinen Browser mehr einsetzten der dieses Protokoll überhaupt nutzen möchte. (Mehr Infos: https://disablessl3.com)
Chrome und Firefox haben in den aktuellen Version SSLv3 bereits deaktiviert. Internet Explorer 11 zieht am 14 April(!) nach. (Chrome: https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/Vnhy9aKM_l4 Firefox: https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/ Internet Explorer: https://technet.microsoft.com/en-us/library/security/3009008.aspx )

Ok, eine Abkürzung können wir aus unserem Sprachgebrauch streichen. SSL ist tot und sollte nicht mehr genutzt werden. Lang lebe TLS.

Was ist mit dem Rest? Hier fängt es jetzt an etwas komplexer zu werden. TLS ist eher als Sammlung von verschiedenen Verfahren zu verstehen um den Traffic zu verschlüsseln. Den einen, definitiven Weg gibt es nicht.

Bei zwei Teilen des Protokolls wurden in der letzten Zeit Schwachstellen in den verwendeten Algorithmen gefunden, im Verschlüsselungslayer und im Data Integrity Layer.

Die Verschlüsselung ist einfach abgehandelt. Der Algorithmus RC4 der hier lange Zeit verwendet wurde gilt als nicht mehr sicher. Zum Glück wird auch AES als Verschlüsselungsalgorithmus akzeptiert und dieser gilt noch für einige Jahre als sicher. In unserem Fall haben wir also RC4 einfach abgeschaltet und alles ist gut.

Der nächste Schritt ist leider nicht ganz so einfach. Im Data Integrity Layer kommt ein Hashalgorithmus zum Einsatz. Vereinfacht ausgedrückt kann ich mit einer Hashfunktion aus A immer B berechnen aber aus B kann ich nicht auf A zurückrechnen. Das ist ein ganz wichtiger Punkt, TLS vertraut darauf, dass ich wenn ich B habe, ich niemals erraten kann was A war. Allerdings hat B in der Regel eine deutlich kleinere Länge als A. Es gibt deshalb auch einen Wert C der zu B gehasht wird.

Um genau zu sein gibt es ein unendliche Anzahl von Werten deren Hash B ergibt. Ein guter Hashalgorithmus macht es aber unwahrscheinlich diese Werte zu finden.

TLS nutzt einen Hash um zu garantieren, dass während der Datenübertragung keiner was an den Daten geändert hat.

Der Server schickt als Paket A zum Client und dieser nutzt dann einen Hashalgorithmus um auf Hash B zu prüfen und zu sagt dann, ja, das Paket kam direkt von dem Server.

Wenn ich jetzt einen Weg finde ein beliebiges Paket C zu berechnen, dass auch den Hash B hat, dann habe ich diesen Sichertheitsmechanismus ausgehebelt.
Ich kann dem Client jetzt beliebige Daten schicken und der Client akzeptiert diese als echt.

Das ist vor einigen Jahren mit dem Hashalgorithmus MD5 passiert. Eine einfache Google Suche zeigt eine Vielzahl von Onlinediensten die einen MD5 Hash umkehren können. MD5 wird deshalb auch in TLS nicht mehr genutzt.

Vor einiger Zeit wurde klar, dass auch der zweite verwendete Hashalgorithmus SHA-1 nicht mehr lange sicher sein wird. Mit der steigenden Rechenpower die jeder zur Verfügung hat ist es nur eine Frage der Zeit bis auch dieser Algorithmus genknackt ist. Experten gehen davon aus, dass Geheimdienste hier auch schon weiter sind und SHA-1 keine Sicherheit vor Regierungen mehr bietet.

Zum Glück gibt es einen Nachfolger, SHA-2 (auch SHA-256 genannt). Dieser gilt auch noch auf viele Jahre als sicher. Wir müssen also einfach nur SHA-1 auf unseren TLS Servern abschalten und SHA-2 nutzen und alles ist gut? Leider nein.

SHA-2 ist ein recht junger Algorithmus und als solcher nicht in älteren Betriebssystemen integriert. Im Speziellen sind hier Windows XP und Windows Server 2003 betroffen.

Für XP wurde dies mit SP3 nachgereicht. Bei Windows Server 2003 allerdings nicht. (Es gibt einen Hotfix, der aber nicht immer hilft.)
Beide Systeme werden von Microsoft nicht mehr mit neuen Features (XP/2003) oder Sicherheitsupdates (XP) bedacht. Und selbst bei Server 2003 werden nur noch kritische Sicherheitsfehler behoben. SHA-2 zählt dazu bei Microsoft wohl nicht.

Mitte Januar haben wir testweise mal SHA-1 auf unseren Servern komplett deaktiviert, 10% aller System die wir überwachen konnten sich dann nicht mehr mit uns verbinden. Wir haben SHA-1 also wieder eingeschaltet. Wir werden es aber über die nächsten Monate nach und nach wieder auf allen Servern deaktivieren. Den Anfang hat das OCC selbst gemacht. Hier werden nur noch als sicher geltende Verfahren zugelassen. Das hat aber auch zur Folge, dass ich das OCC mit alten Browsern oder einem alten Betriebssystem nicht mehr erreichen kann.

Der nächste Schritt sind die verbundenen Server bei allen Partnern und deren Kunden. Seit einigen Wochen ist es deshalb nicht mehr möglich einen neuen OCC-Connector auf Windows XP oder Windows Server 2003 zu installieren.

In den nächsten Monaten werden wir gezielt auf unsere Partner zugehen und darauf hinweisen wo noch ein OCC Connector auf Windows Server 2003 oder Windows XP läuft. Diese müssen dann auf einen neueren Server umgezogen werden.

Ende 2015 werden wir dann die SHA-1 Unterstützung komplett abschalten. (oder vorher, falls ein Verfahren zum Knacken von SHA-1 veröffentlicht wird)

Übrigens werden Passwörter bei uns auf dem Transportweg zusätzlich zu der TLS Verschlüsselung noch mit einem anderen Verfahren verschlüsselt. Mehr dazu in einem zukünftigen Blogeintrag.

Machen Abkürzungen jetzt also sicher? – Ja, wenn es die richtigen Abkürzungen sind. Und wenn wir zusammen mit unseren Partnern die Abkürzungen richtig einsetzen.

von Server-Eye Team