![]() |
AW: Indy OpenSSL Sicherheitsupdates
@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:
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: ![]() @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. |
AW: Indy OpenSSL Sicherheitsupdates
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.
|
AW: Indy OpenSSL Sicherheitsupdates
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 |
AW: Indy OpenSSL Sicherheitsupdates
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) |
AW: Indy OpenSSL Sicherheitsupdates
Zitat:
vielen Dank. Das hat mir weitergeholfen. Parallel dazu habe ich in einem anderen Forum eine ![]() Die Abfrage funktioniert jetzt bestens, aber wie soll es auch anders sein - es baut sich das nächste Hindernis auf, ![]() Viele Grüße Ingo |
AW: Indy OpenSSL Sicherheitsupdates
@mezen: So wie ich die Kommentare bei Github verstanden habe ist das aktuell größte Problem, dass es Remy den Rechner zerledert hat. Deshalb stagniert da alles. Das offenbart wieder einmal das Problem kleiner Open-Source-Projekte: Es gibt nur wenige (einen?) Maintainer. Fällt da jemand aus, kann alles über die Wupper gehen. Mir sind die Indy-Eingeweide allerdings zu kompliziert, als dass ich mich da einbringen könnte. Mir hats schon gereicht damals den
![]() @ioster: Nein, du willst dir nicht THttpClient als Alternative anschauen :-D Ich habs versucht, wirklich viel Zeit in eine Portierung weg von Indy gesteckt und am Ende nur Ärger gehabt. Womit? TLS natürlich! Warum? Microsoft hatte mal wieder buggy Updates rausgegeben, die defekte Stromchiffren enthielten. Und schon glühte bei uns die Hotline weil die Kunden nicht mehr auf ihre Cloudserver kamen. Dann doch lieber Indy mit veraltetem aber funktionierendem OpenSSL. Bei den XML-Parsern ist das ganz einfach: Es gibt so viele verschiedene, weil sie alle unterschiedliche Anforderungen erfüllen. Es gibt "fette" Parser mit unheimlichen vielen Features, die aber langsam sind. Und es gibt "schlanke" schnelle Parser, wo man aber viel Aufwand hat, Daten auszulesen. Kommt also darauf an, wie groß deine XML-Dokumente sind. Bei kleiner 1 MB kannst du nehmen was du willst. Darüber sollte man ausgiebig testen welcher Parser geeignet ist. Denn da gibts kein Patentrezept. |
AW: Indy OpenSSL Sicherheitsupdates
Zitat:
ich möchte eigentlich so gut und schnell wie möglich zum Ziel kommen und stoße selbst mit zusätzlich erworbenen VCL-Komponenten leider immer wieder an (meine?) Grenzen, weil die Dokumentationen dürftig sind und Support nur bedingt geleistet wird. Es gibt solche und solche Anbieter. Ich möchte mich auf die Entwicklung einer Anwendung konzentrieren können und mich nicht unbedingt in tiefschürfende Dokumente über XML oder Ähnliches einlesen müssen. Indy ist im Augenblick für HTTP erste Wahl, weil es zum Delphi-Paket gehört und weit verbreitet ist. Für den Mailversand habe ich mir schon EasyMAPI gegönnt, da die Komponenten eher die Kundenanforderungen erfüllten. Jetzt steht für mich eben XML parsen auf der ToDo-Liste, wobei ich genau dieselbe Quelle des Bundeszentralamtes für Steuern anzapfen möchte, die im benannten Thread untersucht wird. Hier vielleicht offTopic, aber über mit welcher Methode komme ich an einen bestimmten Parameter in einem solchen XML-Dokument? Ich möchte eben nicht über String-Funktionen wie Pos oder PosEx nach den Schlüsselbegriffen suchen müssen, wenn ich schon ein XMLDocument vor mir habe. Viele Grüße Ingo |
AW: Indy OpenSSL Sicherheitsupdates
Zitat:
![]() |
AW: Indy OpenSSL Sicherheitsupdates
Zitat:
Aber vielleicht kennst du das ja alles schon. Ich habe das für verschiedene Projekte schon genutzt. |
AW: Indy OpenSSL Sicherheitsupdates
Zitat:
![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz