Indy OpenSSL Sicherheitsupdates

[Codehunter]

Zitat von HolgerX:

Dass mag zwar für die DLLs gelten, jedoch die 'Developer Snapshots' als Zip gehen nicht mehr und deren Links laufen ins Leere..

Das ist doch nun wirklich nicht schwer... https://github.com/IndySockets/Indy

[ioster]

Moin,

ich benötige für eine Programmfunktion eine HTTPS-Verbindung zu einem Datenserver, die ich gerne mit IdHTTP-Komponente aus Indy10 (Delphi 10.3) umsetzen würde.

Ich dachte, die Abfrage relativ schnell umsetzen zu können, doch ich habe nicht mit den Unzulänglichkeiten der IDE gerechnet. Man sollte meinen, dass HTTPS heute als Standard angesehen wird.

Als die Meldung "SSL-Bibliothek konnte nicht geladen werden." auf dem Bildschirm erschien, suchte ich zunächst vergeblich in den Eigentschaften der Komponente nach der Lösung. Google sagte mir dann, man müsse die libeay32.dll und ssleay32.dll in sein Programmverzeichnis kopieren, um das Protokoll nutzen zu können.

Die Vorgehensweise wird u.a. in einem Tutorial auf dieser Forenseite beschrieben. Nur dumm, dass die Links zu den DLLs überall veraltet sind. Indy Project verweist aua urheberrechtlichen Gründen auf GitHub als Downloadseite.

Nur was soll man hier nun auswählen? Ist das der letzte Stand und wie erfährt man von möglichen Updates?

Ich wäre für aktuelle Infos mehr als dankbar. Der Zeitaufwand für die bisherige Recherche, die in vielen toten Links endete, war nicht ohne.

Danke im Voraus.
Ingo

[Codehunter]

Das kann ich gut verstehen. Die Situation mit den Win32-Binaries für OpenSSL ist wirklich nicht schön. Darüber habe ich mich auch schon oft geärgert. Also ich verwende die 1.0.2s mit Indy 10. Die letzte Minor-Version aus dem 1.0.2-Zweig ist die "u". Dabei jeweils auf 32- und 64 Bit achten, je nach Bedarf. Da musst du auch aufpassen wenn du dein Programm auslieferst, weil die Dateinamen der DLLs bei 32 und 64 Bit identisch sind.

Soweit ich weiß braucht Indy 10 keine speziellen OpenSSL-DLLs mehr, wie es noch bei Indy 9 der Fall war. Man könnte sie also aus den offiziellen Quellen selbst kompilieren. Was ich aber noch nie gemacht habe mangels tieferes Wissen über C++.

Wirklich ein Problem ist aber, dass Indy so weit hinten dran ist mit der Unterstützung für OpenSSL 1.1.1. Schließlich ist der 1.0.2-Zweig schon seit zwei Jahren aus dem aktiven Support raus. Es gibt inzwischen lauffähige Entwicklersnapshots, aber stabil ist das IMHO noch nicht.

[ioster]

Zitat von Codehunter:

Das kann ich gut verstehen. Die Situation mit den Win32-Binaries für OpenSSL ist wirklich nicht schön. Darüber habe ich mich auch schon oft geärgert. Also ich verwende die 1.0.2s mit Indy 10. Die letzte Minor-Version aus dem 1.0.2-Zweig ist die "u". Dabei jeweils auf 32- und 64 Bit achten, je nach Bedarf. Da musst du auch aufpassen wenn du dein Programm auslieferst, weil die Dateinamen der DLLs bei 32 und 64 Bit identisch sind.

Soweit ich weiß braucht Indy 10 keine speziellen OpenSSL-DLLs mehr, wie es noch bei Indy 9 der Fall war. Man könnte sie also aus den offiziellen Quellen selbst kompilieren. Was ich aber noch nie gemacht habe mangels tieferes Wissen über C++.

Wirklich ein Problem ist aber, dass Indy so weit hinten dran ist mit der Unterstützung für OpenSSL 1.1.1. Schließlich ist der 1.0.2-Zweig schon seit zwei Jahren aus dem aktiven Support raus. Es gibt inzwischen lauffähige Entwicklersnapshots, aber stabil ist das IMHO noch nicht.

Moin Codehunter,

vielen Dank für Deine Ausführungen, die für mich ein wenig Licht ins Dunkel bringen. Ich werde es mit den 1.0.2u einfach ausprobieren. Sollte es nicht funktionieren, muss ich die Anforderung vorerst zurückstellen.

Viele Grüße
Ingo

[mezen]

@ioster:
TLS ist kein leichtes Protokoll und bringt einige Eigenschaften mit sich, TLS ist schwierig "mal eben" zu begreifen und entsprechend dem Verständnis sinnhaft und zielgerichtet einzusetzen.

Aktuelle Infos kurzgefasst:

• Indy nutzt OpenSSL
• Indy 9 brauchte spezielle OpenSSL Binaries, welche für Indy angepasst waren. Indy 10 braucht das nicht mehr und es reichen unveränderte aus
• Mitgeliefertes Indy kann nur maximal OpenSSL 1.0.2 (und daher TLS 1.2)
• OpenSSL 1.0.2 ist Ende 2019 aus dem Support gefallen und wird nicht mehr mit Sicherheitsupdates versorgt
• Aktuell neuste und stabile Version ist OpenSSL 1.1.1, Vorgänger war OpenSSL 1.1.0, dessen Vorgänger OpenSSL 1.0.2 war
• Nachfolger OpenSSL 3 ist aktuell frisch in der Beta, nach etwas über 1 Jahr in der Alpha
• Bisher genutzten OpenSSL Binaries wurden von https://opendec.wordpress.com/ erstellt, welcher seine Build Umgebung nicht mehr auf Versionen nach 1.0.2 umgestellt hat
• OpenSSL Version 1.1.0 hat API Änderungen gegenüber OpenSSL 1.0.2, was auch Änderungen in Indy selber benötigt

So weit, so schlecht die Infos.
Aber es gibt weiterhin Hoffnung: Es gibt bereits Anpassungen für Indy, damit Indy auch OpenSSL 1.1.1 nutzen kann: https://www.delphipraxis.net/204185-...tls-1-3-a.html. Dies befindet sich noch im GitHub PR und wartet darauf, dass es nach Indy gemergt wird. Die Änderung läuft auch stabil, ist bei unseren Kunden bereits dauerhaft aktiv und viel genutzt.

@ioster:
Du willst dir vllt als Alternative THttpClient von Emba angucken. Dies ist ein Versuch mittels System APIs, und nicht mit Indy, HTTP nutzbar zu machen. Und das sogar plattformübergreifend (was Indy ja auch bereits kann). Auf Windows wird dafür auf die WinAPIs für WinHTTP zurück gegriffen. Somit brauchst du keine OpenSSL DLLs, da Windows das eigene SChannel nutzt.

@Codehunter:
Danke für deinen Bump bei meinem MR. Aktuell laufen die Änderungen gut, wie ich schrieb, auch schon bei unseren Kunden im Einsatz. Ich muss nur halt warten bis Remy mit dem Review fertig ist. Da er aber nur rein den Code anguckt, und das doch ein paar viele Zeilen beinhaltet, dauert das leider. Mehr kann ich leider nicht tun.

[philipp.hofmann]

Und falls es nicht unbedingt Indy sein muss: bei der Implementierung mit TNetHTTPClient (und TNetHTTPRequest) wird automatisch https über die vorhandenen OS-Komponenten gelöst. Das ist deutlich zukunftssicherer, geht aber nicht für alle Anwendungsfälle.

[ioster]

Moin,

ich muss nochmal stören. Die DLLs aus dem 1.0.2u-Paket haben schon ein wenig gefruchtet. Allerdings bekomme ich nun die Meldung, dass ich meine Anfrage mit der falschen Protokollversion sende.

Die Meldung lautet:

Fehler beim Verbinden mit SSL.
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
protocol version.

Laut Dienstanbieter sollen die Anfragen mit TLS 1.2 erfolgen sollen. Hat jemand sich damit schon auseinandergesetzt?

Danke
Ingo

[mezen]

TIdHTTP erstellt sich einen eigenen TIdSSLIOHandlerSocketOpenSSL, sofern man nicht selber einen IOHandler zuweist. Dieser selbsterstellte hat aber nur die Default Eigenschaften was TLS 1.0 entspricht.
Erzeuge einen eigenen TIdSSLIOHandlerSocketOpenSSL und setze dort SSLOptions.SSLVersions := [sslvTLSv1_2] (SSLOptions.Method ist deprecated und Überbleibsel aus Indy 9)

[ioster]

Zitat von mezen:

TIdHTTP erstellt sich einen eigenen TIdSSLIOHandlerSocketOpenSSL, sofern man nicht selber einen IOHandler zuweist. Dieser selbsterstellte hat aber nur die Default Eigenschaften was TLS 1.0 entspricht.
Erzeuge einen eigenen TIdSSLIOHandlerSocketOpenSSL und setze dort SSLOptions.SSLVersions := [sslvTLSv1_2] (SSLOptions.Method ist deprecated und Überbleibsel aus Indy 9)

Hallo mezen,

vielen Dank. Das hat mir weitergeholfen. Parallel dazu habe ich in einem anderen Forum eine Quellcode gefunden, der die Erstellung eines IOHandlers beschreibt.

Die Abfrage funktioniert jetzt bestens, aber wie soll es auch anders sein - es baut sich das nächste Hindernis auf, das Parsen des XML-Rückgabewerts. Es ist faszinierend, wie man sich in dem Thread "XML parsen, aber wie" über das Für und Wider eines XML-Parsers streitet, doch letztlich hat man auf der 3. Seite wieder einen Cliffhanger.

Viele Grüße
Ingo

[Carsten Hölscher]

Zitat von Codehunter:

Das kann ich gut verstehen. Die Situation mit den Win32-Binaries für OpenSSL ist wirklich nicht schön. Darüber habe ich mich auch schon oft geärgert. Also ich verwende die 1.0.2s mit Indy 10. Die letzte Minor-Version aus dem 1.0.2-Zweig ist die "u". Dabei jeweils auf 32- und 64 Bit achten, je nach Bedarf. Da musst du auch aufpassen wenn du dein Programm auslieferst, weil die Dateinamen der DLLs bei 32 und 64 Bit identisch sind.

Also sehe ich das richtig, dass für 32- und 64-bit Versionen meiner exe in beiden Fälln der Dateiname ssleay32.dll und libeay32.dll lautet?

Also mal im Gesamtzusammenhang, folgender Download: https://indy.fulgan.com/SSL/

32 bit Windows: 32 bit Anwendung: dlls aus openssl-1.0.2q-i386-win32.zip
32 bit Windows: 64 bit Anwendung: geht nicht
64 bit Windows: 32 bit Anwendung: dlls aus openssl-1.0.2q-i386-win32.zip
64 bit Windows: 64 bit Anwendung: dlls aus openssl-1.0.2q-x64_86-win64.zip

Korrekt verstanden? Wenn ja halte ich das für eine etwas ungewöhnliche und verwirrende Benennung, oder gibt es einen Grund, die nicht unterschiedlich zu nennen?

Carsten