Zertifikate des LinuxTag
Warum warnt mich mein Browser? Was ist ein Zertifikat? Und was ist die Rolle von CAcert? Die folgende Sammlung enthält die anzunehmenderweise häufigsten Fragen zum Zertifikatsverfahren im Rahmen von HTTPS-Webseiten, die sich der eine oder die andere vielleicht schon lange stellt.
Für den gesamten Text ist der LinuxTag e.V. der Urheber, und der Text steht unter der Nutzungslizenz CC BY-SA.
Warum erhalte ich eine Warnung, wenn ich bestimmte LinuxTag-Webseiten aufrufe?
Der Browser warnt davor, dass er nicht überprüfen kann, ob die aufgerufene Webseite "echt" ist - ob die Webseitendaten also auch wirklich vom Webserver des LinuxTag e.V. stammen. Der Browser will immer dann die Echtheit einer Webseite überprüfen, wenn er eine Seite aufruft, die mit HTTPS beginnt - warum das so ist, mehr dazu gleich. Für die Überprüfung braucht er ein Zertifikat - was das ist, mehr dazu weiter unten.
Mir ist das zu kompliziert. Warum verzichtet der LinuxTag nicht einfach auf HTTPS, wenn das Probleme macht?
HTTPS sorgt dafür, dass den mittels HTTP übertragenen Daten das SSL-Verfahren vorgeschaltet ist. Das SSL-Verfahren verschlüsselt relevante Daten vor der Übertragung - also bei jedem einzelnen Webseitenaufruf - damit sie niemand mitlesen oder verändern kann.
Da der LinuxTag e.V. nicht will, dass persönliche Daten des Webseitenbesuchers, wie sie etwa im vCC eingegeben werden, von jedem mitgelesen oder verändert werden können, kommt HTTPS auf bestimmten Seiten per default zum Einsatz.
Mir ist das immer noch zu kompliziert. Ist es denn wirklich nötig?
Die Entscheidung, ob der Webseitenbesucher seine Systemangaben, persönlichen Adress- und sonstige Daten offen oder lieber verschlüsselt durch das Internet schicken will, liegt grundsätzlich bei ihm selbst. Man kann ihm ja schlecht vorschreiben, welche seiner Daten er verschlüsselt und welche er unverschlüsselt übertragen soll.
Aber: Wenn der LinuxTag-Webserver HTTPS gar nicht erst anbietet, dann hat der Webseitenbesucher gar keine Wahl. Dann würde er seine Daten ungeschützt versenden, ob er wollte oder nicht. Daher benutzt der LinuxTag-Webserver HTTPS per default, wenn es um die Übertragung von persönlichen Daten geht.
Das nimmt dem Webseitenbesucher die Entscheidung zwar auch ab - und es verursacht eben leider vielleicht ein bisschen Irritation, wenn jemand drüber stolpert, dass er sich erst ein "Zertifikat", von dem er vielleicht nicht so genau weiß was es eigentlich ist, in den Browser laden müsse. Aber: Von Seiten des LinuxTag e.V. ist der Webseitenbesucher so auf der sicheren Seite. Und was die Irritation betrifft: Dafür gibt es ja diese FAQ-Sammlung. ;)
Also gut. Ran an den Speck: Was haben Zertifikate mit HTTPS zu tun?
Allein die Verschlüsselung des Übertragungsweges, wie sie bei HTTPS geschieht, bietet noch keine Sicherheit. Denn ein Angreifer könnte sich in die Kommunikation zwischen dem Webseitenbesucher und dem LinuxTag-Webserver einklinken. So einen Angreifer, der sich in die Mitte setzt, nennt man im IT-Security-Jargon "man in the middle". Er kann dann die vom Webserver bzw. vom Webseitenbesucher übertragenen Daten auf seinen eigenen Server umleiten, ehe sie ihr eigentliches Ziel erreichen. Deshalb heißt so ein Angriff "man in the middle attack".
Wenn ein Angreifer in der Mitte zwischen Webseitenbesucher und LinuxTag-Webserver sitzt, kann er Folgendes tun: Er kann die für die Verschlüsselung benutzten Schlüssel durch eigene ersetzen. Ab dem nächsten Seitenaufruf kann er dann die Daten selbst ver- und entschlüsseln. Das würden weder der Webseitenbesucher noch der Webserver merken: Sie sehen ja nur eine verschlüsselte Verbindung und denken, es ist alles in Ordnung. Allerdings liefe diese Verbindung unbemerkt über den Angreifer. Dieser könnte die übertragenen Daten lesen und, wenn er will, auch manipulieren, anschließend wieder verschlüsseln und an den Webserver weiterschicken, so als sei nichts geschehen. Sprich, die Verschlüsselung des Übertragungsweges nützte überhaupt nichts.
Dem kann man aber entgegenwirken. Um sicherzustellen, dass der Webseitenbesucher wirklich mit dem LinuxTag-Webserver kommuniziert und nicht mit einem "man in the middle", will der Browser bei jedem einzelnen Webseitenabruf von dem Webserver so etwas hören wie: "Ja, ich bin der LinuxTag-Webserver, und die Daten, die ich Dir schicke, sind auch wirklich die des LinuxTag e.V. Ich kann Dir das bestätigen." Genau diese Bestätigungsfunktion übernimmt das Zertifikat, das der LinuxTag-Webserver dem Browser vorweist (daher heißt es auch Server-Zertifikat).
Was genau ist denn ein Zertifikat?
Ein Server-Zertifikat ist im Grunde eine kleine Textdatei, die der Webserver bei jedem Seitenaufruf mitschickt. Das Zertifikat enthält zwei wichtige Angaben: den Name des Ausstellers (also der LinuxTag e.V.) und seinen öffentlichen Schlüssel. Mit diesem öffentlichen Schlüssel entschlüsselt der Browser des Webseitenbesuchers, was ihm der LinuxTag-Webserver schickt. Genauso verschlüsselt der Browser des Webseitenbesuchers damit, was er an den Server schickt.
Der Trick ist, dass in eine Autorität in dieser Zertifikatsdatei mittels digitaler Unterschrift die Identität des Webservers bestätigt.
Denn sonst könnte ja auch der Angreifer einfach eine eigene, fingierte Zertifikatsdatei vorzeigen. Dieses falsche Zertifikat würde ebenfalls auf den Namen des LinuxTag e.V. lauten - und es würde den Schlüssel des Angreifers enthalten. Aber: Dieses fingierte Zertifikat könnte nicht die Identität des LinuxTag-Webservers bestätigen. Denn genau für den Zweck, um die Echtheit von Webservern im Rahmen des HTTPS-Übertragungsweges zu bestätigen, gibt es in der Informationssicherheit spezialisierte Zertifizierungsstellen als Autorität (englisch "Certificate Authorities", oder einfach "CA").
Diese Zertifizierungsstellen bestätigen in dem Zertifikat manipulationssicher die Behauptung, dass Webserver x von Organisation y betrieben wird (das ist die digitale Unterschrift). So entsteht ein CA-Zertifikat. Mit solch einem CA-Zertifikat kann der Webserver seine Identität fortan zweifelsfrei beweisen - und dieser Beweis kann nicht so leicht fingiert werden.
Was hat die Zertifizierungsstelle konkret getan, um sich der Identität des Webservers zu versichern?
Der LinuxTag e.V. lässt alle seine Zertifikate von der Community-Zertifizierungsstelle CAcert unterzeichnen. Denn das freie Projekt benutzt die gleichen technischen Verschlüsselungssstandards wie kommerziell operierende Zertifizierungsstellen, aber seine Dienste sind kostenlos.
- CAcert hat anhand eines Vereinsauszuges aus dem Registergericht den LinuxTag e.V. als Betreiber des Webservers überprüft.
- CAcert hat mittels Ausweisdokumenten bei persönlichen Treffen die Identität mehrere Vereinsmitglieder überprüft, die für die Technik zuständig sind.
- Vereinsmitglieder haben bei CAcert angemeldet, als Administrator für den LinuxTag e.V. aufzutreten. Dazu haben sie bei CAcert ein Passwort hinterlegt, mit dem sie sich zukünftig als Administratoren ausweisen können.
Die Organisation ist nun geprüft, und bestimmte Personen sind nun überprüft. CAcert hat sich nun noch versichert, dass die Personen, die das Passwort hinterlegt haben, auch tatsächlich zum LinuxTag e.V. gehören. Dafür hat CAcert eine E-Mail an die Domain-Registrierungs-Adresse von der LinuxTag-Webseite geschickt. Wenn also diejenigen, der sich als LinuxTag-Angehörige ausgegeben haben, die von CAcert geschickte E-Mail empfangen und beantworten können, gilt ihre Identität in Beziehung zum LinuxTag e.V. als bestätigt. - Erst jetzt haben CAcert-Projektmitglieder die Zertifikatsdatei des LinuxTag e.V. mittels digitaler Unterschrift signiert. Mit diesem signierten Zertifikat - eben ein CA-Zertifikat - kann der LinuxTag-Webserver fortan seine Identität belegen.
Sind die Zertifikate von CAcert weniger verlässlich als die von kommerziellen CAs?
Eher im Gegenteil: CAcert prüft die Identität von Zertifikatsaustellern gewissenhaft und offenbar mit mehr Erfolg als einige der CAs, die kommerziell arbeiten und ihre Zertifikate für geringe Beträge verkaufen. Im Jahr 2011 mussten zum Beispiel alle Browser aktualisiert werden, um CAs wie DigiNotar und GlobalSign, die die Hürde der Aufnahme geschafft hatten, wieder zu entfernen: Es hatte sich herausgestellt, dass falsche Server-Zertifikate mit der Signatur dieser Firmen im Umlauf waren (vgl. zum Beispiel dieser Artikel bei Heise.de von Oktober 2011).
Prima, der LinuxTag hat also ein von CAcert signiertes Zertifikat. Was ist nun das Problem?
Das Zertifikat, das der LinuxTag-Webserver vorweist, muss von dem Browser geprüft werden können. Wenn der Browser das nicht kann, gibt es eine Warnung - damit fing ja die ganze Chose an. Was genau fehlt dem Browser also?
Was der Browser konkret überprüft, ist der in dem Zertifikat angegebene Schlüssel. Denn dieser sorgt für die verschlüsselte Übertragung im HTTPS-Verfahren und ist, wie wir im "man in the middle attack" gesehen haben, der angreifbare Punkt. Aber anhand der digitalen Unterschrift in dem Zertifikat kann der Browser sicherstellen, dass der Zertifikats- und damit der Schlüsselaussteller der LinuxTag e.V. ist - und kein Angreifer (denn die Signatur wurde ja erst nach aufwändigem Prüfprozess geleistet). Als entscheidenden Schritt muss der Browser also sicherstellen, dass die digitale Unterschrift der CA echt ist.
Damit jeder die digitale Unterschrift einer CA überprüfen kann, stellen CAs so genannte Root-Zertifikate oder CA-Zertifikate zur Verfügung. Diese Root-Zertifikate muss der Browser lokal zur Verfügung haben - im Unterschied zu dem bisher besprochenen, so genannten Server-Zertifikat des Ausstellers (das ja auf dem Webserver liegt).
Die Crux ist, dass das Root-Zertifikat von CAcert nicht per default in den Browsern enthalten sind. CAcert wird hauptsächlich von ehrenamtlichen Mitarbeitern betrieben, wie auch der LinuxTag. Der Aufnahmeprozeß in die Browser ist zeitaufwändig und mit Kosten verbunden. CAcert strebt die Aufnahme allerdings an - an dieser Stelle ist vielleicht die Bemerkung angebracht, dass sich das Projekt sehr über Mithilfe freut.
Und darum braucht jeder Browser, der eine LinuxTag-Webseite über HTTPS lädt, ein Root-Zertifikat von CAcert, mit dem er bei jedem einzelnen Ladevorgang die Identitätsbehauptung des Webservers über die CAcert-Signatur abgleichen kann. Das Abgleichen geschieht danach komplett im Hintergrund. Viele Browser haben heute eine Funktion eingebaut, die dem Webseitenbesucher das Ergebnis der Überprüfung sichtbar macht: Am Beginn der Adresszeile des Browsers erscheint bei erfolgreicher Überprüfung zum Beispiel ein blaues oder grünes Feld. Bei erfolgloser Anfrage nach dem Zertifikat erscheint ein rotes Feld.
Okay. Jetzt weiß ich mehr, als ich wissen wollte. Was muss ich denn nun tun?
Damit der Browser die Identität der LinuxTag-Webseiten überprüfen kann, muss man sich das Root-Zertifikat der Klasse 3 von CAcert herunterladen.
Alternativ könnte man dem Browser sagen, dass er den Webseiten der Domain Linuxtag.org stets ungeprüft vertrauen soll. Dafür fügt man eine Ausnahmebestätigung hinzu (bitte Prüfsummen abgleichen - siehe [1]). Der LinuxTag e.V. empfiehlt jedoch das Verfahren mit dem Root-Zertifikat. Erstens ist das sicherer. Und zweitens hat der Webseitenbesucher dann das Root-Zertifikat von CAcert da - und muss nicht bei der nächsten Webseite, die CAcert als CA benutzt, von vorn anfangen.
Das Root-Zertifikat von CAcert lässt sich auf deren Webseite herunterladen:
http://www.cacert.org/index.php?id=3
Nach einem Linksklick unter "Class 3 PKI Key" auf "Intermediate Certificate (PEM Format)" öffnet sich im Firefox in kleines Fenster zum Herunterladen des Zertifikats. Im Internet Explorer gibt es zunächst eine Sicherheitswarnung vor dem Dateidownload (hier "Öffnen" klicken), dann eine weitere Warnung, dass eine Webseite ein Programm auf dem Computer öffnen wolle (hier "Zulassen" klicken).
Diesen Sicherheitswarnungen begegnen wir jetzt, indem wir mittels Prüfsummen die Integrität der herunterzuladenen Root-Zertifikatsdatei überprüfen. Das ist notwendig. Denn wer sich ahnungslos ein fingiertes Root-Zertifikat herunterlädt, hebt das gesamte Zertifikatsverfahren zur Absicherung von HTTPS aus den Angeln.
Zum Überprüfen benutzt man so genannte Fingerprints (zu deutsch Fingerabdrücke): Das sind Prüfsummen, um die Echtheit der Datei festzustellen. CAcert gibt für sein Root-Zertifikat zwei Prüfsummen an - die eine wurde mit dem SHA1-Verfahren erstellt, die andere mit dem MD5-Verfahren. Es reicht, eine Zeichenkette zu überprüfen, nicht beide (toll, nicht wahr ;).
Im Firefox öffnet sich mit einem Klick auf die Schaltfläche "Ansicht" in dem Fenster zum Herunterladen des Zertifikats ein weiteres kleines Fenster, das unter anderem die Fingerabdrücke präsentiert. Im Internet Explorer öffnet sich nach dem Durchwinken der beiden genannten Sicherheitswarnungen ein Fenster namens "Zertifikat" mit drei Registerkarten. Der Fingerabdruck nach dem SHA1-Verfahren verbirgt sich auf der mittleren Registerkarte "Details", wo man sich mittels des kleinen Scrollbalkens im Fenster ganz ans Ende der Feld/Wert-Paare begeben muss. Ein Linksklick auf die Zeile "Fingerabdruck" gibt die Prüfsumme im darunterstehenden Anzeigefeld aus.
Wer keine Schwachstelle auslassen will, gleicht diese Prüfsumme (bestehend aus Ziffern und Buchstaben) an zwei unabhängigen Stellen ab: einmal auf der CAcert-Webseite selbst (sie steht unterhalb der Zertifikatsdateien), und einmal hier auf der LinuxTag-Webseite.
Die SHA1-Prüfsumme des CAcert-Root-Zertifikats der Klasse 3 muss lauten:
AD:7C:3F:64:FC:44:39:FE:F4:E9:0B:E8:F4:7C:6C:FA:8A:AD:FD:CE
Die MD5-Prüfsumme des CAcert-Root-Zertifikats der Klasse 3 muss lauten:
F7:25:12:82:4E:67:B5:D0:8D:92:B7:7C:0B:86:7A:42
Im Firefox erhält die Auswahl "Dieser CA vertrauen, um Websites zu identifizieren" ein Häkchen. Nach einem Klick auf "OK" ist die Sache geritzt. Der Internet Explorer ruft erst noch einen Zertifikatsimport-Assistenten auf. Alle Einstellungen können übernommen werden.
Und wenn die Prüfsumme nicht stimmt?
Bitte drei mal an beiden angegebenen Stellen überprüfen. Wenn die Prüfsumme beim vierten mal immer noch nicht stimmt, dann ist das nicht so gut. Dann bitte das Root-Zertifikat nicht herunterladen, sondern an CAcert (support[at]cacert[dot]org)und die LinuxTag-Administratoren schreiben (admin[at]linuxtag[dot]org).
[1] Fingerabdrücke für LinuxTag-Zertifikate:
vcc.linuxtag.org
* MD5 5D:C9:EE:10:0F:DC:3B:75:64:A2:F6:BA:12:C9:E2:7F
* SHA1 C7:AB:7C:45:BC:80:ED:35:1F:D8:08:3E:39:56:F3:70:D8:A0:DF:AF
eticket.linuxtag.org
* MD5 A3:79:9B:0D:0C:F0:2C:F8:CD:67:29:AF:27:77:47:A4
* SHA1 A5:8A:5A:4A:59:EA:00:1D:EE:8D:DE:73:2A:91:F5:47:F0:CD:8C:F3