Ich habe über das SSL-Protokoll gelesen und jetzt weiß ich, wie es Daten verschlüsselt. Aber ich kann etwas nicht verstehen. Mit SSl sind Sie sicher, dass Sie Daten an den richtigen Server senden und Daten von ihm erhalten. aber wie? Ich meine, wenn ich ein gefälschtes Zertifikat erstelle und es für Anfragen einer speziellen Website sende, wie können Browser (oder andere Programme) das gefälschte Zertifikat erkennen?
Bearbeiten: Ich wollte kein selbstsigniertes Zertifikat erstellen. Ich meinte, wie jemand mein Zertifikat validieren kann, wenn ich ein Zertifikat erstelle, dessen Aussteller und Betreff etc. etwas zum echten Zertifikat sind! (die einzigen Dinge, die nicht real sind, ist der öffentliche Schlüssel und die Signatur)
SSL-Zertifikate werden von einer Zertifizierungsstelle (CA) signiert, von der der Benutzer bereits vertraut (oder wahrscheinlicher) ist , die Leute, die ihr Betriebssystem entworfen haben, vertrauen).
Die CA signiert das Zertifikat digital unter Verwendung der Verschlüsselung mit öffentlichen Schlüsseln . Die grundlegende Erklärung ist, dass die CA einen "privaten Schlüssel" und einen "öffentlichen Schlüssel" hat, den jeder kennt. Über einige Berechnungen, die ich nicht verstehe, kann die Zertifizierungsstelle mit ihrem privaten Schlüssel eine Signatur erstellen, die leicht mit ihrem öffentlichen Schlüssel verifiziert werden kann (der öffentliche Schlüssel kann jedoch nicht zum Erstellen einer neuen Signatur verwendet werden).
Wenn Sie ein SSL-Zertifikat von einem Server erhalten, erhalten Sie den öffentlichen Schlüssel des Servers und eine Signatur von einer Zertifizierungsstelle, die besagt, dass sie gültig ist (zusammen mit einigen anderen Informationen). Wenn Sie diese CA kennen und ihr vertrauen, können Sie die Signatur überprüfen und feststellen, ob sie gültig ist. Sie können auch eine Zertifikatsperrliste verwenden, um sicherzustellen, dass sie nicht widerrufen wurde.
Sie können also grundsätzlich ein fehlerhaftes SSL-Zertifikat erkennen, da es nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert ist.
TL; DR-Zusammenfassung:
Die Gültigkeit eines Serverzertifikats wird festgelegt durch:
Angenommen, Sie möchten eine Verbindung zu Ссылка herstellen (Sie können dies in Ihrem Browser ausprobieren!).
Der (reale) Server antwortet mit einem Zertifikat, das an mail.google.com ausgegeben wird, d. h. im Feld "Betreff" des Zertifikats finden Sie den allgemeinen Namen (CN) "mail.google.com" - vgl. RFC 5280 für Details zu den Feldern von Zertifikaten. Die Tatsache, dass der Betreff mit der Site-URL verknüpft ist, ist sehr wichtig für die Sicherheit des gesamten Modells und wird aktiv von Ihrer TLS-Implementierung überprüft ("Host-Name-Verifizierung"), da sonst Platz für Man-In- The-Middle Angriffe. I.e. jemand könnte ein ansonsten gültiges Zertifikat erwerben und sich als mail.google.com ausgeben, ohne dass Sie davon Notiz nehmen.
Zusätzlich zur Überprüfung des Hostnamens überprüft Ihre TLS-Implementierung auch die "Gültigkeit" des Zertifikats. Das ganze Verfahren ist ziemlich komplex und beinhaltet auch die Überprüfung der Vertrauenswürdigkeit des Zertifikats, aber zusätzlich werden viele andere Dinge überprüft, mehr dazu in einer Minute.
Wenn Sie das Google Mail-Zertifikat in Ihrem Browser anzeigen, werden Sie feststellen, dass tatsächlich drei Zertifikate angezeigt werden:
Das Modell ist, dass es ein paar (gut, leider nicht so wenige) vertrauenswürdige Stammzertifizierungsstellen ("root cA") gibt, die Sie entweder selbst auswählen können oder (die wahrscheinlicher sind), die mit Ihrer Software vorkonfiguriert sind ( zB Browser), denen blind vertraut wird. Diese vertrauenswürdigen Instanzen bilden die Anker des gesamten Trust-Modells von "PKI" (Public Key Infrastructure). Die Grundidee besteht darin, dass die vertrauenswürdigen Einheiten Zertifikate an andere Behörden ausstellen und ihnen die Erlaubnis erteilen, erneut Zertifikate auszustellen (diese Behörden werden als Zwischenzertifizierungsstellen bezeichnet). Die Zwischen-CAs können diese Prozedur bis zu einem bestimmten Punkt erneut rekursiv anwenden, wobei die Anzahl der Zwischen-CAs zwischen einem tatsächlichen End-Entitätszertifikat und einem Stamm-CA-Zertifikat im Allgemeinen begrenzt ist.
An einer Stelle wird eine zwischengeschaltete Zertifizierungsstelle Zertifikate an eine "End-Entität" ausgeben (in unserem Beispiel "mail.google.com"). Der Prozess zum Ausstellen eines Zertifikats bedeutet nun, dass die Partei, die ein Zertifikat anfordert, zuerst ein öffentliches / privates Schlüsselpaar erstellt und sie verwendet, um eine Zertifikatanforderung zu authentifizieren, die an die Zertifizierungsstelle gesendet wird. Die ausstellende Behörde erstellt ein Zertifikat für die untergeordnete Entität (entweder Zwischen-CA oder End-Entität), indem sie dieses Zertifikat unter Verwendung eines eigenen privaten Schlüssels unter Verwendung eines asymmetrischen Algorithmus wie RSA "signiert" und zusätzlich den öffentlichen Schlüssel der anfordernden Partei in das neue einfügt generiertes Zertifikat Die Stammzertifizierungsstelle besitzt ein sogenanntes selbstsigniertes Zertifikat, d. H. Die Stammzertifizierungsstelle ist die einzige Autorität, die ihr eigenes Zertifikat signieren und ihren eigenen öffentlichen Schlüssel einschließen kann. Der private Schlüssel bleibt natürlich immer verborgen.
Die Rekursivität des Zertifikatsausgabeprozesses impliziert, dass es für jedes End-Entitätszertifikat eine einzigartige Möglichkeit gibt, eine "Kette" von Zertifikaten aufzubauen, die zu einer Root-Zertifizierungsstelle führt. Wenn Sie bei dem Versuch, eine Verbindung zu einer TLS-gesicherten Site herzustellen, ein End-Entitätszertifikat erhalten, wird die folgende Prozedur rekursiv angewendet, bis Sie mit einem Stammzertifizierungsstellenzertifikat enden:
Wenn alle Überprüfungen positiv waren, haben Sie letztendlich ein selbstsigniertes Zertifikat, d. h. wenn der Betreff auch der Aussteller ist (wie beispielsweise das VeriSign-Zertifikat in unserem Beispiel).Nun ist das letzte, was Sie überprüfen müssen, ob dieses Zertifikat zu denen gehört, denen Sie blind vertrauen: Wenn dies der Fall ist, ist alles in Ordnung und die Verbindung wird erfolgreich sein, wenn nicht, wird der Verbindungsversuch zurückgewiesen.
Als ob das nicht schon kompliziert genug wäre, behandeln die bisher beschriebenen Überprüfungen keine Fälle, in denen einmal gültige Zertifikate plötzlich unberechtigt werden, beispielsweise Fälle, in denen ein Zertifikat gestohlen wird oder private Schlüssel kompromittiert werden (denken Sie an Comodo und DigiNotar). In diesen Fällen besteht das normale Verfahren darin, die fehlerhaften Zertifikate zu "widerrufen", das heißt, dass Sie sie ab einem bestimmten Zeitpunkt als ungültig markieren möchten (sie werden irgendwann ablaufen, aber für den Rest dieses Zeitraums) sie sollen bereits als ungültig markiert sein). In diesen Fällen haben Zertifizierungsstellen die Möglichkeit, CRLs (ein Katalog von Zertifikaten, die als ungültig deklariert sind) oder OCSP-Antworten (Informationen für einen oder in seltenen Fällen eine Gruppe von Zertifikaten) auszugeben, die Clients Informationen darüber liefern, ob ein bestimmtes Zertifikat als ungültig markiert wurde oder nicht. Der Sperrstatus muss für alle Zertifikate in einer Kette überprüft werden, sollte einer davon als ungültig markiert sein, dann kann das End-Entitätszertifikat nicht vertrauenswürdig sein und die Verbindung muss ebenfalls zurückgewiesen werden.
Jedes gefälschte Zertifikat, das Sie erstellen, ist ein selbstsigniertes Zertifikat.
Der Browser zeigt große unheimliche Warnungen an, wenn er eine Verbindung zu einer Site mit einem selbstsignierten Zertifikat herstellt, das der Benutzer sofort ignorieren wird.
Um Warnungen zu vermeiden, benötigen Sie ein Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle wie VeriSign signiert wurde. Re: Bearbeiten : Sie können ein nicht selbstsigniertes Zertifikat nur erstellen, wenn Sie es von einer vertrauenswürdigen Zertifizierungsstelle signiert haben.
Diese Unternehmen werden
Sie werden sich weigern, ein Zertifikat für ein anderes Fach zu unterschreiben.
Zertifikate funktionieren, weil sie einer Vertrauenskette folgen . Zertifikate haben eine Kette von einem oder mehreren Emittenten, denen vertraut wird. Diese Kette ist das Rückgrat, warum es überhaupt funktioniert. Browser und fast alle SSL-Zertifikat-Bibliotheken führen diese Kettenüberprüfung durch oder bieten zumindest die Option zu.
Selbstsignierte Zertifikate (oder solche, die von Ketten ausgegeben werden, die mit einem selbstsignierten Zertifikat enden) würden diese Prüfung nicht bestehen.
Tags und Links security ssl cryptography certificate ssl-certificate