Indy & OpenSSL 1.1.1 & TLS 1.3

[mezen]

Hi,

als ihr den Titel gelesen habt, habt ihr bestimmt bereits die Standard-Antwort im Kopf gehabt: "Geht mit Indy nicht, unterstützt nur maximal OpenSSL 1.0.2 und damit kein TLS 1.3".
Da kann ich euch beruhigen, darum geht es mir nicht. Bzw. eigentlich sogar genauer: Genau darum geht es mir

Ich hab jetzt "ein bissl" Zeit darin investiert die Indy Unterstützung für OpenSSL 1.1.1 zu schreiben und damit TLS 1.3. Dafür gibt auch einen Push Request zu Indy hin: #299. Gleichzeitig hab ich ein paar Issues, welche bei GitHub hinterlegt worden sind gleich mit gefixt (stehe im PR drin).

Dazu habe ich 2 neue IO Handler geschrieben (einmal Server und einmal Client), die bisherigen sind unverändert um keine Konflikte zu verursachen.
Geschrieben und getestet wurde alles in Delphi Berlin 10.1.2 auf Win32 und Win64. Ich hab weder macOS noch iOS noch Linux noch Android, noch FreePascal, noch ältere (bzw neuere) Delphi Versionen. Ich hab zwar versucht ältere Delphi Versionen im Hinterkopf zu behalten, damit es darauf auch läuft, allerdings gabs dazu noch keine Tests meinerseits.
Getestet habe ich es ausgiebig in kleinen Test Anwendungen auch mit anderen Servern/Clients. Zusätzlich hab ich in ein großes Real World Programm, mit TCP Server/Client, SMTP/IMAP/POP Clients, FTP Client, HTTP Client, eingebaut und auch dort lief es problemlos.

Leider hat der nette Herr, welcher bisher unter indy.fulgan.com neue Binär Dateien von OpenSSL zur Verfügung gestellt hat, gesagt dass er keine Versionen > 1.0.2 mehr anbietet. Daher habe ich anfangs die Versionen von slWebPro genutzt (funktionieren sogar noch auf WinXP), später dann die von Overbyte, da diese ohne externe Abhängigkeiten auskommen (und digital signiert sind, aber kein XP mehr^^). Aber beide haben problemlos funktioniert.

Alle Dateien befinden sich im Unterordner "Lib/Protocols/OpenSSL". Dort befinden sich auch Unterordner "static" und "dynamic" welche ziemlich umfangreiche Imports der OpenSSL API bietet, einmal für statische Verlinkung, einmal zum dynamischen Laden/Entladen. Fürs dynamische Laden gibt es auch in der "IdOpenSSLLoader.pas" Möglichkeiten das Laden/Entladen selbst anzutriggern, falls man die API mal außerhalb des IO Handlers benötigt (z.B. für eigene x509 Generierungen).
Um mir das doppelte Schreiben der Imports zu sparen, habe ich im Ordner "Intermediate" eine Art von ZwischenCode geschrieben, welche ich dann mit "GenerateCode" zu den beiden Varianten generieren lasse. Das Tool "GenerateCode" ist nur simples String Anpassen und tatsächlich auch nur auf Berlin ausgelegt, da hab ich mir keine Mühe für abwärts Kompatibilität gemacht. Als normaler Benutzer der IO Handler braucht man diese auch nicht, erst wenn man Änderungen an der API Implementierung vor nimmt.


So und jetzt kommt ihr. Es wäre schön wenn der ein oder andere dies mal testen würde, damit es nicht nur WOMM zertifiziert ist, sondern mehr Echt-Situationen durchsteht.
Bei mir läuft es auch mit dem Indy, welches bei Delphi Berlin mitgeliefert wird, wenn ich eine weitere Unit erstelle, welche ein paar neue Indy Typen und Funktionen zur Verfügung stellt. Natürlich müssen dann ein paar Units lokal angepasst werden, damit diese die neue Unit usen.

MfG
mezen

[DieDolly]

Erstmal danke für deine Arbeit, die der zukünftigen Sicherheit dient.

Zitat:

Leider hat der nette Herr, welcher bisher unter indy.fulgan.com neue Binär Dateien von OpenSSL zur Verfügung gestellt hat, gesagt dass er keine Versionen > 1.0.2 mehr anbietet.

Wie ist das zu verstehen? Wird es mal keine aktuellen ssl-dll-Dateien mehr geben?
Ich benutze bisher immer libeay32.dll und ssleay32.dll. Welche muss man denn jetzt von overhead nutzen?

[mezen]

Er würde neuere OpenSSL 1.0.2 Dateien vermutlich dort eintragen, wenn OpenSSL neue Versionen erstellen würde. Alles mit "würde", weil OpenSSL gesagt hat, dass 1.0.2 End of Life erreicht hat und nicht mehr weiter gepflegt wird.
Für OpenSSL 1.1.1 müsste er seine Build Umgebung und Prozess umbauen, was einiges an Aufwand in Anspruch nehmen würde. Daher keine neueren Versionszweige als 1.0.2.

[DieDolly]

Das habe ich noch immer nicht richtig verstanden.
Was bedeutet das in normaler, deutscher Sprache für die Zukunft und Delphi?

[mezen]

Ok, kurz und in verständlicher Sprache: OpenSSL 1.0.2 End of Life (= tot), gibt keine Updates mehr. Sollte da eine Sicherheitslücke drin sein, wird diese nicht mehr gefixt.
(Außer OpenSSL sagt "Uh, da war sowas gravierendes drin, da könnten wir nochmal was für das uralte, und schon angeschimmelte, 1.0.2 was machen, weil das noch so viele nutzen)

[DieDolly]

Ach so ok. Und alles neuere wird fulgan nicht mehr unterstützen. Deswegen jetzt deine Umsetzung.
Wie kommt Indy denn dann mit den neuen DLLs klar denn die heißen doch bestimmt anders als die von fulgan.
Ich würde das sehr gerne testen aber habe keine Ahnung wie.

[Hobbycoder]

Erst mal ein fettes RESPEKT !!!

Wo könnte man sich denn deine neuen Bibliotheken herunterladen?

[mezen]

Über den PR kommst du auf diesen GitHub Fork: https://github.com/mezen/Indy/tree/NewOpenSSL_PR

[TurboMagic]

Zitat von DieDolly:

Ach so ok. Und alles neuere wird fulgan nicht mehr unterstützen. Deswegen jetzt deine Umsetzung.
Wie kommt Indy denn dann mit den neuen DLLs klar denn die heißen doch bestimmt anders als die von fulgan.
Ich würde das sehr gerne testen aber habe keine Ahnung wie.

Ich kenne diese angesprochene Person sogar persönlich, diese war der vorhergehende Maintainer der DEC Bibliothek, ist als Freelancer aber scheinbar so total ausgebucht und das derzeit leider nicht mehr mit Delphi Projekten, dass an andere Open Source Projekte scheinbar nicht mehr zu denken ist.

Er war früher auch hier im Forum unterwegs und hat auch mit diese OpenSSL Sache schon mal erklärt.
Aber wenn die OpenSSL Bibliotheken von ICS gut Funktionieren wäre das auch eine Lösung.

Da derzeit Delphi 10.4 in Entwicklung ist, wäre es super, wenn dieser Pull Request zeitnah in Indy einfließen könnte und EMBT dann gleich diese Fassung ausliefern würde.

Aber auch von mir: super, dass das umgesetzt wurde!

[DieDolly]

Zitat:

Da derzeit Delphi 10.4 in Entwicklung ist, wäre es super, wenn dieser Pull Request zeitnah in Indy einfließen könnte und EMBT dann gleich diese Fassung ausliefern würde.

Ich denke das kannst du gleich wieder streichen. Wenn du Gründe suchst, einfach das hier durchlesen https://www.delphipraxis.net/203977-...ml#post1463330

Ich habe trotzdem noch nicht verstanden, wie man diese angeblichen Änderungen denn jetzt nutzt und welche neue DLL man nutzen soll. Und wie überhaupt die funktionieren soll, wenn die einen anderen Dateinamen hat als die von fulgan,