Hallo die Herren, ich beschäftige mich zurzeit mit dem https Handshake zwischen Client und Server. Dazu habe ich mir folgenden Link angeschaut. https://www.elektronik-kompendium.de/sites/net/1811281.htm Soweit sogut. Habe ein Demo Board von TI und kann mich mit dem Beispielprojekt "https Request" erfolgreich mit einem Webserver verbinden. Dafür benötige ich ein Root Zertifikat/Wurzelzertifikat. In meinem Beispiel ist es das "DigiCertGlobalRootCA.crt" Zertifikat für die Webseite https://www.example.org Wenn ich mir den HTTPS Verbindungsaufbau bei elektronik-kompendium anschaue sehe ich kein Root-Zertifikat. Welche Aufgabe hat das Root-Zertifikat? Ist es eine implementierung für die validierung des Server Zertifikats im Punkt 3 (Zertifikat prüfen) ?
Der HTTPS Server muss dem Client nachweisen, wer er ist. Dazu sendet er sein Zertifikat an den Client. Ein Zertifikat ist ein elektronisches Dokument mit der Domain des Besitzers, sowie weiteren optionalen Informationen (Inhaber, Anschrift, etc). Im Prinzip wie ein Personalausweis oder eine Geburtsurkunde. Der Browser würde einem einfaches Zertifikat jedoch nicht vertrauen. Schließlich könnte sich jeder Hinz und Kunz einfach eins selbst erstellen. Urkunden kann man sich ja auch selbst schreiben. Vertrauenswürdig werden solche Dokumente erst, wenn eine vertrauenswürdige Person dieses Unterschreibt. Bei Zertifikaten ist diese Unterschrift natürlich elektronisch und einigermaßen fälschungssicher. Die Frage ist: Wer ist vertrauenswürdig? Du jedenfalls nicht. Der Browser und/oder das Betriebssystem enthält einen Satz sogenannter Root Zertifikate. Die gehören den Personen/Firmen, die sich selbst auserkoren haben, Zertifikate (Dokumente) zu beglaubigen. Die kungeln alle in einem Club zusammen und folgen ihren eigenen Regeln, welche festlegen, wer eigentlich vertrauenswürdig ist. Wer die Clubregeln bricht, fliegt raus. In der Praxis läuft das dann so, dass diese Zertifikate beim nächsten Betriebssystem- oder Browser-Upgrade entsprechend gekennnzeichnet werden. Wer zum Club gehört, kann die Zertifikarte seiner Freunde/Geschäftspartner unterschreiben, so dass diese automatisch ebenfalls als Vertrauenswürdig gelten. Und die können das auch tun, usw. Angenommen du bist gerade auf der Seite mikrocontroller.net, dann zeigt dein Browser an, dass mikrocontroller.net vertrauenswürdig ist, weil der Server ein Zertifikat mit passender Domain vorgelegt hat und dieses von jemandem (Let's Encrypt) als vertrauenswürdig unterschrieben wurde. Und wer hat Let's Encrypt überhaupt erlaubt, solche Unterschriften zu erteilen? Das war die Firma ISRG. Kennst du die? Bist du ganz sicher, dass ISRG nicht irgendwelchen Deppen die Erlaubnis erteilt, Zertifikate zu erstellen? Fragen über die man mal nachdenken sollte. Um auf deine Frage zurück zu kommen: ISRG ist in diesem Fall die Root Zertifizierungsstelle. Wenn dein Betriebssystem/Browser deren Zertifikat vorliegen hat, vertraut es allen Kunden von ISRG autmatisch ebenfalls - in diesem Fall Let's Encrypt. Und er vertraut auch allen Kunden von Let's Encrypt - in diesem Fall mikrocontroller.net. Damit dein Browser HTTPS spricht, muss der Server ein Zertifikat vorlegen. Es muss nicht unterschrieben sein. Solche Zertifikate kann man sich mit einem openssl Kommando ganz einfach selbst erstellen. Allerdings warnt der Browser vor solchen unsignierten Zertifikaten. Er würde auch warnen, wenn du das Zertifikat einfach selbst unterschreibst, mit einem selbst gebasteltem Root Zertifikat. Damit ein grünes Schloss erscheint, muss das Zertifikat von einer offiziellen Root CA unterzeichnet werden oder von einem direkten oder indirekten Geschäftspartner einer Root CA. Alternative: Einfach eine Phantasie Root CA erstellen, das Server Zertifikat damit signieren und das Root CA Zertifikat zentral installieren. Das hat z.B. die Firma Sennheiser gemacht, und dann auch noch den privaten Schlüssel mit einem Treiber verteilt, so dass jeder Hacker jetzt böse Webseiten erstellen konnte, die "angeblich" von Sennheiser als Vertrauenswürdig unterschrieben wurden. Toll, was? Am Ende vertrauen die Geschäftsleute jedem, der genug zahlt. Das ist meine Meinung dazu. Dazu kommen Deppen wie Sennheiser, die das ganze System unabsichtlich untergraben, aber natürlich auch Leute, die das absichtlich machen. Wer kontrolliert schon, ob der neue Video Downloader neue Zertifikate mit installiert? Wusstest du, dass die NSA Mitglied im Club ist? Da könnte man noch sagen "Die Amerikaner sind aber die guten". Und was ist mit einem arabischen Geheimdienst? Den gibt's nämlich auch im Club.
Hallo Stefanus, danke für die vielen Informationen. Ich versuche mal mit deinen Infos , mir eine Antwort zu geben. Also nachdem der Server sein Server Zertifikat an den Client sendet prüft der CLient mit Hilfe des Root Zertifikat die Echtheit des Server Zertifikats. Ist das so korrekt? Denn ich habe auch gelesen, das nachdem der Client das Server Zertifikat erhalten hat, der Client den Server der CA kontaktiert und somit das zuvor übertragene Server Zertifikat validiert.
Fabian schrieb: > Ist das so korrekt? So ist es. > Denn ich habe auch gelesen, das nachdem der Client das Server > Zertifikat erhalten hat, der Client den Server der CA kontaktiert > und somit das zuvor übertragene Server Zertifikat validiert. Das ist ein optionales Feature. Ich weiß nicht, welche Clients davon Gebrauch machen. Ein weiteres optionales Feature ist die Abfrage einer öffentlichen Sperr-Liste. In Kombination mit Apps gibt es dann noch das "Certificate Pinning". Dabei vertraut die App nur ganz bestimmten Zertifikaten, die in der App selbst hinterlegt sind (nicht allen, die auf eine Root CA führen).
Fabian schrieb: > Ist das so korrekt? Ja. Damit werden erstellte Zertifikate verifiziert. Aber zurückgezogene Zertifikate lassen sich so nicht feststellen... > Denn ich habe auch gelesen, das nachdem der Client das Server Zertifikat > erhalten hat, der Client den Server der CA kontaktiert und somit das > zuvor übertragene Server Zertifikat validiert. ...und das geschieht hier.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.