SSL - Secure Socket Layer

SSL ist ein Protokoll, das der Authentifizierung und Verschlüsselung von Internetverbindungen dient. SSL schiebt sich zwischen die Anwendungsprotokolle und den Transportprotokollen. Ein typisches Beispiel für den Einsatz von SSL ist der gesicherte Abruf von vertraulichen Daten über HTTP und die gesicherte Übermittlung von vertraulichen Daten an den HTTP-Server. In der Regel geht es darum, die Echtheit des kontaktierten Servers durch ein Zertifikat zu garantieren und die Verbindung zwischen Client und Server zu verschlüsseln.
SSL ist äußerst beliebt und das Standard-Protokoll bzw. die Erweiterung für Anwendungsprotokolle, die keine Verschlüsselung für sichere Verbindungen mitbringen.

Hinweis: Das ursprüngliche SSL ist inzwischen veraltet und in TLS aufgegangen. Obwohl man heute in der Regel TLS verwendet spricht man trotzdem immer noch von SSL.

SSL oder TLS?

SSL wurde ursprünglich von Netscape in den 90er Jahren für den Browser "Netscape Navigator" entwickelt und war lange Zeit "der Standard" für die Verschlüsselung von Internet-Verbindungen. Die Weiterentwicklung von SSL wurde mit der Version 3 beendet. Die IETF hat SSL 3.0 übernommen, ein paar Änderungen vorgenommen und als neuen und zu SSL inkompatiblen Standard mit der Bezeichnung TLS spezifiziert (SSL Version 3.1).
Vielfach haben bis heute Funktionen in Software und Bibliotheken immer noch die Bezeichnung SSL im Namen, obwohl sie TLS verwenden. Deshalb ist es heute immer noch üblich von SSL zu sprechen, obwohl man eigentlich die technische Implementierung von TLS meint.
In der Praxis ist es aber völlig unerheblich ob man SSL oder TLS sagt.

SSL/TLS im OSI-Schichtenmodell

Anwendung HTTP, FTP, SMTP, POP, IMAP, ...
Transport SSL/TLS
TCP / UDP
Vermittlung IPv4 / IPv6
Netzzugang Ethernet (LAN), IEEE 802.11 (WLAN), ...

Im OSI-Schichtenmodell ist SSL bzw. TLS auf Schicht 5, der Sitzungsschicht angeordnet. Im DoD-Schichtenmodell, das für TCP/IP verwendet wird, ist SSL/TLS auf der Transportschicht als Transportverschlüsselung über TCP und unterhalb der Anwendungsprotokolle zugeordnet. Dabei arbeitet SSL/TLS völlig transparent. So können theoretisch alle denkbaren Anwendungsprotokolle SSL zum Verschlüsseln benutzen. Dabei muss aber jedes Anwendungsprotokoll SSL bzw. TLS explizit beherrschen.
So wird beispielsweise aus dem unverschlüsselten HTTP (Hypertext Transfer Protocol) das verschlüsselte HTTPS (Hypertext Transfer Protocol Secure). Ebenso ist es möglich E-Mails über SSL beim POP-Server verschlüsselt abzurufen oder an den SMTP-Server verschlüsselt zu übermitteln. Auch hier bekommen die Protokolle einen "Secure"-Zusatz (SMTPS, POPS, IMAPS).
SSL ist inzwischen nicht nur auf HTTPS oder andere Kommunikationsprotokolle beschränkt. Verfahren wie EAP-TLS, EAP-TTL, PEAP und auch das LDAP-Protokoll verwenden SSL.

Anwendungsbeispiel: HTTPS

SSL ist eine optional aktivierbare Sicherheitskomponente für HTTP und ist somit für Webseiten gedacht, die vertrauliche Daten verarbeiten. Zum Beispiel beim Online-Banking oder Online-Shopping. Diese Webseiten bauen in der Regel automatisch eine verschlüsselte Verbindung zwischen Browser und Webserver auf. Der User bekommt das nur mit, wenn ein Schloss- oder Schlüssel-Symbol in der Statusleiste eingeblendet wird oder die Adresszeile ihre Farbe ändert.

Funktionsweise von SSL/TLS

SSL - Secure Socket Layer

Bestandteil von SSL ist die Zertifizierung (1.) des öffentlichen Schlüssels, die Authentifizierung des Servers (2.), die Validierung des übermittelten Zertifikats (3.) und die anschließende verschlüsselte Übertragung von Daten zwischen Sender und Empfänger.
Für die Authentifizierung werden Zertifikate verwendet. Unter anderem um das Verteilungsproblem von Authentifizierungsinformationen zu beheben und um Identitäten zu authentifizieren. Hierbei geht es darum, die Authentizität der Gegenstelle zweifelsfrei feststellen zu können.

Zertifikate

Eine Verschlüsselung besteht aus der Verschlüsselung der Daten beim Sender und der Entschlüsselung der Daten beim Empfänger. Bei SSL bzw. TLS arbeitet man mit zwei unterschiedlichen Schlüsseln zur Ver- und Entschlüsselung. Das sogenannte Schlüsselpaar besteht aus einem privaten (Private Key) und einem öffentlichen Schlüssel (Public Key). Der öffentliche Schlüssel des Empfängers ist dem Sender bekannt. Er benutzt ihn zum Verschlüsseln der Daten. Anschließend können die verschlüsselten Daten aber nicht mehr mit dem öffentlichen Schlüssel entschlüsselt werden. Dafür braucht es den privaten Schlüssel, der nur dem Empfänger bekannt sein darf und deshalb zwingend geheim gehalten werden muss. Nur der Server mit dem passenden privaten Schlüssel ist in der Lage die verschlüsselten Daten zu entschlüsseln (asymmetrisches Verschlüsselungsverfahren bzw. Public-Key-Verfahren).

Bevor nun der Sender Daten verschlüsseln darf, muss er jedoch zweifelsfrei feststellen, ob der öffentliche Schlüssel, den er vor der Verschlüsselung vom Empfänger mitgeteilt bekommt, auch tatsächlich dem Empfänger gehört, dem er die Daten verschlüsselt schicken will. Eine per SSL verschlüsselte Verbindung bietet keinen Schutz, wenn nicht sichergestellt ist, dass der öffentliche Schlüssel von dem Server kommt, zu dem eine verschlüsselte Verbindung hergestellt werden soll.
An der Stelle kommt jetzt das Zertifikat ins Spiel, mit dem sich ein Server und sein öffentlicher Schlüssel authentisieren. Um die Gültigkeit des öffentlichen Schlüssels zu unterstreichen, lässt sich der Server-Betreiber und Domain-Inhaber ein Zertifikat ausstellen, in dem unter anderem Domainname, der öffentliche Schlüssel ein Ablaufdatum enthalten sind und welche Instanz die Vertrauenswürdigkeit bestätigt hat.
Durch das Zertifikat authentisiert sich der Empfänger gegenüber dem Sender, bzw. der Server gegenüber dem Client. Gleichzeitig kann der Client das Zertifikat überprüfen (Validierung) und somit die Vertrauenswürdigkeit feststellen (Authentizität).

SSL-Zertifikat in der Browser-Ansicht

SSL bzw. TLS arbeitet mit PKIX-Zertifikaten bzw. mit einer Public Key Infrastructure nach X.509v3. Die Zertifikate koppeln eine Identität an einen öffentlichen Schlüssel, der zur Authentisierung und Verschlüsselung verwendet wird.
Es gibt insgesamt drei Zertifikatstypen, die sich durch einen unterschiedlichen Prüfaufwand haben bei der Zertifizierung unterscheiden und so eine entsprechend unterschiedliche Echtheitsstufe garantieren.

Die häufigsten Zertifikate sind DV- und EV-Zertifikate. Während man DV-Zertifikate schon für wenige Euro oder sogar kostenlos bekommen kann, kommen wegen des erheblichen Prüfaufwands bei EV-Zertifikaten mehrere hundert oder sogar tausend Euro zusammen. Allerdings kann man bei EV-Zertifikaten von einer höheren Vertrauenswürdigkeit ausgehen.

SSL-Verbindung im BrowserSSL-Verbindung im Browser
SSL-Verbindung im Browser
SSL-Verbindung im Browser

Welches Zertifikat bei einer verschlüsselten Verbindung zum Einsatz kommt, ist als Nutzer nicht so leicht zu erkennen. Meist ist eine verschlüsselte Verbindung in einem Client nur an einem Schloss-Symbol zu erkennen. Aber nicht, um was es sich für ein Zertifikat handelt.
Zertifikate werden von einer Zertifizierungsstelle bzw. Certification Authority (CA) ausgestellt und beglaubigt.

Certificate Authority (CA) / Zertifizierungsstelle

Weltweit gibt es weit über 700 Zertifizierungsstellen. Im Englischen auch Certificate Authority oder Certification Authority genannt. Meist mit CA abgekürzt.
Die Certificate Authorities (CA) sind ein wichtiger Pfeiler für die Sicherheit im Internet. Jeder, der sichere Dienste im Internet anbietet, lässt sich die Echtheit von digitalen Schlüsseln und Signaturen von Certificate Authorities bestätigen.

Dazu lässt sich ein Unternehmen oder eine Organisation von einer Certificate Authority nach einer Überprüfung ein digitales Zertifikat ausstellen. Das kann dann zum Beispiel auf einem Webserver hinterlegt werden. Mit diesem Zertifikat weist sich die Webseite gegenüber den zugreifenden Browsern als Eigentümer aus. Der Browser des Besuchers überprüft die Angaben im Zertifikat und fragt bei Bedarf bei der ausstellenden Zertifizierungsstelle nach, ob das Zertifikat gültig ist.
Auf diese Weise können zum Beispiel die Kunden einer Bank davon ausgehen, dass sie tatsächlich mit dem Server der Bank verbunden sind und das der Datenaustausch verschlüsselt erfolgt, wenn sie Online-Banking betreiben.

Auch die Zertifizierungsstelle besitzt ein Zertifikat, indem sich deren öffentlicher Schlüssel befindet. Dabei handelt es sich um ein Wurzel- bzw. Stammzertifikat, das in Browsern und Betriebssystemen hinterlegt ist. Diesen Stammzertifikaten wird in der Regel bedingungslos vertraut. Anhand der Signatur der Zertifizierungsstelle und dem Stammzertifikat kann ein Browser feststellen, ob das Zertifikat einer Domain wirklich von der angegebenen Zertifizierungsstelle ausgestellt wurde.

Das Geschäftsverhältnis zwischen Zertifizierungsinstanz und den Unternehmen, aber auch zu den Internet-Nutzern, beruht auf Vertrauen. Daher muss eine CA alles dafür tun, dass die Prüfprozesse ordnungsgemäß funktionieren und sicher vor Hackerangriffen sind.
Leider ist es schon vorgekommen, dass Eindringlinge auf interne Server von Zertifizierungsstellen zugegriffen und sich dort Zertifikate generiert haben. Wird ein solches Zertifikat verwendet, kann ein Internet-Nutzer einen Betrug nicht überprüfen. Und ein Unternehmen, dass Dienste im Internet anbietet, kann genauso wenig feststellen, ob eine Zertifizierungsstelle unberechtigt Zertifikate ausgestellt hat. Höchstens die CA kann betrügerische Zertifikate feststellen.
CAs sind also Treuhänder, die nur von ihrem guten Ruf leben. Sobald bekannt wird, dass eine CA Schindluder betreibt oder gehackt wurde, kann sie den Laden schließen.

SSL-Zertifizierung

SSL: Ablauf der Zertifizierung

Das Zertifikat wird von einer Zertifizierungsstelle, auch Certificate Authority (CA) genannt, ausgestellt. Die Zertifizierungsstelle signiert das Zertifikat mit ihrem eigenen privaten Schlüssel, womit die Echtheit der Daten bestätigt sind. Im Vorfeld prüft die Zertifizierungsstelle die Informationen im Zertifikat und die Identität des Antragstellers. Dafür gibt es verschiedene Verfahren. Beispielsweise den Certificate Signing Request (CSR).

CSR - Certificate Signing Request / Antrag zur Zertifizierung

Der Certificate Signing Request (CSR) ist ein gängiges Verfahren, um sich seinen öffentlichen Schlüssel von einer Zertifizierungsstelle signieren zu lassen. Davor erzeugt sich der Server-Betreiber ein Schlüsselpaar auf dem eigenen Server. Beispielsweise mit OpenSSL. Manche Zertifizerungsstellen sind auch in der Lage aus der Ferne die Schlüsselerzeugung auf dem Rechner des Kunden anzustoßen. Dafür bringen die Browser die notwendigen Kryptografieverfahren mit.
Der CSR bzw. der Antrag des Zertifikats erfolgt dann zum Beispiel per Webformular. Dabei muss man Angaben machen, die von der Zertifizierungsstelle geprüft und in das Zertifikat eingetragen werden. Nach der Ausstellung des Zertifikats kann der Kunde das Zertifikat und den privaten Schlüssel auf dem jeweiligen Server ablegen.

  1. Der Server-Betreiber erzeugt ein Schlüsselpaar, bestehend aus einem öffentlichen und privaten Schlüssel. Der private Schlüssel bleibt auf dem Server und wird geheim gehalten.
  2. Der Server-Betreiber stellt einen CSR für den öffentlichen Schlüssel an eine CA.
  3. Die CA prüft die Angaben des CSR und den öffentlichen Schlüssel.
  4. Ist alles korrekt, erstellt die CA ein Zertifikat und schickt es an den Server-Betreiber zurück.

Validierung eines Zertifikats

Bekommt ein Client oder Server von einem anderen Server ein Zertifikat, dann muss er sich von dessen Echtheit überzeugen. Also, ob das Zertifikat wirklich von dem Server kommt, der kontaktiert wurde.
Mit der Validierung eines Zertifikats wird die Identität bestätigt, ohne dass die beteiligten Kommunikationspartner vorab Authentifizierungsinformationen, wie zum Beispiel Schlüssel, austauschen müssen.

SSL: Ablauf der Validierung

Im folgenden Beispiel wird die Validierung exemplarisch für eine verschlüsselte HTTPS-Verbindung beschrieben. Grundsätzlich funktioniert die Validierung bei anderen Protokollen genauso.
Nachdem der Browser vom Webserver ein Zertifikat bekommen hat, beginnt er mit der Validierung. Der Browser prüft zuerst, ob er dem Aussteller des Zertifikats, der Zertifizierungsstelle oder Certificate Authority (CA), vertraut. Dazu muss das entsprechende Wurzelzertifikat der Zertifizierungsstelle im Browser hinterlegt sein (1. und 2.). Der Browser hat dazu eine Liste mit Zertifizierungsstellen, denen er per Default vertraut.
Im zweiten Schritt kontaktiert der Browser die angegebene Validierungsstelle bzw. Zertifizierungsstelle (3. und 4.). Diese prüft, ob das Zertifikat gültig ist und meldet das Ergebnis an den Browser zurück.
Sofern das Zertifikat bereits bekannt ist, ist eine Validierung über die Zertifizierungsstelle nicht mehr zwingend erforderlich.

Ablauf der Authentisierung

SSL: Ablauf der Authentifizierung
Beim ersten HTTPS-Request durch den Browser (Client) nutzt SSL die asymmetrische Verschlüsselung. Der Server schickt als erste Antwort seinen öffentlichen Schlüssel (Public Key) und ein Zertifikat. Auf diese Weise authentisiert sich der Webserver gegenüber dem Client. Schlüssel und Zertifikat werden vom Client auf Glaubwürdigkeit überprüft. Je nach Einstellung des Clients muss der Benutzer zuerst die Glaubwürdigkeit bestätigen.
Nach erfolgreicher Authentifizierung des Servers, generiert der Browser einen symmetrischen Schlüssel, den er mit dem öffentlichen Schlüssel des Servers verschlüsselt. Den symmetrischen Schlüssel schickt der Browser dann an den Server. Der Server kann das verschlüsselte Paket mit seinem privaten Schlüssel öffnen. Der darin enthaltene Schlüssel des Browsers nutzt der Server für die symmetrische Verschlüsselung der darauf folgenden Verbindung. Eine sichere Übertragung ist gewährleistet. Die Inhalt der HTTPS-Pakete sind gegen Belauschen und Veränderung geschützt.
Während der Datenübertragung zwischen Client und Server wird immer wieder ein neuer Schlüssel ausgehandelt, so dass ein möglicher Angreifer nur für eine kurze Zeit die Verbindung stören kann.

In der Regel authentifiziert sich der Client nicht. Die Möglichkeit der beiderseitigen Authentifizierung per Signatur ist als Option in der SSL-Spezifikation enthalten. In der Regel muss nur bei einem SSL-VPN auch der Client seine Identität mit einem Zertifikat ausweisen.
Die Benutzerauthentifizierung, sofern erforderlich, findet in der Regel auf der Anwendungsebene statt. Konkret bedeutet dass, der Kunden würde sich in einem Online-Shop registrieren und anmelden oder im Online-Banking mit Pin, Passwort und TAN identifizieren.

Implementierungen von SSL und TLS

Beim Einsatz von Implementierungen für SSL und TLS sollte man auf bewährte Lösungen setzen. Die Vertrauenswürdigkeit eines Implementierungen drückt sich dadurch aus, dass der Quellcode öffentlich ist. Dass man also prinzipiell die Möglichkeit hat den Quellcode auf Fehler und Hintertüren zu überprüfen. Zwar lässt sich bei bekannten und beliebten Bibliotheken nicht ausschließen, dass sie trotzdem Fehler und Lücken enthalten. Trotzdem ist hier die Wahrscheinlichkeit größer, dass doch mal jemand unabhängiges auf den Quellcode schaut.
In der Praxis sollte es eine Rolle spielen, wie aktiv eine Software oder ein Produkt gepflegt wird.

Wie sicher ist SSL/TLS?

Seit den Enthüllungen im Rahmen des NSA-Skandals im Sommer 2013 ist bekannt, dass SSL/TLS definitiv unsicher ist und nur eine unsichere Authentifizierung enthält, was zu einer nur bedingt wirksamen Verschlüsselung führt. Das Problem dabei ist nicht die Verschlüsselung an sich, sondern das Vertrauenskonzept, welches hierarchisch angeordnet ist.
Ein Geheimdienst, wie die NSA, der Google, Microsoft, Yahoo und Apple zur Zusammenarbeit zwingen kann, kann das auch bei einer Zertifizierungsstelle, wie sie bei SSL/TLS die zentrale Instanz für die Zertifizierung und Validierung von Identitäten bildet. Und deshalb gelten Zertifizierungsstellen, denen man bedingungslos vertrauen muss, als kompromittiert.

SSL/TLS ist also nicht wirklich sicher! Trotzdem kann man SSL/TLS als sicher ansehen. Doch das bedeutet nicht, dass es für alle Anwendungen und in Zukunft sicher genug ist. Das bedeutet, trotz Authentifizierung und Verschlüsselung muss man als Nutzer mit einer gewissen Unsicherheit leben.

SSL/TLS sicherer machen

Hinweis: Mit dem aktuellen Vertrauensmodell (Certificate Authority) ist es unmöglich die Authentifizierung und Verschlüsselung für alle Anwendungen sicher zu machen. Die einzige Möglichkeit besteht darin, Workarounds zu bauen, also Teilprobleme von SSL/TLS und dessen kaputtes Vertrauensmodell zu lösen, um die Sicherheit des System einigermaßen glaubhaft am Laufen zu halten.

Weil die Authentifizierung grundsätzlich defekt ist, versucht man wenigstens die Verschlüsselung so weit hinzubekommen, dass die Kommunikation rückwirkend nicht entschlüsselt werden kann. Diese Maßnahmen sind erforderlich, weil man weiß, dass Geheimdienste (bspw. die NSA) verschlüsselten Datenverkehr aufzeichnet. Anschließend versuchen Geheimdienste über offizielle Anordnungen die Herausgabe der Schlüssel zu fordern oder sich den Zugang zu den Schlüsseln anderweitig zu beschaffen.
Mit dem Einsatz von Perfect Forward Secrecy in Kombination mit Diffie Hellman kann man die Kommunikation rückwirkend nicht entschlüsseln. Deshalb wird für die verschlüsselte Übertragung von personenbezogenen oder anderen sensiblen Daten mit SSL bzw. TLS Perfect Forward Secrecy und Diffie-Hellman empfohlen.

Um TLS/SSL sicherer zu betreiben führt ebenfalls kein Weg an TLS Verion 1.2 vorbei. Seit TLS 1.1 ist ein Schutz gegen BEAST-Angriffe eingebaut und mit TLS 1.2 wurden bessere Verschlüsselungsverfahren eingeführt (seit 2009).
TLS 1.2 wird in der Standardkonfiguration von Internet Explorer, Firefox, Google Chrome, Opera und Apple Safari verwendet (Stand 02/2014).
Auch auf der Seite der Chipher-Suiten wird empfohlen entweder zu ECDSA oder zu RSA mit AES/GCM zu wechseln. Beides sind noch nicht offensichtlich gebrochene Cipher-Suiten.

Übersicht: SSL / TLS