Zweiwege-SSL-Klärung

74

Ich bin etwas verwirrt darüber, wie bidirektionales SSL funktioniert. Wie erstellt der Client sein Zertifikat, um es an den Server zu senden? Wird es vom Server generiert und an den Client verteilt?

Was ist der Vorteil von Zweiwege-SSL gegenüber Einweg-SSL?

ssl  two-way 
— Schwert
quelle

Antworten:

103

Beide Zertifikate sollten vor der Verbindung vorhanden sein. Sie werden normalerweise von Zertifizierungsstellen erstellt (nicht unbedingt gleich). (Es gibt alternative Fälle, in denen die Überprüfung anders durchgeführt werden kann, einige Überprüfungen jedoch durchgeführt werden müssen.)

Das Serverzertifikat sollte von einer Zertifizierungsstelle erstellt werden, der der Client vertraut (und die in RFC 6125 definierten Namenskonventionen befolgt ).

Das Clientzertifikat sollte von einer Zertifizierungsstelle erstellt werden, der der Server vertraut.

Es liegt an jeder Partei zu entscheiden, was sie vertraut.

Es gibt Online-CA-Tools, mit denen Sie ein Zertifikat in Ihrem Browser beantragen und dort installieren können, sobald die CA es ausgestellt hat. Sie müssen sich nicht auf dem Server befinden, der die Clientzertifikatauthentifizierung anfordert.

Die Zertifikatsverteilung und das Vertrauensmanagement ist die Rolle der Public Key Infrastructure (PKI), die über die Zertifizierungsstellen implementiert wird. Der SSL / TLS-Client und die Server und dann lediglich Benutzer dieser PKI.

Wenn der Client eine Verbindung zu einem Server herstellt, der eine Clientzertifikatauthentifizierung anfordert, sendet der Server eine Liste der Zertifizierungsstellen, die er als Teil der Clientzertifikatsanforderung akzeptieren möchte. Der Kunde kann dann sein Kundenzertifikat senden, wenn er dies wünscht und ein geeignetes verfügbar ist.

Die Hauptvorteile der Clientzertifikatauthentifizierung sind:

  • Die privaten Informationen (der private Schlüssel) werden niemals an den Server gesendet. Der Client gibt sein Geheimnis während der Authentifizierung überhaupt nicht preis.
  • Ein Server, der keinen Benutzer mit diesem Zertifikat kennt, kann diesen Benutzer weiterhin authentifizieren, vorausgesetzt, er vertraut der Zertifizierungsstelle, die das Zertifikat ausgestellt hat (und das Zertifikat ist gültig). Dies ist der Art und Weise, wie Pässe verwendet werden, sehr ähnlich: Möglicherweise haben Sie noch nie eine Person getroffen, die Ihnen einen Pass zeigt. Da Sie jedoch der ausstellenden Behörde vertrauen, können Sie die Identität mit der Person verknüpfen.

Sie interessieren sich vielleicht für Vorteile von Client-Zertifikaten für die Client-Authentifizierung? (auf Security.SE) .

— Bruno
quelle
Sie sollten "erstellt" durch "signiert von" ersetzen, um dies relevant zu halten
— CharlieS
1
@CharlieS " Keep this relevant " ... Meinst du, es ist nicht relevant, wenn "created" verwendet wird (Wortlaut in Übereinstimmung mit der Frage) ;-)? "Ausgestellt" könnte in der Tat ein besseres Wort sein.
— Bruno
CA ist eine Zertifizierungsstelle. Es spielt keine Rolle, wie das Zertifikat ausgestellt oder erstellt wurde, es spielt nur eine Rolle, ob es von der zertifizierten Behörde unterzeichnet wurde. Ich verstehe, dass die meisten Zertifizierungsstellen von ihnen selbst signierte Zertifikate für öffentliche Schlüssel erstellen / ausstellen und verwendet werden könnten. Wenn jedoch ein bereits vorhandener öffentlicher Schlüssel erforderlich ist, muss er nur von der Zertifizierungsstelle signiert werden.
— CharlieS
@CharlieS Nein, das Signieren ist wirklich nur der letzte technische Schritt im Zertifizierungsprozess (der aus der Ausstellung eines Zertifikats besteht). Es wäre für eine Zertifizierungsstelle nicht sinnvoll, ein von einer anderen Zertifizierungsstelle ausgestelltes Zertifikat zu signieren, da Sie den Aussteller-DN mit dem Betreff-DN abgleichen müssen, um die Kette zu erstellen, wenn Sie dies überprüfen. Das Zertifikat wird nur "erstellt", wenn es signiert ist, da es zuvor eine CSR oder etwas später die TBSCertificate-Struktur ist (aber immer noch kein Zertifikat). Sie wählen nicht "Erstellen", aber ein X.509-Zertifikat muss signiert sein, um zu existieren, und genau das macht diese Datenstruktur zu einem Zertifikat.
— Bruno
Sie erlauben nicht die Unterzeichnung von Zertifikaten, die von einer anderen Behörde ausgestellt wurden. x509 ist signiert, aber nicht unbedingt von einer vertrauenswürdigen Stelle.
— CharlieS
43

Was Sie als "bidirektionales SSL" bezeichnen, wird normalerweise als TLS / SSL mit Clientzertifikatauthentifizierung bezeichnet.

Bei einer "normalen" TLS-Verbindung zu example.com überprüft nur der Client, ob er tatsächlich mit dem Server für example.com kommuniziert. Der Server weiß nicht, wer der Client ist. Wenn der Server den Client authentifizieren möchte, werden normalerweise Kennwörter verwendet. Daher muss ein Client einen Benutzernamen und ein Kennwort an den Server senden. Dies geschieht jedoch innerhalb der TLS-Verbindung als Teil eines inneren Protokolls (z. B. HTTP) Teil des TLS-Protokolls selbst. Der Nachteil ist, dass Sie für jede Site ein separates Passwort benötigen, da Sie das Passwort an den Server senden. Wenn Sie beispielsweise dasselbe Passwort für PayPal und MyPonyForum verwenden, senden Sie dieses Passwort jedes Mal, wenn Sie sich bei MyPonyForum anmelden, an den Server von MyPonyForum, damit der Betreiber dieses Servers es abfangen und auf PayPal ausprobieren und Zahlungen in Ihrem Namen ausführen kann .

Die Clientzertifikatauthentifizierung bietet eine weitere Möglichkeit, den Client in einer TLS-Verbindung zu authentifizieren. Im Gegensatz zur Kennwortanmeldung wird die Clientzertifikatauthentifizierung als Teil des TLS-Protokolls angegeben. Dies funktioniert analog zur Authentifizierung des Servers durch den Client: Der Client generiert ein öffentlich-privates Schlüsselpaar und sendet den öffentlichen Schlüssel zur Signatur an eine vertrauenswürdige Zertifizierungsstelle. Die Zertifizierungsstelle gibt ein Clientzertifikat zurück, mit dem der Client authentifiziert werden kann. Der Client kann jetzt dasselbe Zertifikat zur Authentifizierung bei verschiedenen Servern verwenden (dh Sie können dasselbe Zertifikat für PayPal und MyPonyForum verwenden, ohne das Risiko einzugehen, dass es missbraucht werden kann). So funktioniert es: Nachdem der Server sein Zertifikat gesendet hat, fordert er den Client auf, auch ein Zertifikat bereitzustellen. Dann passiert etwas Magie mit öffentlichen Schlüsseln (wenn Sie die gelesenen Details wissen möchtenRFC 5246 ) und jetzt weiß der Client, dass er mit dem richtigen Server kommuniziert, der Server weiß, dass er mit dem richtigen Client kommuniziert, und beide verfügen über ein gemeinsames Schlüsselmaterial zum Verschlüsseln und Überprüfen der Verbindung.

— NEOatNHNG
quelle
Ich habe eine Client-Rest-API erstellt, die eine Server-Rest-API aufruft (One-Way-Post-Call). Meine Client-Rest-API verwendet Zertifikate, die von der Server-Rest-API ausgestellt wurden. Meine Client-Rest-API hat jedoch niemals Zertifikate für die Server-Rest-API ausgestellt. Kommt es unter Einweg-SSL oder Zweiweg-SSL? Obwohl es sich nur um einen One-Way-Aufruf von Client zu Server handelt, denke ich, dass es sich um eine Zwei-Wege-SSL handelt, da hier die Server-Rest-API überprüft, ob der Client über die vom Server ausgestellten Zertifikate verfügt.
— Himalaya Majumdar
1
@HimalayMajumdar: Wenn auf Ihrem Server ein Zertifikat von einer Zertifizierungsstelle signiert ist oder wenn Sie dieses Zertifikat in Ihrem Client fest codiert haben (Pinning), dann ist es immer noch das richtige TLS mit Clientzertifikatauthentifizierung (Sie nennen es Zwei-Wege-SSL). Yay :-). Wenn Ihr Client Ihrem Serverzertifikat jedoch blind vertraut, handelt es sich technisch gesehen immer noch um TLS mit Clientzertifikatauthentifizierung. Da das Serverzertifikat jedoch nicht vom Client überprüft werden kann, ist es nicht in beide Richtungen und in den meisten Fällen eine wirklich schlechte Idee. Tu das nicht :-(.
— NEOatNHNG
Wenn ich einen Java-Client schreibe, der einen https-fähigen Dienst (selbstsigniertes https) aufruft, schlägt der Client normalerweise fehl, da er dem Zertifikat standardmäßig nicht vertraut. Bei meinem aktuellen Java-Client habe ich gerade die vom Server ausgestellten Zertifikate in meinen Klassenpfad importiert, damit der Server meinem Client vertraut. Ich glaube, durch den Import der Zertifikate vertraut sogar mein Client dem Server automatisch. Vielen Dank für Ihre Antwort.
— Himalaya Majumdar
5

Auf zwei Arten fragt der Client ssl nach dem digitalen Zertifikat des Servers und der Server fordert vom Client dasselbe an. Es ist sicherer, da es in beide Richtungen ist, obwohl es etwas langsam ist. Im Allgemeinen folgen wir dem nicht, da sich der Server nicht um die Identität des Clients kümmert, aber ein Client muss sicherstellen, dass der Server, mit dem er eine Verbindung herstellt, integer ist.

— Divyanshu Srivastava
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.