Bundesamt für Sicherheit in der Informationstechnik

M 5.66 Clientseitige Verwendung von SSL/TLS

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Benutzer

Das bei der Web-Nutzung am häufigsten verwendete Sicherheitsprotokoll ist SSL/TLS (Secure Socket Layer/Transport Layer Security). Die erste Version des SSL-Protokolls (SSL v 1.0) wurde von Netscape entwickelt. Neuere Versionen sind unter der Bezeichnung TLS in verschiedenen RFCs standardisiert. SSL/TLS wird von allen aktuelleren Browsern unterstützt. Mit SSL/TLS können Verbindungen abgesichert werden:

  • durch Verschlüsselung der Verbindungsinhalte,
  • durch Überprüfung der Vollständigkeit und Korrektheit der übertragenen Daten,
  • durch Prüfung der Identität des Servers und
  • optional durch Prüfung der Identität der Client-Seite.

Zu Beginn einer neuen mit SSL/TLS abgesicherten Kommunikationsverbindung findet ein sogenannter Handshake zwischen Client und Server statt. Hierbei verständigen sich Client und Server über die kryptographischen Algorithmen, die für Schlüsselaustausch, Verschlüsselung und Integritätssicherung eingesetzt werden. Außerdem einigen sich Client und Server über die SSL-Version, die verwendet wird. Zusätzlich sendet der Server sein X.509-Zertifikat an den Client. Optional kann auch der Client dem Server sein X.509-Zertifikat übermitteln, falls dies vom Server angefordert wird. Mit Hilfe eines asymmetrischen Verschlüsselungsverfahrens wird anschließend ein symmetrischer Schlüssel sicher ausgetauscht. Für die Verschlüsselung der eigentlichen Datenübertragung wird nun ein symmetrisches Verfahren benutzt, weil hiermit dies große Datenmengen schneller verschlüsselt werden können. Bei jeder Transaktion wird ein anderer symmetrischer Schlüssel als "Session Key" ausgehandelt, mit dem dann die Verbindung verschlüsselt wird.

Ein Benutzer kann Webseiten, die eine SSL/TLS-gesicherte Datenübertragung ermöglichen, beispielsweise daran erkennen, dass die Internet-Adresse um ein "s" erweitert ist (https://www...). Zusätzlich werden solche Webseiten bei den meisten gängigen Browsern auch besonders gekennzeichnet, beispielsweise durch ein angezeigtes Symbol (Schlüssel, Vorhängeschloss etc.) oder durch eine farbliche Markierung der Internet-Adresse.

Die Nutzung von SSL/TLS ist nicht auf HTTP -Clients und -Server beschränkt. Auch Protokolle wie SMTP , FTP , IMAP oder LDAP können durch SSL/TLS kryptographisch abgesichert werden, allerdings setzt dies voraus, dass die betreffenden Clients und Server diese Sicherheitsfunktion jeweils unterstützen.

SSL/TLS besteht aus zwei Schichten. Auf der oberen Schicht arbeitet das SSL/TLS Handshake Protokoll. Dieses dient dem Client und dem Server dazu, sich gegenseitig zu authentisieren sowie dazu, für den anschließenden Datenverkehr einen Schlüssel und einen Verschlüsselungsalgorithmus auszuhandeln. Die untere Schicht, das SSL/TLS Record Protokoll, das die Schnittstelle zur TCP -Schicht bildet, ver- und entschlüsselt den eigentlichen Datenverkehr. Da SSL/TLS für den Zugriff auf TCP auf der Socket-Schnittstelle aufsetzt und diese durch eine sicherheitserweiterte Version ersetzt, ist es auch für andere Dienste verwendbar.

Versionsnummer

Es existieren mehrere SSL/TLS-Protokollversionen, wie SSL v2, SSL v3, TLS v1.0, TLS v1.1 und TLS v1.2. SSL v1 wurde nicht veröffentlicht. Um eine sichere Verbindung zwischen Client und Server zu gewährleisten, sollte mindestens TLS 1.2 verwendet werden.

TLS 1.1 bietet ausreichende Sicherheit, aber im Vergleich zu TLS 1.2 weist es jedoch einige Schwächen auf, z. B. sind in TLS 1.1 noch Cipher-Suites vorhanden, die auf IDEA und DES basieren, in TLS 1.2 nicht mehr.

TLS 1.0 kann in bestehenden Client-Anwendungen übergangsweise weiter eingesetzt werden, falls eine sofortige Migration zu TLS 1.1 oder vorzugsweise TLS 1.2 nicht möglich ist und geeignete Maßnahmen gegen Chosen-Plaintext-Angriffe ( z. B. BEAST) auf die CBC-Implementierung getroffen werden. Generell sollte jedoch eine Migration zu TLS 1.2 schnellstmöglich erfolgen. SSL v2 und SSL v3 dürfen nicht mehr eingesetzt werden.

Algorithmen und Schlüssellängen

Bei SSL/TLS können verschiedene kryptographische Algorithmen mit verschiedenen Schlüssellängen eingesetzt werden (siehe hierzu auch M 3.23 Einführung in kryptographische Grundbegriffe ). Beim Verbindungsaufbau einigen sich Client und Server auf die in der Sitzung verwendeten Verfahren.

Durch die Auswahl der Produkte (Browser, Webserver, Plug-In etc.) und geeignete Konfiguration ist sicherzustellen, dass bei der SSL/TLS-geschützten Kommunikation ausschließlich Algorithmen und Schlüssellängen zum Einsatz kommen, die dem Stand der Technik und den Sicherheitsanforderungen der Institution entsprechen. Darüber hinaus sollten die verwendeten Cipher-Suites Perfect Forward Secrecy (PFS) unterstützen (siehe TR-02102-2).Weitere Hinweise zu Algorithmen und Schlüssellängen finden sich in der Maßnahme M 2.164 Auswahl eines geeigneten kryptographischen Verfahrens .

Zertifikate

Es ist schwierig, bei der Datenkommunikation über offene Netze die Identität der Kommunikationspartner zu überprüfen, da nicht sichergestellt ist, dass Namensangaben korrekt sind. Bei SSL/TLS erfolgt die Überprüfung der Identität des Kommunikationspartners über so genannte Zertifikate. Zertifikate enthalten deren öffentliche Schlüssel sowie eine Bestätigung einer weiteren Instanz über die korrekte Zuordnung des öffentlichen Schlüssels zu dessen "Besitzer", hier also ein Server oder Client. Der Wert eines Zertifikates hängt also nicht zuletzt davon ab, wie vertrauenswürdig diese Bestätigungsinstanz (auch Trustcenter oder Zertifizierungsstelle genannt) ist. Die Echtheit des Zertifikates lässt sich wiederum mit dem öffentlichen Schlüssel der Bestätigungsinstanz überprüfen.

Alle gängigen Browser enthalten bereits bei der Installation SSL/TLS-Zertifikate einiger Zertifizierungsstellen. Diese Zertifizierungsstellen haben sehr unterschiedliche Sicherheitsleitlinien und Bedingungen, unter denen sie Zertifikate erteilen. Bevor sicherheitskritische Informationen über eine SSL/TLS-geschützte Verbindung übertragen werden, sollte deshalb die Sicherheitsrichtlinie der jeweiligen Zertifizierungsstellen geprüft werden.

Bei der Aufnahme eines neuen Zertifikates sollte darauf geachtet werden, dieses erst nach Überprüfung des "Fingerprints" zu aktivieren. Der Fingerprint ist eine hexadezimale Zahl, die zusammen mit dem Zertifikat übermittelt wird. Zusätzlich sollte sie auf einem anderen Weg übermittelt und verglichen werden, da diese die Korrektheit des Zertifikats sicherstellen soll.

Betreiber von Webservern, die mit den Besuchern ihrer Webseiten sicherheitsrelevante Daten austauschen wollen, sollten hierzu einen kryptographisch abgesicherten Weg anbieten, also z. B. SSL/TLS.

In der Vergangenheit ist es bereits vorgekommen, dass Zertifizierungsstellen kompromittiert und dadurch Hunderte gefälschte Zertifikate ausgestellt wurden, darunter auch solche für Nachrichtendienste, Online-Portale, andere Zertifizierungsstellen und Anonymisierungsdienste. Durch Widerrufslisten und Validierungsprotokolle wie OCSP (Online Certificate Status Protocol) können gefälschte, manipulierte oder veraltete Zertifikate allerdings zeitnah als ungültig erklärt werden. Daher sollte die Validierung von Zertifikaten in Anwendungsprogrammen wie Browsern und E-Mail-Clients aktiviert werden. Dabei ist OCSP der Verwendung von Zertifikatswiderruflisten (Certificate Revocation Lists, CRLs) vorzuziehen, da OCSP zeitnahe Aktualisierungen über das Internet erlaubt.

Kann ein Zertifikat nicht validiert werden, beispielsweise weil der OSCP-Server nicht erreicht oder auf die Widerrufslisten nicht zugegriffen werden kann, dann gibt es aus Sicht des Clients zwei Möglichkeiten: Er kann die Verbindung beenden oder ein eventuell manipuliertes oder ungültiges Zertifikat akzeptieren. Die Entscheidung, was in solchen Fällen zu tun ist, sollte mit den Sicherheitsrichtlinien der Institution in Einklang stehen.

Session Renegotation und TLS-Kompression

Clientseitig sollte die Session Renegotiation deaktiviert werden. Allgemeine Informationen zur Funktionsweise von Session Renegotiation sind in M 5.177 Serverseitige Verwendung von SSL/TLS zu finden.

TLS bietet die Möglichkeit, die übertragenen Daten vor der Verschlüsselung zu komprimieren. Dies kann dazu führen, dass Seitenkanalangriffe auf die Verschlüsselung über die Länge der verschlüsselten Daten, durchgeführt werden. Ein Beispiel hierfür ist CRIME (Compression Retro Info-leak Made Easy), ein 2012 vorgestellter Seitenkanal-Angriff, der das Ziel hat, eine HTTPS -Sitzung zu übernehmen. Um dies zu verhindern, sollte die TLS-Kompression deaktiviert werden.

Hinweis: Beim Einsatz von SSL/TLS ist zu beachten, dass verschlüsselte Daten hinsichtlich aktiver Inhalte und Schadprogramme nicht zentral, also z. B. am Sicherheitsgateway, überprüft werden können. Dies muss bei der Sicherheitskonzeption berücksichtigt werden, damit keine Sicherheitslücken entstehen. Weitere Empfehlungen hierzu finden sich unter anderem im Baustein B 1.6 Schutz vor Schadprogrammen .

Prüffragen:

  • Unterstützen die eingesetzten Client-Produkte eine sichere Version von SSL / TLS ?

  • Ist sichergestellt, dass die eingesetzten Clients kryptographische Algorithmen und Schlüssellängen verwenden, die dem Stand der Technik und den Sicherheitsanforderungen der Institution entsprechen?

  • Wird die Sicherheitsrichtlinie der jeweiligen Zertifizierungsstellen geprüft, bevor sicherheitskritische Informationen über eine SSL / TLS -geschützte Verbindung übertragen werden?

  • Wird auch bei der Nutzung von SSL / TLS ein ausreichender Schutz vor Schadprogrammen und unerlaubten aktiven Inhalten gewährleistet?

  • Wird darauf geachtet, dass neue Zertifikate erst nach Überprüfung des "Fingerprints" aktiviert werden?

  • Ist sichergestellt, dass die Validierung von Zertifikaten den Sicherheitsrichtlinien der Institution entspricht?

  • Sind Session Renegotiation und TLS-Kompression deaktiviert?

Stand: 14. EL Stand 2014