SSH Fingerprints geheim halten?

[Gast]

Normalerweise sind ja die Fingerprins eines SSH Servers dazu da, damit man vom Client aus überprüfen kann, ob der SSH Server der sich als {HOSTNAME} ausgibt unter der angefunkten DOMAIN auch der echte SSH Server ist, den man eigentlich erreichen will.
Natürlich muß man in diesem Fall schon vor dem Login die Fingerprints kennen und dann mit der Ausgabe im Terminal vergleichen.


Was ich aber nun wissen will.

Wenn einem Man in the Middle Angreifer die Fingerprints bekannt wären, dann könnte er die Ausgabe seines SSH Servers ja fälschen und der Clientrechner fällt auf den SSH Server ein, weil der Fingerprint ja der vermeintlich richtige ist.

Dementsprechend sollte der Fingerprint des SSH Servers niemals bekannt werden, außer halt an die Personen, die darauf zugreifen wollen.

[Hardwaretoaster]

Der Fingerprint ist ein Hash des Public Key.

Der Client nimmt diesen einen generierten Sitzungsschlüssel zu verschlüsseln. Der Angreifer kennt den zugehörigen Private-Key nicht, die erwartete verschlüsselte bestätigung vom Server an den Client ist also falsch.

Es reicht also den private-Key der asym. Verschlüsselung geheim zu halten.

[ESAD]

der fingerprint dient dem hinweis des benutzers dass sich der public key verändert hat. ein geheimhalten wäre sinnlos.

weiters dient er dem mapping von öffentliche public keys zu hostnamen. sinnvoll wenn keine zentrale verwaltung gegeben ist.

mit der authentifizierung hat er nichts zu tun. dafür verwendet man diffie hellman

[Gast]

Ihr habt beide nicht verstanden wo ich hinaus will.

Ein Man in the Middle Angreifer könnte seinen Public Key dem Nutzer geben und zwar so einen, der einen derartigen Fingerprint/Hash ergibt, der mit dem des Servers identisch ist.

Und da der Nutzer meint, der Server sei der richtige, gibt er sein Passwort ein.
Und schon ist der MitM Angreifer zwischen der Verbindung Client und Server.

[Gast]

Der Fingerprint ist ein Hash des Public Key.

Der Client nimmt diesen einen generierten Sitzungsschlüssel zu verschlüsseln. Der Angreifer kennt den zugehörigen Private-Key nicht, die erwartete verschlüsselte bestätigung vom Server an den Client ist also falsch.

Es reicht also den private-Key der asym. Verschlüsselung geheim zu halten.

Nö, in jedem Public Key Verfahren gilt es erstmal, den Fingerprint zu überprüfen, damit überhaupt sichergstellt ist, daß der Public Key auch derjenige ist, für den er sich ausgibt.

[Hardwaretoaster]

Ich gehe mal davon aus die zwei Posts stammen vom selben Gast.

Daher: Zu #4, das wäre theoretisch denkbar, aber der Angreifer müsste dazu ein Schlüsselpaar bauen, dass einen Public Key mit selben Hash produziert. Den Public-Key hast du ja verfahrensbedingt sogar, müsstest also "nur" den private Key errechnen. Wenn das aber einfach wäre, müsste der unterliegende Algo als unsicher gelten, in so nem Fall muss man sich da was Neues überlegen. (am Bsp RSA in wiki: "private Schlüssel wird geheim gehalten und kann nicht oder nur mit extrem hohem Aufwand aus dem öffentlichen Schlüssel berechnet werden")


Daraus ergibt sich für #5: Klar, gilt es das (). Aber du hast quasi ne zweite Hürde, die darin liegt, dass du dem gegenüber was verschlüsselt schickst, was er nur entschlüsseln kann, wenn er er selbst ist = den passenden private key besitzt (was wegen der Antwort zu #4 gilt.

@ESAD Diffie-hellman ist ein Verfahren zum Schlüsselaustausch. Inwiefern meinst du das mit authentifizierung? User ggü- Server gibt es zig Varianten (ggf. auch PW), andersum halt über eine lokale Vertrauen-DB oder eine öffentliche, per Zertifikat.

[ESAD]

mit diffie hellman vereinbart man den symetrischen sitzungsschlüssel mit welchen dann die client/server authentifizierung durchgeführt (bzw. deren verschlüsselte übertragung) werden kann. das hab ich damit gemeint

[Hardwaretoaster]

Gut, dann war das nur beim ersten Lesen missverständlich für mich.

[ESAD]

normalerweise stellt sich ja das problem mit den fingerprints per hand testen ja auch garnicht weil man die schlüssel ja anhand der pki einer ca überprüfen kann. (auch wenn da ein paar browser (firefox, etc) mal ein paar probleme hatten)

allgemein gilt ja z.b. md5 noch als schwach kollesionsresitent und damit auch noch als ausreichend sicher.