Ich schreibe ein Client/Server-TCP-Programm und möchte die Verbindung mit TLS verschlüsseln und authentifizieren. Mein Plan war, dass Clients öffentliche RSA-Schlüssel an den Server senden und dann den privaten Schlüssel und einen Benutzernamen verwenden, um die Identität des Clients zu authentifizieren und die Verbindung zu verschlüsseln.Wie wird eine TLS-Verbindung mit öffentlichen/privaten RSA-Schlüsseln und GnuTLS hergestellt?
Die GnuTLS-Dokumentation lässt viel zu wünschen übrig, aber ich fand ein gutes PSK-Beispiel und versuchte, es anzupassen, um RSA asymmetrische Schlüssel zu verwenden. Nachdem ich meinen Kopf gegen dieses Problem gestoßen habe, insbesondere alle Arten von obskuren Feinheiten, die nicht klar in der Dokumentation beschrieben sind, habe ich den Client nicht mehr darüber zu beklagen, dass "keine unterstützten Cipher Suites gefunden wurden", sondern jetzt der Server.
Nach noch mehr Suche im Internet fand ich ein Testprogramm, das Teil von GnuTLS CI ist, testet RSA-PSK und ich erkannte, dass der gemeinsame Schlüssel immer noch symmetrisch ist. RSA-PSK ist nicht das, was ich dachte.
Ich mag es wirklich nicht, einen symmetrischen Schlüssel zu verwenden, da er auf der Serverseite in Plain gespeichert werden muss und daher unsicher ist.
Ein kurzer Blick auf RSA-Schlüsselaustausch schlägt jedoch vor, dass kein Benutzername beteiligt ist und es tatsächlich Zertifikat basiert, und dass der Server seinen eigenen privaten Schlüssel verwendet, während alle Clients denselben öffentlichen Schlüssel verwenden. Somit ist es unmöglich, die Identität eines Kunden zu garantieren.
Nachdem ich einen Tag damit verbracht habe, TLS zur Arbeit zu bringen und es verabscheute, das Rad neu zu erfinden (was immer ein Sicherheitsrisiko darstellt), frage ich hier, ob es Experten gibt, die mich beraten können was ich erreichen möchte. Die einzige Lösung, die einem einfällt, ist ziemlich dreckig und hacky (und erfindet das Rad neu), nämlich einen Pre-TLS-Handshake-Handshake zu implementieren, bei dem der Client einen zufälligen Schlüssel generiert, ihn mit seinem privaten Schlüssel verschlüsselt und sendet es und den Benutzernamen an den Server, der dann den öffentlichen Schlüssel verwendet, um es zu entschlüsseln. GnuTLS kann dann den normalen symmetrischen PSK-Schlüsselaustausch unter Verwendung des Zufallsschlüssels verwenden.
Ich verstehe nicht, warum GnuTLS sowas sowieso nicht implementiert. Ich erwartete, dass der GnuTLS-Client den Benutzernamen an den Server sendet. Der Server führt dann einen Schlüsselaustausch durch, indem er Schlüssel für die Verschlüsselung generiert und sie mit dem öffentlichen Schlüssel des Clients verschlüsselt und den verschlüsselten Schlüssel an den Client sendet. Der Client entschlüsselt den Schlüssel mit seinem privaten Schlüssel und siehe da, der Schlüsselaustausch ist sicher abgeschlossen und der TLS-Kanal ist offen.
Also zusammenfassend:
1) Wie erreiche ich, was ich (am besten mit GnuTLS) erreichen müssen?
2) Warum funktioniert RSA-PSK nicht wie erwartet und verwendet stattdessen symmetrische Schlüssel und ein Zertifikat?
Nachdem ich dies ein paar Mal gelesen habe, habe ich immer noch keine Ahnung, was Sie zu tun versuchen. Vielleicht können wir mit den Grundlagen beginnen: Was ist falsch an einem guten, alten Standardserver-authentifizierten TLS? –
Ich muss den Client authentifizieren, nicht den Server. Wenn ein Angreifer den Server täuscht, erreichen sie nichts. Was ich zu erreichen versuche, ist eher eine SSH-Verbindung, bei der nur bestimmte Clients eine Verbindung herstellen können und sie ihre Identität nachweisen müssen. Ich möchte, dass die Authentifizierung nach dem öffentlichen Schlüssel erfolgt. Dies alles wird im ersten Absatz behandelt. Ich möchte auch die Komplexität der Zertifikatsunterzeichnungsketten vermeiden. – AlastairG
Ich möchte auch die Datenverbindung verschlüsseln.Ich möchte PSK nicht verwenden, da es sich um eine symmetrische Verschlüsselung handelt. Wenn unsere Datenbank kompromittiert ist, kann der Angreifer auf unser System zugreifen (obwohl, wenn sie die Datenbank greifen können, sie wahrscheinlich auch alle anderen Dinge tun können, aber trotzdem). SRP sieht zwielichtig aus - es gibt keine wirkliche Erklärung dafür, wie sicher es ist. Unabhängig davon, ob Sie das Kennwort oder das verfälschte Kennwort für den Austausch von Schlüsseln senden, scheint es trotzdem so zu sein, als ob es im Klartext gesendet würde. – AlastairG