#10054 (die Verbindung wurde vom Peer zurückgesetzt ) - tidhttp https tls 1.2

[Emwykey]

Hallo Liebes Forum,

ich versuche mit der Indy Komponente TIDHttp Abfragen an einen REST Service zu senden.
Ich verwende:
- Indy 10
- Delphi XE5
- OpenSSL 1.1.0

leider endet jeder Versuch in der Meldung #10054 Connection reset by peer...

Mit einem in C# erstellten Testprojekt laufen die Abfragen auf den Server fehlerfrei.

Ich habe es auch bereits mit den TREST.. Komponenten versucht, leider ebenfalls ohne erfolg.
Das nicht funktionierende Delphi Projekt findet ihr im Anhang.

Wenn mir irgendwer sagen kann, was fehlt oder falsch ist oder warum es nicht funktioniert wäre ich echt mega dankbar

:-D:-D


EDIT: Auch mit dem REST Debugger Tool kann keine Verbindung hergestellt werden, selber Fehler

[Emwykey]

Zur Info: Mit der TRESTClient Komponente Funktioniert es zumindest in Delphi Tokyo (10.2) - habe ich gestern getestet. Hier funktioniert auch der Aufruf mit dem REST Debugger. Es wäre aber dennoch interessant, wie das in XE 5 lösbar wäre. :-D:-D

[Olli73]

Sind die SSL-Einstellungen korrekt? Ich hatte da auch mal Probleme, weiß aber nicht mehr, ob/welche Fehlermeldung kam.

[Emwykey]

Müssten, zumindest ist nichts weiter als TLS 1.1 oder TLS 1.2 angegeben... Ich kenn mich da leider auch nicht so gut aus, hab aber viel probiert was ich so im Internet gefunden hab zu der Fehlermeldung und hat leider nichts gebracht


Funktioniert in C# auch so ( .Net 4.5 ) -- WebRequest und TLS 1.1/1.2

Allerdings was ich gerade feststellen musste, zwar funktioniert der Aufruf in der mit Tokyo erzeugten EXE mit TRESTClient, aber nicht auf Windows 7 Rechnern, bisher nur getestet auf Windows 7, Windows 10 und Windows Server 2012 R2.

Umgekehrt funktioniert der Aufruf jedoch unter Windows 10 und Windows Server 2012 R2 in XE5 compiliert auch nicht...

Es wurde sowohl ein PC mit Delphi und OpenSSL Installation sowie ein Client ohne beides getestet....

Das kann doch eigentlich nicht sein oder? Es ist wirklich das selbe Projekt, nur in der anderen Umgebung compiliert.

[mjustin]

Wenn die HTTP Requests exakt gleich sind sollte auch das Ergebnis übereinstimmen.
Für eine Vergleich der HTTP Requests kann Wireshark oder Fiddler2 (HTTP Proxy) verwendet werden. Vergleicht man einen funktionierenden und einen nicht funktionierenden Request kann man die relevanten Unterschiede aufspüren.

Aber wenn bereits der Verbindungsaufbau selber abgelehnt wird, ist es ein reines TLS/SSL Problem. Ob das so ist, sollte man im Debugger sehen können. Der Verbindungsaufbau zum Server erfolgt ja bevor die HTTP-spezifischen Pakete gesendet werden.

Allein anhand des Sourcecodes kann man das nicht sehen, es muss für diesen Test schon die URL bekannt und erreichbar sein.

[Emwykey]

Hallo, im Testprojekt ist die URL angegeben die ist auch aktiv
Ist wirklich das Selbe Projekt, der selbe Aufruf, allerdings ( Im Testprojekt auskommentiert ) über den REST Client, IDHTTP funktioniert immer noch gar nicht.
Über den REST Client erhalte ich in XE 5 beim Aufruf von SSL_Connect() in der Unit IDSSLOpenSSL, ich habe auch schon x mal openSSL neu installiert :( aber das hilft nicht

[mjustin]

Zitat:

Zitat von Emwykey (Beitrag 1399542)

Hallo, im Testprojekt ist die URL angegeben die ist auch aktiv
Ist wirklich das Selbe Projekt, der selbe Aufruf, allerdings ( Im Testprojekt auskommentiert ) über den REST Client, IDHTTP funktioniert immer noch gar nicht.
Über den REST Client erhalte ich in XE 5 beim Aufruf von SSL_Connect() in der Unit IDSSLOpenSSL, ich habe auch schon x mal openSSL neu installiert :( aber das hilft nicht

In Unit IDSSLOpenSSL wird in procedure TIdSSLSocket.Connect die Funktion SSL_Connect aufgerufen. (So circa in Zeile 3679). Der Aufruf gibt einen Errorcode zurück. Wird dieser Code ausgeführt und welchen Wert gibt der Aufruf von SSL_Connect zurück?

[Bbommel]

Hi Emwykey,

also wenn ich mir die URL von deinem REST-Sevice in den Browser kopiere (hier: Firefox), dann mag er mir die auch nicht öffnen und gibt mir eine Sicherheitswarnung aus. Und zwar so:

"Der Inhaber von hs-abnahme.a-trust.at hat die Website nicht richtig konfiguriert. Firefox hat keine Verbindung mit dieser Website aufgebaut, um Ihre Informationen vor Diebstahl zu schützen."

Das Problem scheint mir also nicht in Delphi zu liegen, sondern beim Server stimmt noch etwas nicht so ganz. Fehlendes Zertifikat, fehlendes Intermediate-Zertifikat oder irgendwie so etwas ist ja der Klassiker bei SSL-Verbindungen. Ich würde also erst einmal schauen, dass das läuft und erst danach in Delphi weiterforschen.

[Thomas Horstmann]

Welche OpenSSL DLLs werden denn benutzt? 1.1.0 oder 1.0.2? Soweit ich weiß unterstützt Indy nur 1.0.2.

[HolgerX]

Hmm

habe mir auch mal die URL aus deinem Projekt geholt und auch mit Chrome dauert es Ewigkeiten, bis eine Antwort kommt.

Ein kleiner Test mit INDY gibt mir nen SocketError 10060 Connection Timeout...

Ich denke auch, da ist was mit dem Server nicht OK ;)

(Test mit D6 + INDY 10.6.2 + DLLs (1.0.2.11))

Andere HTTPS-Server liefern problemlos ihre Daten ;)

[Emwykey]

Zitat:

Zitat von Thomas Horstmann (Beitrag 1399556)

Welche OpenSSL DLLs werden denn benutzt? 1.1.0 oder 1.0.2? Soweit ich weiß unterstützt Indy nur 1.0.2.

Aktuell 1.1.0 ich versuche es mal mit 1.0.2 und berichte


EDIT: Ok, funktioniert leider nicht...

[Emwykey]

Zitat:

Zitat von HolgerX (Beitrag 1399559)

.....
Ich denke auch, da ist was mit dem Server nicht OK ;)
.....

Hatte ich mir auch überlegt, gerade da auch der Aufruf anderer https services bei mir ebenfalls keine probleme verursacht hat, allerdings finde ich es doch seltsam, dass es in C# generell und auch unter delphi tokyo in kombination mit WIN10 ohne weiteres klappt :((( echt zum verzweifeln

[Bbommel]

Seltsam ist das nicht unbedingt. Wenn du den TRESTClient in Tokyo nutzt, dann nutzt der ja normalerweise kein Indy mehr, sondern lässt das HTTPS-Zeugs von Windows regeln. Genauso könnte es ja mit C# sein. Diese anderen SSL-Implementierungen können z.B. andere Zetrifaktslisten haben von bekannten Zertifizierungsstellen und brauchen daher z.B. ein Intermediate-Zertifikat nicht, welches ein anderer braucht.

Ich hatte das z.B. mal mit einem eigenen Server. Bei 1&1 damals ein Zertifikat gekauft und versucht es einzurichten. Bei Chrome lief dann auch https problemlos, mit Firefox kam ich aber nicht weiter. Bei mir war es dann nämlich genau so ein Problem mit dem Intermediate-Zertifikat, welches Firefox offenbar brauchte, wovon ich aber das falsche eingespielt hatte. Wenn ich das alles noch richtig rekonstruiert bekomme. :-)

[Emwykey]

Zitat:

Zitat von Bbommel (Beitrag 1399576)

.... Wenn du den TRESTClient in Tokyo nutzt, dann nutzt der ja normalerweise kein Indy mehr,...

Danke für die Antwort, aber auch mit TRESTClient funktioniert es in XE5 und vor allem unter Windows 7 sowieso garnicht :O
hab auch schon bereits versucht in der Registry TLS 1.1 und TLS 1.2 als Default Secure Protocols (https://support.microsoft.com/en-au/...e-protocols-in) zu hinterlegen geht leider trotzdem nicht auf Windows 7, auf 10 immernoch nur die in Tokyo compipierte EXE des selben Projekts


Bin zwischenzeitlich von dem Versuch mit Indy abgekommen da es einfach nicht klappen wollte

[Bbommel]

Wie gesagt - warum sich unterschiedliche Systeme unterschiedlich verhalten (Win 7 vs. Win 10, Indy vs. Windows selbst), hatte ich ja grob versucht zu beschreiben.

Aus meiner Sicht liegt der Fehler nicht beim Client, also deinem Programm, egal ob nun mit Indy oder nicht, sondern beim Server. Falls das deiner ist, müsstest du da vielleicht noch mal schauen, wo es bei den Zertifikaten oder anderen Teilen der Konfiguration hakt oder du müsstest den Admin mal darauf hinweisen. Teste es einfach selber mal mit dem Firefox.

Viel Glück. :-)

[Emwykey]

Zitat:

Zitat von Bbommel (Beitrag 1399590)

... Teste es einfach selber mal mit dem Firefox.

Viel Glück. :-)

Habe ich, und danke nochmal für die Antwort. Der Aufruf funktioniert in Chrome und Firefox ABER Firefox meldet, dass es sich nicht um eine sichere Verbindung handelt und ich muss vorerst eine Ausnahme zufügen. Ich werde das so an den Betreiber weiterleiten :)

[Olli73]

Wenn es nur am Zertifikat hängt, kannst du evtl. Mit idssliohandlersocketopenssl.onverifypeer eingreifen.

[mjustin]

Die Validierung durch https://www.ssllabs.com/ssltest/index.html ergibt Trust-Probleme und ein Problem mit der Zertifikatskette.

Dem Zertifikat wird nicht von den Trust Stores von Mozilla, Apple, Android und Java vertraut. Das erklärt, dass Chrome keinen Zertifikatsfehler anzeigt (Chrome verwendet den Windows Zertifikatsspeicher, Firefox einen eigenen).

Zur Diagnose von OpenSSL Verbindungsfehlern kann man mit openssl s_client -connect example.com:443 einen Verbindungsaufbau testen.

Das gibt zum Beispiel auf einem Linux-Client diesen Fehler aus: unable to get local issuer certificate

Zitat:

CONNECTED(00000003)
depth=1 C = AT, O = ..., OU = ..., CN = ...
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
...
---

Auf verschiedenen Computern und mit verschiedenen Frameworks kann es unterschiedliche Ergebnisse geben, je nachdem ob das Zertifikat jeweils im lokalen Zertifikatsspeicher vorhanden ist oder (noch) nicht.

Vielleicht hilft das ja weiter.

[Emwykey]

Zitat:

Zitat von Olli73 (Beitrag 1399652)

Wenn es nur am Zertifikat hängt, kannst du evtl. Mit idssliohandlersocketopenssl.onverifypeer eingreifen.

Es klappt!!!!!!! Viele vielen Dank!!!!!!!