immerda:SSL-Zertifikate: Unterschied zwischen den Versionen

Aus immerda
Zur Navigation springen Zur Suche springen
K (hat „SSL-Zertfikate“ nach „SSL-Zertifikate“ verschoben)
Zeile 5: Zeile 5:
 
</div>
 
</div>
 
[[Bild:The internet structure.png|thumb|right|background-color:#dfefdf|Die Struktur des Internets]]
 
[[Bild:The internet structure.png|thumb|right|background-color:#dfefdf|Die Struktur des Internets]]
Oftmals greifen wir im Internet auf Webseiten oder weitere Dienste (wie Mail oder [[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:The internet structure.png|Bild]]) werden die Daten die du an den Server schickst über verschiedene Knoten unterschiedlicher und unbekannter Herkunft wie 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 somit misbraucht werden. Um dies zu verhindern ist es wichtig, dass für die Übertragung von privaten und sensiblen Daten '''immer''' eine verschlüsselte Verbindung benützt wird. Damit kannst du sichergehen, 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 [[Sicherheit:immerda#Der_Wert_des_Privatlebens|Wert der Privatsphäre]] zu schützen!
+
Oftmals greifen wir im Internet auf Webseiten oder weitere Dienste (wie Mail oder [[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:The internet structure.png|Bild]]) anzusehen ist, werden die Daten die du an den Server schickst auch über verschiedene Knoten unterschiedlicher und unbekannter Herkunft wie 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 somit 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 [[Sicherheit:immerda#Der_Wert_des_Privatlebens|Wert der Privatsphäre]] zu schützen!
  
 
Im folgenden werden wir verschlüsselte Verbindung als Synonym für eine per [http://de.wikipedia.org/wiki/Transport_Layer_Security SSL] abgesicherte Verbindung verwenden.
 
Im folgenden werden wir verschlüsselte Verbindung als Synonym für eine per [http://de.wikipedia.org/wiki/Transport_Layer_Security SSL] abgesicherte Verbindung verwenden.
Zeile 11: Zeile 13:
 
== Wie kommt eine verschlüsselte Verbindung zustande? ==
 
== Wie kommt eine verschlüsselte Verbindung zustande? ==
  
Eine Verbindung deines Brwosers (oder deines Email- Jabberprogramms etc.) kann per [http://de.wikipedia.org/wiki/Transport_Layer_Security SSL] abgesichert werden, dazu 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.
+
Eine Verbindung deines Brwosers (oder deines Email-, Jabberprogramms etc.) kann per [http://de.wikipedia.org/wiki/Transport_Layer_Security 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. Wie du deine Emails sicher mit einem lokalen Mailprogramm abrufst siehe hier in der [[IMAP/POP/SMTP:immerda|Anleitung]], für [[Jabber]] können nur per ssl gesicherte Verbindungen aufgebaut werden, mehr dazu auch in der [[Jabber|Anleitung]].
+
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 [[IMAP/POP/SMTP:immerda|Anleitung]]. Für [[Jabber]] können nur per ssl gesicherte Verbindungen aufgebaut werden, mehr dazu auch in der [[Jabber|Jabber Anleitung]].
  
 
===https===
 
===https===
  
Normalerweise beginnen die die [http://de.wikipedia.org/wiki/URL URLs] mit http://... . Das http:// zeigt dabei an, das wir das [http://de.wikipedia.org/wiki/HTTP HyperText Transfer Protokol] 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. Sprich 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 den vollen Inhalt dieser Seite.
+
Normalerweise beginnen die die [http://de.wikipedia.org/wiki/URL URLs] mit http://... . Das http:// zeigt dabei an, das wir das [http://de.wikipedia.org/wiki/HTTP 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. Sprich 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 den vollen Inhalt dieser Seite.
  
Um nun per ssl gesichert auf eine Seite zuzugreifen verwenden wir eine erweiterung des [http://de.wikipedia.org/wiki/HTTP http]-Prokolls: http'''s''' ([http://de.wikipedia.org/wiki/HTTPS Infos]). Das s zeigt dabei an, dass es sich um eine verschlüsselte Verbindung handelt, zudem stellen die meisten Browser den Unterschied farblich und symbolisch (z.B. Firefox Schloss-Icon) in der Adresszeile dar. Vergleiche diese Screenshots von Firefox:
+
Um nun per ssl gesichert auf eine Seite zuzugreifen verwenden wir eine erweiterung des [http://de.wikipedia.org/wiki/HTTP http]-Prokolls: http'''s''' ([http://de.wikipedia.org/wiki/HTTPS Infos]). Das '''s''' zeigt dabei an, dass es sich um eine verschlüsselte Verbindung handelt, zudem 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:
 
Keine verschlüsselte Verbindung:
Zeile 29: Zeile 31:
 
[[Bild:Immerda url ssl.png]]
 
[[Bild:Immerda url ssl.png]]
  
Nur wenn wir eine derartige Verbindung haben, können wir sicher gehen, dass die Daten, welche wir Übermitteln unterwegs nicht gelesen werden können!
+
Nur wenn wir eine derartige Verbindung haben, können wir sicher gehen, dass die Daten, welche wir Übermitteln unterwegs '''nicht''' gelesen werden können!
  
 
== Konsequenzen ==
 
== 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 derartigen Informationen '''immer''' darauf achten, dass wir mit einer gesicherten Verbindung darauf zugreifen.
+
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 derartigen 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 gesichert ist.
+
'''Deshalb:''' Niemals sensbile Daten auf einer Webseite eingeben, welche nicht per SSL/https gesichert ist.
  
 
= Vertrauen =
 
= 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 [http://de.wikipedia.org/wiki/Man-in-the-middle-Angriff Man-in-the-Middle] dazwischen sitzt, uns die gesicherte Verbindung vorgaukelt und alles mitschneidet?
+
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 [http://de.wikipedia.org/wiki/Man-in-the-middle-Angriff Man in the Middle] dazwischen sitzt, uns die gesicherte Verbindung vorspielt und alles mitschneidet?
  
 
[[Bild:M-i-m.png|right|thumb|Man in the middle]]
 
[[Bild:M-i-m.png|right|thumb|Man in the middle]]
  
Dazu musst du als Benutzerin ja irgendwie der aufgebauten verschlüsselten Verbindung vertrauen können, resp. überprüfen können ob dieser Verbindung auch wirklich zu vertrauen ist. Dazu wurde die Technik von [http://de.wikipedia.org/wiki/Digitales_Zertifikat digitalen Zertifikaten] entwickelt, welche die Möglichkeit bieten den Aufbau einer Verbindung zu überprüfen.
+
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 und ob dieser auch wirklich zu vertrauen ist. Dazu wurde die Technik von [http://de.wikipedia.org/wiki/Digitales_Zertifikat digitalen Zertifikaten] entwickelt, welche die Möglichkeit bieten die [http://de.wikipedia.org/wiki/Authentizit%C3%A4t Authentizität] einer Verbindung zu überprüfen.
 +
 
 +
Hier kommen nun [http://de.wikipedia.org/wiki/Zertifizierungsstelle Zertifizierungsstellen] ins Spiel, welche als sogenannte [http://de.wikipedia.org/wiki/Trusted_Third_Party Trusted Third Parties] ein ausgestelltes Zertifikat, welches zum Aufbau der sicheren Verbindung verwendet wird, beglaubigen sollen. Sprich sie 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.
  
Hier kommen nun [http://de.wikipedia.org/wiki/Zertifizierungsstelle Zertifizierungsstellen] ins Spiel, welche als sogenannte Trusted-Third-Parties ein ausgestelltes Zertifikat, welches zum Aufbau der sicheren Verbindung verwendet wird, beglaubigen sollen, resp. sicherstellen, dass es auch wirklich von derjenigen Person ausgestellt wurde, welche auch vorgibt die jeweilige zu sein. D.h. jedes '''gültige''' Zertifikat wird von einer Zertifizierungsstelle beglaubigt resp. unterschrieben und kann so automatisch durch den Browser auf dessen Gültigkeit überprüft werden. Damit dein Browser dies überprüfen kann, muss er das Root-Zertifikat dieser Zertifizierungsstelle importiert haben. Für das detailierte Konzept dahinter siehe den Beschrieb zur [http://de.wikipedia.org/wiki/Public_Key_Infrastructure Public-Key-Infrastruktur].
+
Jedes '''gültige''' Zertifikat wird von einer [http://de.wikipedia.org/wiki/Zertifizierungsstelle 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 [http://de.wikipedia.org/wiki/Zertifizierungsstelle Zertifizierungsstelle] importiert haben, die das Zertifikat unterschrieben hat. Für das detailierte Konzept dahinter siehe den Beschrieb zur [http://de.wikipedia.org/wiki/Public_Key_Infrastructure Public-Key Infrastruktur].
  
Ein Admin, welcher seinen Server per SSL absichern möchte, schickt einen Teil seines Zertifikates an diese [http://de.wikipedia.org/wiki/Zertifizierungsstelle Zertifizierungsstelle] diese Überprüft die Idendität des Admins und unterschreibt dann diesen Zertifikatsrequest. Damit bürgt die Zertifizierungsstelle mit ihrem Konzept der Überprüfung, dass das Zertifikat auch wirklich von dieser Person stammt für die sie sich ausgibt. Dein Browser überprüft dies dann und sollte seiner Meinung nach alles in Ordnung sein, wird er dich mit keiner Warnmeldung belästigen.
+
Dies funktioniert folgendermasssen: Ein Admin, der seinen Server per SSL absichern möchte, schickt einen Teil seines Zertifikates (den Zertifizierungsrequest) an diese [http://de.wikipedia.org/wiki/Zertifizierungsstelle 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 und stellt er 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 ==
 
== Root-Zertifikate / Zertifizierungsstellen ==
  
Dies bedeutet, dass mein Browser (oder Mail-, Jabberprogramm usw.) ja irgendwie die Root-Zertifikate haben muss, damit er die [http://de.wikipedia.org/wiki/Authentizit%C3%A4t Authentizität] des Zertifikats überprüfen kann. Dabei kommen uns die Browserhersteller zu Hilfe und haben bereits einige Zertifikate von [http://de.wikipedia.org/wiki/Zertifizierungsstelle Zertifizierungsstellen], die sie für Vertrauenswürdig halten, 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 der Prozess, welcher dazu führt das Zertifizierungsstellen aufgenommen werden, vor allem mit einem finanziellen Aufwand verbunden, welchen sich unkommerielle Zertifizierungsstellen kaum leisten können und dazu führt, dass deren signierte Zertifikate von Browsern als unsicher gemeldet wird oder gar durch das komische Sicherheitskonzept des Internet Explorers 7 der Zugriff auf eine eigentlich gültig und somit vertrauenswürdig verschlüsselte Seite explizit nicht empfohlen wird.
+
Dies bedeutet, dass dein Browser (oder Mail-, Jabberprogramm usw.) ja irgendwie die Root-Zertifikate haben muss, damit er die [http://de.wikipedia.org/wiki/Authentizit%C3%A4t Authentizität] des jeweiligen Server-Zertifikats überprüfen kann. Dabei kommen uns die Browserhersteller zu Hilfe und haben bereits einige Root-Zertifikate von [http://de.wikipedia.org/wiki/Zertifizierungsstelle 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 und dazu führt, dass deren signierte Zertifikate von Browsern als unsicher gemeldet wird oder gar, aufgrund des komischen Sicherheitskonzept des Internet Explorers 7, der Zugriff auf eine eigentlich gültig und somit vertrauenswürdig verschlüsselte Seite explizit nicht empfohlen wird.
  
Importieren wir dann das Root-Zertifikat derjenigen Zertifizierungsstelle, kann der Browser die Verbindung überprüfen und wir können sicher gehen, das wir eine gültige Verbindung aufgebaut haben.
+
Dem kann dadurch abgeholfen werden, dass 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.
  
 
=== CACert ===
 
=== CACert ===
Zeile 61: Zeile 67:
 
== Konsequenzen / Zusammenfassung ==
 
== Konsequenzen / Zusammenfassung ==
 
[[Bild:Non trustable ssl cert.png|thumb|framed|right|Beispiel eines nicht Vertrauenswürdigen Zertifikats]]
 
[[Bild:Non trustable ssl cert.png|thumb|framed|right|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 import des Root-Zertifikats) keine Warnmeldung ausgibt und dieser die Verbindung somit als vertrauenswürdig gesichert ansieht oder wir das Zertifikat nicht über einen anderen Weg überprüft haben, wie z.B. mit Hilfe eines publizierten Fingerprints. Allen verschlüsselten Verbindungen, bei denen der Browser (oder andere Programme) eine Warnmeldung ausgibt, ist nicht zu trauen resp. mit Vorsicht zu geniessen. Ihr solltet dann die Meldung (siehe [[:Bild:Non trustable ssl cert.png|Bild]]) des Browsers genau durchlesen und ggf. den Verbindungsaufbau abbrechen.
+
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 [http://de.wikipedia.org/wiki/Fingerprint Fingerprints] des Zertifikats ([[Certs:immerda#Fingerprints|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:Non trustable ssl cert.png|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 von [http://cacert.org CACert] in deinen Browser importieren. Eine Anleitung dazu findest du [[Certs:immerda#Importieren|hier]].
 
Um den Zugriff auf die meisten Immerda Seiten zu überprüfen musst du das Root-Zertifikat von [http://cacert.org CACert] in deinen Browser importieren. Eine Anleitung dazu findest du [[Certs:immerda#Importieren|hier]].

Version vom 25. November 2007, 17:17 Uhr

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 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 wie 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 somit 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 Brwosers (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 Jabber können nur per ssl gesicherte Verbindungen aufgebaut werden, mehr dazu auch in der Jabber Anleitung.

https

Normalerweise beginnen die 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. Sprich 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 den vollen 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, zudem 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 derartige 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 derartigen 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 und ob dieser auch wirklich zu vertrauen ist. Dazu wurde die Technik von digitalen Zertifikaten entwickelt, welche die Möglichkeit bieten 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. Sprich sie 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 und stellt er 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 er 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 und dazu führt, dass deren signierte Zertifikate von Browsern als unsicher gemeldet wird oder gar, aufgrund des komischen Sicherheitskonzept des Internet Explorers 7, der Zugriff auf eine eigentlich gültig und somit vertrauenswürdig verschlüsselte Seite explizit nicht empfohlen wird.

Dem kann dadurch abgeholfen werden, dass 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.

CACert

Diese Problematik besteht leider gerade bei CACert, einer nichtkommerzielle Zertifizierungsstelle, welche wir für fast all unsere Seiten verwenden. Deshalb muss und sollte unbedingt das Root-Zertifikat von CACert in euren Browser importiert werden. 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 von CACert in deinen Browser importieren. Eine Anleitung dazu findest du hier.