Warum sollten Sie vor der Authentifizierung in SSH einen gemeinsamen Sitzungsschlüssel erstellen?

544
Adrian Wydmanski

Ich wollte verstehen, wie SSH genau funktioniert, und bin auf diesen Artikel gestoßen: https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-und-connection-cocess

Der Autor schrieb, dass eine SSH-Sitzung in zwei Schritten aufgebaut wird:

  1. Client und Server stellen eine Verschlüsselung her, um die Kommunikation abzusichern
  2. Client-Authentifizierung

In der ersten Phase beteiligen sich beide Parteien an der Generierung eines gemeinsamen Sitzungsschlüssels, der zum Verschlüsseln von Nachrichten verwendet wird. Es wird während der Authentifizierungsphase verwendet:

  1. Der Client kombiniert die entschlüsselte Nummer mit dem gemeinsamen Sitzungsschlüssel, der zum Verschlüsseln der Kommunikation verwendet wird, und berechnet den MD5-Hashwert dieses Werts.

Meine Frage lautet: Warum kann ich einen gemeinsamen Sitzungsschlüssel generieren, wenn der Authentifizierungsvorgang fehlschlägt? Die Nachrichten sind ohnehin durch die Verschlüsselung mit öffentlichen Schlüsseln und die Entschlüsselung mit privaten Schlüsseln gesichert. Ist daher eine weitere Sicherheitsebene erforderlich? Oder ist es nur eine Sicherheitsmaßnahme, um sicherzugehen, dass sie sicher ist?

Es wäre für mich sinnvoller, wenn der Client zuerst authentifiziert wurde und danach ein gemeinsam genutzter Sitzungsschlüssel generiert wurde.

1

2 Antworten auf die Frage

3
jakub_d

Es sind die asymmetrischen (öffentlichen / privaten) Vorgänge, die teuer sind (je weniger, desto besser), symmetrische Krypto ist billig. SSH führt zunächst eine vollständige symmetrische Verschlüsselung zwischen Client und Server ein und beginnt dann, Authentifizierungsmethoden zu diskutieren.

Im Rahmen der Verhandlungen können mehrere Schlüssel angeboten und abgelehnt werden (Ihr Vorschlag würde dies teurer machen). Dann können andere Authentifizierungsmethoden ausprobiert werden. Sie möchten alle Lauschangriffe so wenig wie möglich über diese Phase informieren, daher ist es sinnvoll, bereits eine vollständige Ende-zu-Ende-Verschlüsselung zu verwenden.

Bonusargument: Ihr Vorschlag macht Fehlversuche günstiger, das wollen wir eigentlich nicht, sie sollten mindestens genauso teuer sein wie erfolgreiche.

Ich denke, das OP bezieht sich auf den Schlüsselaustauschprozess (der asymmetrisch und daher teuer ist) und fragt, warum dies nicht erst nach der Authentifizierung verzögert wird. grawity vor 5 Jahren 1
Vielen Dank für Ihre Antwort. Können Sie mir Quellen zur Verfügung stellen, die erklären, warum symmetrische Verschlüsselung schneller als asymmetrisch ist? Adrian Wydmanski vor 5 Jahren 0
@AdrianWydmanski - Wenn Sie einen Linux-Computer zur Hand haben, probieren Sie die Geschwindigkeit von openssl rsa2048 im Vergleich zur Geschwindigkeit von openssl aes-256-cbc; Die symmetrischen AES können auf meinem Rechner etwa 40 MB / s verschlüsseln, während der asymmetrische Teil nur ~ 300 RSA-Signaturen pro Sekunde ausführen kann. jakub_d vor 5 Jahren 0
Warum - das mag eine schwierige philosophische Frage sein. RSA beinhaltet etwas unangenehme Mathematik und große Primzahlen, während die symmetrischen Chiffren mit einfachen ganzzahligen Berechnungen genug aus den Daten machen müssen. jakub_d vor 5 Jahren 0
2
grawity

Nein. Dies ist die primäre Verschlüsselungsebene. Es gibt keine andere Schicht.

Die Nachrichten sind ohnehin durch die Verschlüsselung mit öffentlichen Schlüsseln und die Entschlüsselung mit privaten Schlüsseln gesichert

Sie sind nicht Die Verschlüsselung / Entschlüsselung mit öffentlichen Schlüsseln wird aus verschiedenen Gründen niemals zum Schutz des gesamten Datenverkehrs verwendet (z. B. erheblich schlechtere Leistung asymmetrischer Algorithmen gegenüber symmetrischer Verschlüsselung oder mangelndes Vorwärtsgeheimnis) oder einfach das Protokoll verwendet Algorithmen, die zum Signieren geeignet sind, jedoch keine Verschlüsselung.

Stattdessen verwenden sowohl SSH als auch TLS / SSL ein "Hybrid" -Modell, bei dem die öffentlichen / privaten Schlüsselpaare nur zum Aushandeln eines Sitzungsschlüssels verwendet werden (oder häufiger nur zur Sicherung der Verhandlung) und danach nicht mehr verwendet werden.

Außerdem, wie würde die Server Daten verschlüsseln, wenn der Kunde nicht hat ein Schlüsselpaar überhaupt? Denken Sie daran, dass SSH über verschiedene Client- (Benutzer-) Authentifizierungsmethoden verfügt - beispielsweise ein einfaches Kennwort, das irgendwie verschlüsselt werden muss. (Zum Vergleich: In der Regel wird die Verwendung von TLS / SSL vom Client überhaupt nicht authentifiziert.) Idealerweise würde der Authentifizierungsprozess nicht für Außenstehende sichtbar machen, wer gerade authentifiziert.

Eine Verschlüsselungsebene nur für die Authentifizierungsdetails zu haben und für den Rest der Sitzung zu einer anderen zu wechseln, wäre möglich, aber unnötig komplex - denn schließlich würde das von Ihnen erwähnte 'Problem' (einen Schlüssel erledigen) nicht einmal vermeiden Austausch vor der Authentifizierung).

Verwandte Probleme