immerda:SSL-Zertifikate

Aus immerda
(Weitergeleitet von SSL-Zertfikate)
Wechseln zu: Navigation, Suche

Grundkonzept

Wieso eine Verbindung per SSL absichern resp. verschlüsseln?

Die Struktur des Internets

Oftmals greifen wir im Internet auf Webseiten oder weitere Dienste (wie Mail oder immerda:Jabber) zu und übermitteln dabei vertrauliche Daten wie Passwörter, Gesprächsinhalte usw. Da das Internet grundsätzlich als ein Netzwerk von vielen verschiedenen beliebigen Knoten (Zur Illustration siehe folgendes Bild) anzusehen ist, werden die Daten die du an den Server schickst auch über verschiedene Knoten unterschiedlicher und unbekannter Herkunft sowie Kontrolle verschickt. Somit wäre es theoretisch möglich, dass auf jedem Knoten auf dem deine Daten vorbeikommen, diese aufgezeichnet und somit ausgelesen werden können. So könnten deine Passwörter oder Gesprächsinhalte in falsche Hände geraten und missbraucht werden. Um dies zu verhindern ist es wichtig, dass für die Übertragung von privaten und sensiblen Daten immer eine verschlüsselte und vertrauenswürdige Verbindung benützt wird. Damit kannst du sicherstellen, dass niemand zwischen dir (z.B. deinem Browser oder deinem Mailprogramm) und dem Server auf den du zugreifst (z.B. immerda-Webmail oder immerda-Jabberserver) irgendwelche Daten ausspähen kann.

Es ist unserer Meinung nach wichtig den Wert der Privatsphäre zu schützen!

Im folgenden werden wir verschlüsselte Verbindung als Synonym für eine per SSL abgesicherte Verbindung verwenden.

Wie kommt eine verschlüsselte Verbindung zustande?

Eine Verbindung deines Browsers (oder deines Email-, Jabberprogramms etc.) kann per SSL abgesichert werden. Es sind jedoch verschiedene Faktoren wichtig, damit eine verschlüsselte Verbindung zustande kommt und dieser auch zu trauen ist, sprich wirklich die komplette Verbindung zwischen dir und dem Server verschlüsselt abläuft.

Im folgenden nehmen wir als Beispiel den Zugriff auf https-gesichrte Webseiten (also z.B. das immerda-Webmail). Informationen dazu, wie du deine Emails sicher mit einem lokalen Mailprogramm abrufst, findest du dazu in der passenden Anleitung. Für immerda:Jabber können nur per SSL gesicherte Verbindungen aufgebaut werden, mehr dazu auch in der Jabber Anleitung.

https

Normalerweise beginnen die URLs mit http://... . Das http:// zeigt dabei an, das wir das HyperText Transfer Protokoll verwenden, jenes Protkoll welches beschreibt, wie auf Webseiten zugegriffen werden kann. Derartige Verbindungen sind immer unverschlüsselt und für alle Knoten zwischen dir und dem Server auf welchem die Seite liegt lesbar. Dh. einerseits ist ersichtlich auf was für eine Seite du zugreifst, anderseits auch was für eine Seite dir der Webserver zurück gibt, sprich der volle Inhalt dieser Seite.

Um nun per SSL gesichert auf eine Seite zuzugreifen verwenden wir eine Erweiterung des http-Prokolls: https (Infos). Das s zeigt dabei an, dass es sich um eine verschlüsselte Verbindung handelt. Ausserdem stellen die meisten Browser den Unterschied farblich und symbolisch (z.B. im Firefox per Schloss-Icon) in der Adresszeile dar. Vergleiche diese Screenshots von Firefox:

Keine verschlüsselte Verbindung:

Immerda url nonssl.png

Verschlüsselte Verbindung:

Immerda url ssl.png

Nur wenn wir eine verschlüsselte Verbindung haben, können wir sicher gehen, dass die Daten, welche wir übermitteln unterwegs nicht gelesen werden können!

Konsequenzen

Damit wir sicher gehen können, dass keine sensiblen Daten wie Passwörter oder private Informationen (wie Emails) zwischen uns und dem Server mitgelesen werden können, müssen wir bei der Eingabe von solchen Informationen immer darauf achten, dass wir mit einer gesicherten Verbindung (sprich per https) darauf zugreifen.

Deshalb: Niemals sensbile Daten auf einer Webseite eingeben, welche nicht per SSL/https gesichert ist.

Vertrauen

Doch wie können wir der verschlüsselten Verbindung vertrauen? Wie können wir sicherstellen, dass die Verbindung auch wirklich komplett zwischen uns und dem Server auf den wir zugreifen wollen verschlüsselt ist und nicht etwa jemand (ein sogenannter Man in the Middle dazwischen sitzt, uns die gesicherte Verbindung vorspielt und alles mitschneidet?

Man in the middle

Dazu musst du als Benutzerin irgendwie der aufgebauten verschlüsselten Verbindung vertrauen können, sprich du musst eine Möglichkeit haben die gesicherte Verbindung zu überprüfen. Dazu wurde die Technik von digitalen Zertifikaten entwickelt, welche die Möglichkeit bietet die Authentizität einer Verbindung zu überprüfen.

Hier kommen nun Zertifizierungsstellen ins Spiel, welche als sogenannte Trusted Third Parties ein ausgestelltes Zertifikat, welches zum Aufbau der sicheren Verbindung verwendet wird, beglaubigen sollen. Dh. diese sollen sicherstellen, dass das Zertifikat auch wirklich von derjenigen Person ausgestellt wurde, welche vorgibt die jeweilige zu sein. Damit kannst du sicherstellen, dass du die verschlüsselte Verbindung auch wirklich dorthin aufbaust, wohin du auch annimmst (z.B. durch Eingabe der URL), dass du sie aufbaust.

Jedes gültige Zertifikat wird von einer Zertifizierungsstelle beglaubigt, sprich unterschrieben und kann dadurch automatisch durch deinen Browser auf dessen Gültigkeit überprüft werden. Damit dein Browser dies überprüfen kann, muss er das Root-Zertifikat derjenigen Zertifizierungsstelle importiert haben, die das Zertifikat unterschrieben hat. Für das detailierte Konzept dahinter siehe den Beschrieb zur Public-Key Infrastruktur.

Dies funktioniert folgendermasssen: Ein Admin, der seinen Server per SSL absichern möchte, schickt einen Teil seines Zertifikates (den Zertifizierungsrequest) an diese Zertifizierungsstelle. Diese Überprüft dann die Idendität des Admins und unterschreibt anschliessend den Zertifikatsrequest. Damit bürgt die Zertifizierungsstelle mit ihrem Konzept der Überprüfung, dass das Zertifikat auch wirklich von derjenigen Person stammt für die sie sich ausgibt. Dein Browser überprüft diese Unterschrift beim Verbindungsaufbau. Stellt dieser ein Problem fest, oder kann er das Zertifikat nicht überprüfen, wird er dich mit einer Meldung belästigen. Ansonsten wirst du keine Meldung zu Gesicht bekommen und du kannst der Verbindung vertrauen.

Root-Zertifikate / Zertifizierungsstellen

Dies bedeutet, dass dein Browser (oder Mail-, Jabberprogramm usw.) ja irgendwie die Root-Zertifikate haben muss, damit es die Authentizität des jeweiligen Server-Zertifikats überprüfen kann. Dabei kommen uns die Browserhersteller zu Hilfe und haben bereits einige Root-Zertifikate von Zertifizierungsstellen, die sie für Vertrauenswürdig halten, fix importiert. Damit nehmen sie uns einerseits die Mühe ab, dass wir all die Root-Zertifikate selber zusammensuchen müssen, anderseits geben sie uns dadurch auch vor, wem wir (blind) zu Vertrauen haben.

So ist auch der Prozess, welcher dazu führt, das Zertifizierungsstellen aufgenommen werden, vor allem mit einem finanziellen Aufwand verbunden, welchen sich unkommerielle Zertifizierungsstellen leider kaum leisten können. Seit 2016 gibt es nun jedoch eine Zertifizierungsstelle Let's encrypt, welche eine kostenlose Signierung von Zertifikaten ermöglicht und von allen gängigen Browsern und Systemen zur Validierung der Zertifikaten akzeptiert wird. Wir haben begonnen diese Zertifizierungsstelle in unsere Systeme einzupflegen und verwenden nun diese für die meisten Domains. Mehr informationen dazu findest du in unserem Blogartikel dazu.

Eine frühere Variante, welche wir verfolgten, war unsere eigene CA zu etablieren und für unsere Services zu verwenden. Zertifikate, die durch diese CA signiert sind, werden jedoch nicht einfach so für gültig erklärt, weil unsere CA ja nicht in den Browsern vorhanden ist. Dieser Umstand kann geändert werden indem wir das Root-Zertifikat der jeweiligen Zertifizierungsstelle importieren. Damit kann dann unser Browser die Verbindung überprüfen und wir können sicher gehen, das wir auch wirklich eine gültige Verbindung aufgebaut haben. Dieses Problem stellt sich insbesondere bei unseren eigenen CA, da wir nicht vor haben in die allgemeinen Browsern aufgenommen zu werden. Damit Zertifikate, die durch unsere CA signiert wurden, korrekt akzeptiert werden müsst ihr also unsere CA bei euch importieren. Eine Anleitung wie das funktioniert findet ihr hier.

Konsequenzen / Zusammenfassung

Beispiel eines nicht Vertrauenswürdigen Zertifikats

Abschliessend kann gesagt werden, dass wir einer verschlüsselten Verbindung auf einer Seite nur trauen können, wenn der Browser (nach allfälligem Import des Root-Zertifikats) keine Warnmeldung ausgibt und dieser die Verbindung somit als vertrauenswürdig gesichert ansieht. Wir können das Zertifikat natürlich auch über einen anderen Weg überprüfen, wie z.B. mit Hilfe eines publizierten Fingerprints des Zertifikats (Immerda Zertifikate Fingerprints).

Allen verschlüsselten Verbindungen, bei denen der Browser (oder andere Programme) eine Warnmeldung ausgibt, ist nicht zu trauen resp. sind mit äusserster Vorsicht zu geniessen. Ihr solltet dann die Meldung (siehe Bild) des Browsers genau durchlesen und ggf. den Verbindungsaufbau abbrechen. Wir empfehlen den Abbruch einer verschlüsselten Verbindung vor allem dann, wenn ihr bisher beim gesichrten Zugriff auf die Seite nie eine Meldung bekommen habt.

Um den Zugriff auf die meisten Immerda Seiten zu überprüfen musst du das Root-Zertifikat der immerdaCA in deinen Browser importieren. Eine Anleitung dazu findest du hier.