Das sieht eher nach einem TLS-Problem aus ... der
.config nach ist
openssl auch im Image (sogar statisch gelinkt, Platz war/ist hier also kein Punkt) und daher würde ich das mal mit dem
s_client-Modul des
openssl-Kommandos versuchen. Da kann man dann wunderbar alle notwendigen Optionen angeben (viele vergessen gerne mal
-servername, was dann keinen SNI-Header sendet und auch zum Abbruch führen könnte bei einem Host mit vielen virtuellen Servern - wobei das BusyBox-
wget eine SNI sendet und der Server ist ja offensichtlich ein IIS 10 von MS) und dann sieht man zumindest schon mal, ob die TLS-Verbindung überhaupt bis zum Lesen zu tunnelnder Daten kommt (wo man dann auch noch ein HTTP-
GET von Hand eingeben könnte:
GET /hosts.txt HTTP/1.0, gefolgt von 2x Enter-Taste) oder ob die schon vorher geschlossen wird - zum Beispiel, weil man keine gemeinsame Basis bei den zu verwendenden TLS-Standards findet.
EDIT:
Wenn man tatsächlich versuchen wollte, die gesuchte Datei per manuellem GET-Kommando von DIESEM Server zu laden, muß man vermutlich doch umfangreichere Header verwenden - zumindest einen passenden
Host-Header, denn offensichtlich beherbergt dieser Server mehr als eine Präsenz und da braucht's dann diesen Header, um den richtigen davon auszuwählen (die SNI erleichtert nur die Auswahl des passenden Zertifikats, wenn der Server über mehrere verfügt).
Da dieser Server offenbar nur max. TLS 1.2 beherrscht, wird meine Vermutung - abhängig von der Konfiguration der OpenSLL-Libraries, die von Freetz-NG verwendet wird, denn beim (internen) Aufruf aus
wget (der Busybox) werden da keine weiteren Angaben gemacht - wahrscheinlicher, falls die Libs/das CLI-Programm nur noch TLS 1.3 akzeptieren/anbieten sollten, sofern nichts anderes per Parameter/Option festgelegt wurde. Zwar ist TLS 1.2 (afaik) offiziell noch nicht "deprecated" (
https://datatracker.ietf.org/doc/rfc8996/), aber die aktuellen Standardeinstellungen von OpenSSL (wo es ja auch noch unterschiedliche Versionsstränge gibt) und was davon von Freetz(-NG) beim Build wie umgestellt wird, habe ich nicht auf dem Schirm.
Da das BusyBox-Applet aber nur mit einer Pipe nach/von
openssl s_client arbeitet und auch noch STDERR ignoriert wird, kann
wget da häufig keine präzisen Infos zum Grund eines Fehlers ermitteln und wenn der Server eine TLS-Verbindung wg. irgendwelcher Unstimmigkeiten ablehnt, schließt er üblicherweise auch die darunter liegende TCP-Verbindung (ansonsten werden ja Ressourcen am Server blockiert). Der Grund dafür wurde dann i.d.R. vorher in der TLS-Aushandlung mitgeteilt - nur interessiert sich
wget (als Applet) eben nicht für diesen Teil der Kommunikation und sieht damit nur das Resultat. Es hat ja auch Gründe, warum es bei
curl (und auch beim "ausgewachsenen" (GNU-)
wget) eine ganze Reihe weiterer Parameter zum Konfigurieren von TLS-Verbindungen gibt. Damit will ich nicht unbedingt behaupten, daß es mit
curl oder dem "richtigen"
wget auch hier funktionieren müsse - aber die sind hinsichtlich der Ursachen eines Problems deutlich aussagefreudiger.
