SSL-Verschlüsselung in der Praxis

Technologie hat einige Sicherheitsrisiken im Gepäck

Von unserem Gastautor Paul van Brouwershaven, Director Business Development bei GlobalSign

[datensicherheit.de, 08.04.2014] “The new Snowden revelations are explosive. Basically, the NSA is able to decrypt most of the Internet.” („Die Snowden-Enthüllungen sind explosiv. Im Grunde ist die NSA in der Lage ein Gr0ßteil des Internets zu entschlüsseln.“), “They’re doing it primarily by cheating, not by mathematics” („Sie tun dies vor allem durch schummeln und nicht mit Hilfe der Mathematik“)
Diese erst vor einigen Wochen von Bruce Schneier (us-amerikanischer Kryptologe) ausgesprochenen Zitate und der Eindruck monatelanger Enthüllungen in der NSA-Spähaffäre legen nahe, sich neu mit SSL zu beschäftigen. Immerhin eine Technologie, die bereits 20 Jahre auf dem Buckel und einige nicht ganz unbekannte Sicherheitsrisiken im Gepäck hat.

Was genau ist SSL?

Secure Sockets Layer (SSL) und Transport Layer Security (TLS) sind die beiden heutzutage meistgenutzten Sicherheitsprotokolle. Im Wesentlichen stellt das Protokoll einen sicheren Kanal zwischen zwei Computern bereit, die über das Internet oder ein internes Netzwerk miteinander kommunizieren. Typischerweise wird das SSL-Protokoll eingesetzt, wenn ein Webbrowser sich sicher mit einem Webserver über das inhärent unsichere Internet verbinden will.
Technisch betrachtet ist SSL ein transparentes Protokoll. Um eine sichere Sitzung aufzubauen, benötigt es nur wenig direkte Interaktion mit dem Endnutzer. Denkt man beispielsweise an einem Browser, weist ein Icon in Form eines Sicherheitsschlosses darauf hin, dass SSL eingesetzt wird, oder im Falle von Extended Validation SSL werden sowohl die Adresszeile als auch ein Sicherheitsschloss innerhalb einer grünen Zeile angezeigt.

Ein solches EV SSL-Zertifikat ist durch visuelle Indikatoren leicht erkennbar und einfach zu interpretieren:

© Globalsign

Standard SSL-Zertifikate zeigen:

© Globalsign

Im Gegensatz zu HTTP-URL-ADRESSEN, die mit „http://“ beginnen und standardmäßig Port 80 verwenden, beginnen HTTPS-URL-ADRESSEN mit „https://“ und verwenden standardmäßig Port 443.
HTTP ist unsicher und kann leicht belauscht werden, wenn sensible Daten wie Kreditkarteninformationen, Anmeldedaten zu Online-Konten oder andere vertrau-liche Informationen übermittelt werden. Um die Daten zu schützen, die mit HTTPs über den Browser gepostet oder gesendet werden, werden diese Informationen deshalb verschlüsselt.

Allen Anwendungen dieser Art ist eines gemeinsam: Daten, die über das Internet oder in einem Netzwerk versendet werden, sollen und müssen vertraulich bleiben. Kreditkartennummern, Kontoanmeldedaten, Passwörter und persönliche Daten dürfen nicht im Internet offengelegt werden. Konkret bedeutet das beispielsweise, dass sobald die Kreditkartendetails und der Betrag, mit dem die Kreditkarte belastet werden soll, gesendet werden, ein Cyberkrimineller nicht mit einer Man-in-the-Middle-Attacke in der Lage ist, den Betrag oder den Adressaten der Zahlung zu ändern. Unternehmen und Institutionen müssen wiederum ihren Kunden und den Nutzern des Extranets versichern, dass Sie tatsächlich derjenige sind, für den Sie sich ausgeben. Das ist ein essentieller Bestandteil des regionalen, nationalen und internationalen Datenschutzes.

In der Praxis sollte ein SSL-Zertifikat in allen nachfolgenden Fälle verwendet werden:

• Bei Online-Kreditkartentransaktionen
• Bei Online-Systemanmeldungen, wenn sensible Informationen über Webformulare übertragen werden oder um geschützte Bereiche von Websites zu sichern
• Um Webmail, Outlook Web Access, Exchange und Office Communications Server zu sichern
• Um Tools für die Abwicklung von Geschäftsprozessen und virtualisierte Anwendungen wie Citrix Delivery- oder Cloud-basierte Rechnerplattformen zu sichern
• Um die Verbindung zwischen einem E-Mail-Client wie Microsoft Outlook und einem E-Mail-Server wie Microsoft Exchange zu schützen
• Um die Übertragung von Dateien über https- und FTP(s)-Dienste zu sichern, wenn zum Beispiel Inhaber einer Website neue Seiten hinzufügen oder große Dateien transferieren
• Um Anmeldungen an Hosting Control Panels und Aktivitäten wie Parallels, cPanel und andere zu sichern
• Bei jeglichem Intranet-basierten Datenverkehr (interne Netzwerke, Filesharing, Extranets und Datenbankverbindungen)
• Um Netzwerkanmeldungen und Netzwerkverkehr mit SSL VPNs wie VPN Access Server oder Anwendungen wie Citrix Access Gateway zu sichern

Aber Achtung: Die in digitalen Zertifikaten verwendeten Algorithmen werden weltweit kryptoanalytisch eingeordnet, und inzwischen als deutlich schwächer bewertet als das noch vor wenigen Jahren der Fall war, allerdings immer noch als ausgesprochen solide. Moderne Algorithmen zu entwickeln ist die eine Seite der Medaille. Die andere, dass alle Beteiligten schneller als in der Vergangenheit die zur Verfügung stehenden Algorithmen auch tatsächlich einsetzen.

Das Problem endet nicht bei den Zertifikaten

Es ist wichtig zu verstehen, dass das Problem leider nicht bei der in den Zertifikaten verwendeten Kryptografie endet. Die in den Zertifikaten verwendeten Cipher Suites sind ein zusätzlicher Angriffsvektor. Laut einer Datenerhebung des Trustworthy Internet Movement verwenden nahezu 33% der Top 200.000 Sites schwache Cipher Suites.
Perfect Forward Secrecy (PFS) ist eine spezielle Eigenschaft von Verschlüsselungs-verfahren, die als besonders sicher gilt, aber noch wenig verwendet wird. Das gilt für Cipher Suites ebenso wie für die Top 200.000 Sites. Bei PFS ist der Schlüsseltausch zwischen Server und Browser so gestaltet, dass der Schlüssel vor einer späteren Entschlüsselung geschützt ist. Der geheime Sitzungsschlüssel wird nicht zwischen den Sitzungspartnern übertragen. Das funktioniert aber nur, wenn Browser und Server PFS einsetzen. Gerade bei der Konfiguration von letzteren hapert es.
Auch OCSP (Online Certificate Status Protocol)  Stapling, das Performance-Vorteile für sichere Seiten bringt, und HTTP Strict Transport Security (HSTS) werden vergleichsweise wenig verwendet. Und: immer noch setzen zahlreiche Websites veraltete SSL-Versionen ein. Man sollte also durchaus Websites mit einem entsprechenden Tool  (wie beispielsweise kostenlos unter https://sslcheck.globalsign.com/de) überprüfen.

Und dann ist da noch die Schlüsselverwaltung

Was bleibt, ist das Problem der Schlüsselverwaltung. Durch die aktuellen Leaks wissen wir nun definitiv, dass Nachrichtendienste Datenbanken mit kompromittierten Schlüsseln pflegen. An sich ist das keine große Überraschung, Sicherheitsexperten tun ähnliches. Aus Sicht eines potenziellen Angreifers ist die aktuelle Praxis der Schlüsselverwaltung äußerst hilfreich. Einer der Hauptschwachpunkte: Websites nutzen die gleichen Schlüssel viel zu lange und immer wieder. Das macht ihn für einen potentiellen Lauscher umso wertvoller.
Man sollte sich an dieser Stelle auf eine CA verlassen, die explizit unbegrenzte Neuausstellungen erlaubt, und nicht zulässt, dass der gleiche Schlüssel mehrfach verwendet wird. Wer vor dem Verwaltungsaufwand zurück scheut, kann in der Regel auf APIs und Plug-ins zurückgreifen, die solche Änderungen automatisiert vornehmen.

Welche Verschlüsselungsstärke? (Schlüsselanforderung: 2048 Bit für 2014)

In Einklang mit der Leitlinie des National Institute of Standards and Technology (NIST) hat man Zertifizierungsstellen (CAs) geraten, den zunächst in der NIST Special Publication 800-57 und später den in 800-131A veröffentlichen Empfehlungen zu folgen.
Darin wurden CAs angewiesen, die Signierung von digitalen Zertifikaten mit öffentlichen 1024-Bit-RSA-Schlüsseln nach dem 31. Dezember 2010 ausdrücklich zu missbilligen und die Signierung zum 31. Dezember 2013 vollständig einzustellen (Tabelle 2, Abschnitt 3 der 800-131A).

Es bestand allerdings ein allgemeiner Konsens darüber diese besonders langlebigen Zertifikate gesondert zu behandeln. Einzelne CAs haben bereits deutlich vor dem Ablauf der Frist eine stärkere als die von der NIST-Leitlinie empfohlene Schlüssellänge verpflichtend eingeführt. So akzeptiert auch GlobalSign bereits seit dem 1. Januar 2011 keine Signaturanforderung für ein Zertifikat (CSR) mit einer Schlüssellänge von 1024 Bit.

Erst 2012 wurden die NIST-Empfehlungen vom CA/Browser-Forum übernommen. Danach wurden Zertifizierungsstellen von Browser-Root-Programmen wie zum Beispiel der Mozilla CA Certificate Policy angewiesen, die Signatur von Zertifikaten mit 1024 Bit RSA-Schlüsseln bis zum Stichtag komplett einzustellen.

Die Migration zu längeren Schlüsseln schützt korrekt ausgebrachte SSL-Lösungen auch vor ausgereiften Attacken. Denn: In den kommenden Jahren, nehmen die Chancen für die Faktorisierung von 1024 RSA-Primzahlen zu und damit das Potenzial für erfolgreiche MITM-Attacken auf langlebige Zertifikate, die noch für Live-Transaktionen eingesetzt werden.

Was man tun sollte

• Achten Sie beim Kauf von Zertifikaten darauf, was ein Anbieter verspricht und welche tatsächlichen Verpflichtungen er Ihnen gegenüber hat
• Pflegen Sie eine Sicherheitsrichtlinie, die folgende Fragen beantwortet:
• Welche kryptografischen Algorithmen können verwendet werden?
• Wie oft müssen die Schlüssel geändert werden?
• Wie stark muss zwingend verschlüsselt werden?
• Wie werden die Schlüssel generiert und wie werden sie gesichert?
• Erstellen Sie eine Bestandsliste aller kryptografischen Schlüssel, mit Altersangabe und Stärke der Verschlüsselung
• Stellen Sie sicher, dass jeder Schlüssel richtlinienkonform verwaltet wird
• Achten Sie neben einem Zertifikat mit ausreichend großem Schlüssel darauf die aktuellste Version von Webserver und SSL/TLS-Bibliotheken zu verwenden
• Verwenden Sie nach Möglichkeit Chiffren mit PFS
• Betreiben Sie ausnahmslos alle SSL-Konfigurationen nach diesem Schema
• Sorgen Sie zusätzlich dafür, dass alle Rechner, die Zugang zum Schlüsselmaterial haben entsprechend gepatched und gehärtet sind sowie über strukturierte Zugriffsrechte verfügen
• Wenn Sie zwischenzeitlich unsicher sind, welche Verschlüsselungsstärke Ihr vorhandenes Zertifikat hat, überprüfen Sie es mit einem SSL Configuration Checker

© GlobalSign

Paul van Brouwershaven ist Director Business Development bei GlobalSign

Weitere Informationen zum Thema:

GlobalSign®
SSL-Informationszentrum