Zertifikate, SSL, TLS und HTTPS – ein Crashkurs

Wir sind an dem Thema SSL, TLS, https, Zertifikate und Verschlüsselungsprotokolle so oft "vorbeigeschrammt", dass ich mal näher darauf eingehen muss. Leider ist das wie so oft "nicht so einfach" und falls Sie sich noch nie wirklich mit dem Thema beschäftigt haben, sollten Sie einen Moment innehalten und versuchen die Zusammenhänge zu verstehen. Hier ein kurzer Crashkurs mit wichtigen Begriffen und kurzen Erklärungen.

SSL/TLS

SSL ist die Abkürzung für Secure Sockets Layer und ist ein Verschlüsselungsprotokoll für die Datenübertragung im Internet. Bis zur Version 3.0 heisst es SSL, alle Versionen danach heissen TLS (Transport Layer Security). Diese Umbenennung fand schon im Jahr 1999 statt. Die Version TLS 1.0 entspricht der Version SSL 3.1. Die aktuelle Version von TLS ist 1.2.In Zukunft und im weiteren Verlauf dieses Blogeintrags werde ich die Bezeichnung TLS verwenden.

Verschlüsselungsprotokoll und Schlüsselverteilungsproblem

Ein Verschlüsselungsprotokoll ist eine besondere Art des Netzwerkprotokolls. Eine grosse Herausforderung bei allen Verschlüsselungsverfahren ist das Schlüsselverteilungsproblem. Beide Teilnehmer müssen einen Schlüssel besitzen, um die Nachrichten zu ver- bzw. zu entschlüsseln.Die einzige Möglichkeit verschlüsselt zu kommunizieren war lange Zeit die Übersendung des Schlüssels per Boten oder eben ihn persönlich zu überbringen!Um diesen Aufwand zu vermeiden wurden in den siebziger Jahren des letzten Jahrhunderts symetrische und asymetrische Verschlüsselungsverfahren entwickelt.

Symmetrisches Verfahren

Beim symmetrisches Verfahren kommunizieren beide Partner mit demselben Schlüssel. Die Schlüssel müssen also sicher übertragen werden.

Asymmetrisches Verfahren

Beim asymetrischen Verfahren, auch Public-Key Verfahren genannt, erzeugt ein Benutzer ein Schlüsselpaar, das aus einem geheimen (private) und einem öffentlichen (public) Schlüssel besteht. Der öffentliche Schlüssel kann "öffentlich" ausgetauscht werden. Er ermöglicht es jedem, Daten für den Inhaber des privaten Schlüssels zu verschlüsseln. Nur der Besitzer des geheimen Schlüssels kann diese Daten wieder entschlüsseln.

Damit entfällt die "komplizierte, geheime" Übertragung des Schlüssels. Der öffentliche Schlüssel kann bedenkenlos geteilt werden werden und das Schlüsselverteilungsproblem ist gelöst.

Aber:

Um das Schlüsselpaar zu erzeugen, benötigt man eine zufällige Zahl. Und Zufall ist nicht ganz einfach zu erzeugen auf einem Computer. Normalerweise benutzt man dafür einen Zufallszahlengenerator (ein Stück Software). Diese Zufallszahlengenratoren können manipuliert werden (Beispiel 1, Beispiel 2). Im Artikel Ein Backup mit Duply hatten wir bereits das Problem mit der Entropie (dem Zufall).

Zweites aber:

Da der öffentliche Schlüssel jedem zur Verfügung steht, ist nicht sicher gestellt, dass genau dieser öffentliche Schlüssel auch dem gewünschten Empfänger zugeordnet werden kann. An dieser Stelle kommen digitale Zertifikate ins Spiel, die den öffentlichen Schlüssel einem privaten Schlüsselinhaber zuordnen, also gewissermassen zertifizieren, dass der öffentliche Schlüssel zu der entsprechenden Person oder Firma gehört.

Drittes aber:

Die asymetrische Verschlüsselung ist langsamer im Vergleich zur symmetrischen Verschlüsselung.

TLS kombiniert beide Verfahren

TLS ist ein hybrides Protokoll, es kombiniert symmetrische und asymmetrische Verfahren.TLS funktioniert folgendermassen:

1. Ein Client baut eine Verbindung zum Server auf (Aufruf von https://... im Browser)
2. Der Server schickt dem Client sein Zertifikat
3. Der Client überprüft ob Zertifikat und Servername zusammenpassen und schickt dem Server entweder eine mit dem öffentlichen Schlüssel des Servers verschlüsselte Zufallszahl oder beide Parteien berechnen ein gemeinsames Geheimnis (Diffie Hellman Schlüsseltausch)
4. Aus der Zufallszahl oder dem Geheimnis wird ein Schlüssel berechnet, der dann beiden Parteien zur Verfügung steht und die dann folgende Kommunikation schützt (symmetrisches Verfahren).

Implementierungen des Protokolls finden sich in den Bibliotheken OpenSSL und GnuTLS.

Wichtige Anwendungsfälle für TLS, die auch hier im Blog immer wieder vorkommen, sind die Protokolle HTTP, POP3, SMTP, NNTP, SIP, IMAP, XMPP, IRC, LDAP, FTP und OpenVPN.

Hinweis: In diesem Zusammenhang haben Sie bestimmt schon vom Heartbleed-Bug gehört. Bei diesem "Fehler" konnte ein "Angreifer" über Jahre den Arbeitspeicher der beteiligten Partner auslesen und dort private Schlüssel, Benutzernamen und Passworte abgreifen. Der Web Comic xkcd erklärt Heartbleed sehr anschaulich:

HTTP und HTTPS

TLS-Verschlüsselung wird zum grössten Teil zur Absicherung des HTTP Protokolls verwendet. HTTP steht für Hypertext Transfer Protocol und ist das unverschlüselte Kommunikationsprotokoll im WWW. Wenn die Kommunikation über HTTP und TLS abgewickelt wird, spricht man vom HTTPS Protokoll (Hypertext Transfer Protocol Secure).Wenn Sie beispielsweise Websites über das unverschlüsselte HTTP Protokoll

• in einem ungesicherten WLAN ansehen, kann der Klartext Ihrer Kommunikation von jedem "Angreifer" in Reichweite des WLANs mitgelesen werden.
• in einem kabelgebundenen Netz oder verschlüsseltem WLAN ansehen, kann der Klartext von allen Teilnehmern des Netzes mitgelesen werden.

Wenn Sie Ihre Kommunikation über HTTP/TLS, also HTTPS abwickeln, so ist ein Mitlesen zwar möglich, aber der Netzwerkverkehr ist verschlüsselt und kann nicht "einfach so" entschlüsselt werden.

Digitale Zertifikate

Ein digitales Zertifikat bestätigt bestimmte Eigenschaften von Personen und Objekten. Sie können Zertifikate selbst erzeugen oder bei einer Zertifizierungsstelle kaufen. Die technischen Vorgänge sind bei selbst zertifizierten und bei gekauften Zertifikaten die gleichen. Sie sind also "gleich sicher". Der Unterschied besteht im Vertrauen in den Austeller des Zertifikats. Wenn Sie mit eine HTTPS Verbindung mit unserem Testserver herstellen (https://serverblogger.ch), erhalten Sie die Meldung Invalid Certificate.

Je nach Browsertyp erhalten Sie eine ähnliche Meldung. Der Text ist etwas irreführend. Das Zertifikat ist nicht ungültig, sondern einfach selbst zertifiziert. Die Situation ist ein vergleichbar mit einem Zertifikat über Ihren Bildungsstand. Sie könnten sich selbst zertifizieren, dass Sie einen bestimmten Kenntnisstand oder Bildungsabschluss haben. Die meisten Menschen würden dieser Bestätigung vermutlich wenig Glauben schenken (auch wenn sie wahr ist). Wenn dagegen eine dritte Instanz, wie die entsprechende Schule oder Ausbildungsstätte Ihren Kenntnisstand bestätigt, sieht die Sache schon ganz anders aus.

Wenn Sie auf die Website https://www.nsa.gov gehen, so vertraut Ihr Browser dem Zertifikat.

Es wurde von der Zertifizierungsstelle Geo Trust ausgegeben und ist gültig bis zum 02.12.2015. Ihr Browser ordnet das Zertifikat als gültig ein und stuft damit die Site als vertrauenswürdig ein. Damit ein Browser unterscheiden kann, welcher Zertifizierungsstelle er vertraut, und welcher nicht, schaut er einfach in eine Liste der Zertifizierungsstellen. Im Firefox Browser finden Sie die Liste der Authorities in den Sicherheitseinstellungen oder online hier.

Ihr Browser vertraut allen dort gelisteten Unternehmen! Sie können die Liste allerdings bearbeiten und einzelne Zertifizierungsstellen löschen. Das machen allerdings die wenigsten Menschen. Wenn Sie einen Root-Server betreiben und ganz normale Menschen mit ganz normalen Browsern Ihre Services nutzen, haben Sie keine echte Wahl.

Sie müssen ein Zertifikat kaufen, ansonsten gibt es den Fehlerhinweis im Browser Ihres Kunden und vermutlich wird er Ihre Site daraufhin nicht benutzen!

Die Zertifizierungsstellen sind wieder ähnlich wie beim Schulbeispiel - es gibt gute und schlechte Schulen und man kann sich natürlich auch Doktortitel kaufen. Bei den Zertifikaten ist es manchmal ebenso (Beispiele hier, hier und hier). Wegen der mangelnden Vertrauenswürdigkeit einiger Zertifizierungsstellen wird seit Anfang 2010 die Sicherheit von TLS grundsätzlich angezweifelt (Heise: EFF zweifelt an Abhörsicherheit von SSL). Durch die Deaktivierung fragwürdiger Zertifizierungsstellen im eigenen Browser lässt sich das Risiko jedoch weitgehend beseitigen.

Auch wenn das Zertifikatssystem weder perfekt, noch wirklich sicher ist, ist es der einzige Mechanismus, der momentan in der Masse zur Verfügung steht. Man kann es vielleicht mit dem Geschäftsmodell vieler Kreditkartenfirmen vergleichen. Es ist einfacher für diese Firmen einen finanziellen Schaden, den der Kunde im Einzelfall hatte, auszugleichen, als von Anfang an für bessere Sicherheit zu sorgen.Damit Sie nun nicht völlig den Glauben an die Sicherheit verlieren, ein kleiner Hoffnungsschimmer.

Jede noch so nachlässig implementierte verschlüsselte Verbindung ist ein Quentchen besser als eine unverschlüsselte Verbindung.

Unterschiedliche Arten von Zertifikaten (blau und grün)

Um die Sache noch etwas spannender zu gestalten, gibt es unterschiedliche Arten von Zertifikaten. Ausser der Stärke der Verschlüsselung ist das in erste Linie die Domain- oder die Identitätsprüfung.Bei der Domainprüfung gibt es Single, Wildcard und Multidomain Zertifikate. Single Zertifikate umfassen genau eine Domain, Wildcard Zertifikate die Hauptdomain und alle Subdomains, Multidomain-Zertifikate umfassen mehrere Domains. Überprüft wird von der Zertifizierungsstelle, ob der Auftraggeber der Inhaber der Domain ist. Dazu wird automatisiert eine E-Mail an den administrative Adresse im Whois Eintrag geschickt. Diese E-Mail muss auf unterschiedliche Art bestätigt werden. Der Vorgang geht innerhalb kurzer Zeit (Minuten) und man erkennt es auch im Browser (Domain Validation).

Hier ein Beispiel für ein wohl vergessenes Multidomain Zertifikat, dass zum Einsatz kommt, wenn ich die BMW Site über HTTPS aufrufe (https://www.bmw.com/). Das Zertifikat ist nicht für diese Domain zertifiziert.

Bei der Identitätsprüfung einer Organisation wird ausser der Domainprüfung auch ein Handelsregisterauszug verlangt und teilweise telefonisch Kontakt aufgenommen. Bei einer erweiterter Prüfung (Extended Validation Certificate) wird ausserdem eine grüne Addresszeile im Browser angezeigt .

Schauen Sie sich mal die Zertifikate der Websites an, mit denen Sie regelmässig Kontakt haben.

tl;dr: Jeglicher Netzwerkverkehr sollte, wenn möglich, über TLS abgewickelt werden um ein Mindestmass an Abhörsicherheit zu gewährleisten. Als Betreiber eines Root-Servers sollten Sie sich ein Zertifikat von einer Zertifizierungsstelle installieren oder installieren lassen, der die gängigen Browser und damit auch Ihre Kunden vertrauen.