[Problem] Curl (v. 7.75.0) - Problem/Phänomen bei einer url Fehler: curl: (35) error:14094410:lib(20):func(148):reason(1040)

FischersFreetz

Neuer User
Mitglied seit
22 Feb 2019
Beiträge
173
Punkte für Reaktionen
25
Punkte
28
Hallo,
Freetz-ng bringt ja curl in der Version 7.75.0 mit.
Code:
# curl -Version
curl 7.75.0 (mips-unknown-linux-gnu) libcurl/7.75.0 OpenSSL/1.1.1j
Release-Date: 2021-02-03
Protocols: file ftp ftps http https mqtt rtsp
Features: alt-svc AsynchDNS HTTPS-proxy IPv6 Largefile NTLM NTLM_WB SSL UnixSockets
Kommischerweise erhalte ich nur(?) bei einer url eine Fehlermeldung, andere urls funktionieren problemlos.
Rich (BBCode):
# curl -v https://easylist.to/easylist/easylist.txt 
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS alert, handshake failure (552):
* error:14094410:lib(20):func(148):reason(1040)
curl: (35) error:14094410:lib(20):func(148):reason(1040)
(CA-bundle war/ist ausgewählt und Parameter --insecure oder --cacert cacert.pem ändern nichts am Fehlerbild.)

Rufe ich curl in der (Vorgänger)-Version 7.69.1 mit der selben url auf, kann ich die Datei herunterladen.

(Das Ganze passiert auf einer 7590 - Firmeware-Version 7.12 - Freetz-Version freetz-ng-18132MA-840bf0bb9)

Kann jemand dieses Problem bestätigen, erklären, (abstellen)?

EDIT:
Nach einem Firmware-Update auf 7.21 tritt dieses Phänomen nicht mehr auf.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,768
Punkte für Reaktionen
1,261
Punkte
113

Ich tippe mal auf einen Fehler bei der Auswahl der Protokoll-Version - wobei die Domain wohl mal wieder eine von denen ist, die über Cloudflare als Reverse-Proxy laufen und da kann das auch ein (vielleicht sogar nur temporärer) Fehler bei denen gewesen sein ... auch kein Einzelfall und selbst hier für's IPPF haben bestimmt schon einige ab und an im Browser erlebt, daß der sich über eine Protokoll-Verletzung beim Aufruf einer Seite von hier beschwert.

Wenn's tatsächlich permanent auftritt und auch ein openssl s_client ... das reproduzieren kann (da gibt's dann auch noch Optionen, die übertragenen Daten im Handshake auszugeben), erst dann lohnt es sich, da irgendwie weiter drüber nachzudenken.

Denn eigentlich paßt schon die "Fehlerklasse" (das ist die Range, die für SSLv3 genutzt wurde) so gar nicht mehr in die heutige Zeit - auch wenn ich nicht beschwören will, ob auch die späteren TLS-Versionen noch diesen SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE-Fehlercode verwenden oder nicht.
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via