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

[FischersFreetz]

Hallo,
Freetz-ng bringt ja curl in der Version 7.75.0 mit.

# 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.

# 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.

 

[PeterPawn]

openssl/include/openssl/sslerr.h at f62846b703d163265176fe960ec7d087b4c3fa96 · openssl/openssl

TLS/SSL and crypto library. Contribute to openssl/openssl development by creating an account on GitHub.

github.com

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.