it-swarm.com.de

Benötigt SSL überhaupt ein clientseitiges Zertifikat?

Ein Freund besteht darauf, dass sowohl Browser als auch Server Zertifikate benötigen. Ich sage nein, nur der Server benötigt einen mit zwei Schlüsseln. Die Frage ist, ob der Browser eine Art Zertifikat (nicht nur Schlüssel) für die Verschlüsselung in SSL/TLS-Kommunikationen mit dem Server verwendet.

6
ProfK

Dein Freund ist richtig. Der Browser muss über das Stammzertifizierungsstellenzertifikat verfügen, damit überprüft werden kann, ob das Serverzertifikat von einer legitimen Zertifizierungsstelle signiert wurde.

6
Mike Scott

Der typische Fall von Zertifikaten, die von einer vertrauenswürdigen Partei ausgestellt wurden (Let's Encrypt usw.)

Serverzertifikate sind unerlässlich, da der Client überprüfen muss, ob er mit dem erwarteten Server spricht, um Man-in-the-Middle-Angriffe zu erkennen. Um sich gegenüber einem Client zu authentifizieren, benötigt der Server dazu das Zertifikat selbst, das öffentlich ist, und den privaten Schlüssel, der mit dem Zertifikat übereinstimmt, das nur dem Server bekannt ist. Um ein vom Server bereitgestelltes Zertifikat als vertrauenswürdig zu akzeptieren, prüft der Client unter anderem, ob dieses Zertifikat von einer vertrauenswürdigen Partei, d. H. Einer vertrauenswürdigen Zertifizierungsstelle (CA = Certificate Authority, d. H. Der Entität, die Zertifikate ausstellt), ausgestellt wurde. Diese vertrauenswürdigen Zertifizierungsstellen werden als Zertifikate im Trust Store des Client-Betriebssystems oder Browsers gespeichert. Dies sind die Arten von Zertifikaten, die auf der Client-Seite benötigt werden.

Und dann gibt es Client-Zertifikate, mit denen der Client gegenüber dem Server authentifiziert wird. Diese sind optional und werden nur selten verwendet. Wenn diese verwendet werden, benötigt der Client nicht nur das (öffentliche) Zertifikat selbst, sondern auch den passenden geheimen privaten Schlüssel, ähnlich dem, was der Server benötigt, um sich gegenüber dem Client zu authentifizieren.

Der seltene Fall von selbstsignierten Serverzertifikaten

In diesem Fall sendet der Server ein Zertifikat, das nicht von einer dem Browser (oder der App oder einem anderen Client) bekannten Zertifizierungsstelle ausgestellt wurde. In diesem Fall ist auf der Clientseite kein Zertifikat beteiligt, der Client muss jedoch einen anderen Weg finden, um zu überprüfen, ob das Zertifikat das erwartete ist. In der Regel fordert der Browser den Benutzer auf, in diesem Fall eine Ausnahme hinzuzufügen.

Der noch ungewöhnlichere Fall, dass überhaupt keine Zertifikate vorliegen

SSL/TLS kann auch ohne Zertifikate verwendet werden, d. H. Nicht einmal auf der Serverseite. In diesem Fall erfolgt die Authentifizierung mit anderen Methoden, z. B. einem geheimen Schlüssel, der vorab zwischen Client und Server (PSK) geteilt wird. Diese Methoden werden selten verwendet und werden vom Browser nicht unterstützt.

12
Steffen Ullrich

Schauen wir uns an, was mit SSL zwischen Server und Client passiert. Aus Wikipedia :

[T] Sie verhandeln eine zustandsbehaftete Verbindung mithilfe eines Handshake-Verfahrens. [...] Während dieses Handshakes einigen sich Client und Server auf verschiedene Parameter, mit denen die Sicherheit der Verbindung hergestellt wird:

  • Der Handshake beginnt, wenn ein Client eine Verbindung zu einem TLS-fähigen Server herstellt, um eine sichere Verbindung anzufordern, und der Client eine Liste der unterstützten Chiffresuiten (Chiffren und Hash-Funktionen) anzeigt.
  • Aus dieser Liste wählt der Server eine Verschlüsselungs- und Hash-Funktion aus, die er auch unterstützt, und benachrichtigt den Client über die Entscheidung.
  • Der Server sendet dann in der Regel seine Identifikation in Form eines digitalen Zertifikats zurück. Das Zertifikat enthält den Servernamen, die vertrauenswürdige Zertifizierungsstelle (CA), die für die Authentizität des Zertifikats bürgt, und den öffentlichen Verschlüsselungsschlüssel des Servers.
  • Der Kunde bestätigt die Gültigkeit des Zertifikats, bevor er fortfährt.
  • Um die für die sichere Verbindung verwendeten Sitzungsschlüssel zu generieren, führt der Client entweder Folgendes aus:
    • verschlüsselt eine Zufallszahl mit dem öffentlichen Schlüssel des Servers und sendet das Ergebnis an den Server (den nur der Server mit seinem privaten Schlüssel entschlüsseln kann); Beide Parteien verwenden dann die Zufallszahl, um einen eindeutigen Sitzungsschlüssel für die nachfolgende Ver- und Entschlüsselung von Daten während der Sitzung zu generieren
    • verwendet den Diffie-Hellman-Schlüsselaustausch, um einen zufälligen und eindeutigen Sitzungsschlüssel für die Ver- und Entschlüsselung zu generieren, der die zusätzliche Eigenschaft der Weiterleitungsgeheimnis aufweist: Wenn der private Schlüssel des Servers in Zukunft offengelegt wird, kann er nicht zum Entschlüsseln der aktuellen Sitzung verwendet werden, selbst wenn Die Sitzung wird von einem Dritten abgefangen und aufgezeichnet.

Dies beendet den Handshake und startet die gesicherte Verbindung, die mit dem Sitzungsschlüssel ver- und entschlüsselt wird, bis die Verbindung geschlossen wird.

Der Server fragt den Client zu keinem Zeitpunkt nach einem Zertifikat. In der Regel verwendet der Client in Schritt 4 (Bestätigung der Gültigkeit des Zertifikats) einen lokalen Speicher mit CA-Zertifikaten, um zu überprüfen, ob die vom Server präsentierte Zertifikatkette gültig ist. Es ist jedoch durchaus möglich, dass der Client eine andere Methode verwendet. Dies ist beispielsweise bei selbstsignierten Zertifikaten der Fall: Ihr Browser fragt Sie, ob Sie dieses Zertifikat akzeptieren möchten, das nicht verifiziert werden kann. Wenn Sie dies bestätigen, wird der Handshake erfolgreich abgeschlossen. Befehlszeilenclients wie curl und wget verfügen über Optionen, die angeben, dass Sie die Zertifikatkette nicht überprüfen möchten.

Der Client muss nicht über Zertifikate verfügen, es hat sich jedoch bewährt, zu überprüfen, wer der Server angibt, dass er es ist. Das bedeutet, dass der Client CA-Zertifikate benötigt, um die vom Server präsentierte Zertifikatkette zu überprüfen.

Der Server kann so konfiguriert werden, dass ein Clientauthentifizierungszertifikat angefordert wird. Siehe dieser MSDN-Beitrag für eine Illustration.

1
muru

TLS kann ohne "TLS" -Zertifikat funktionieren (dh es ist tatsächlich ein X.509-Zertifikat). Dies ist orthogonal. Ein Endpunkt kann über ein Zertifikat oder beide oder keines verfügen. TLS bieten verschiedene Vorteile, Authentifizierung ist nur einer von ihnen (aber der wichtigste in der Tat, über Vertraulichkeit, die oft nicht intuitiv ist)

0
Patrick Mevzek