-[gedankenkraut]-

╔═════════════════════════════════════════════════════════════════════╗ ║ neues curl in altem kernel ║ ║ Donnerstag, 17. Oktober 2019, 01:16 errorpriester ║ ╚═════════════════════════════════════════════════════════════════════╝

Ich hab hier ein Gerät (ARMv5) in meinem LAN daß aus Gründen™ ein antikes Arch-Linux mit Kernel 2.6.35 (2010) fährt.
Der Rest der Software ist daran angepasst und so frisch es damals ging. (glibc 2.16 von 2012 und openssl 1.0.0 von 2014).
Dieses Gerät muss mit einem aktuell gehalten Server über https kommunizieren.
Auf dem Server habe ich gerade ein paar antike Cypher deaktiviert, weswegen diese Kommunikation nun fehlschlägt.

Mein naheliegender erster Gedanke war curl+openssl zu aktualisieren und aktuelle Verschlüsselung zu benutzen.
Das ist die saubere Lösung und natürlich die lästigste.
Variante zwei wäre, einen der alten Cypher wieder zu reaktivieren. Nun bin ich kein Security-experte, aber es wird schon seinen Grund haben, daß da normalerweise von abgeraten wird.
Variante drei wäre, Klartext zu reden - immerhin ist die Kommunikation komplett lokal und inhaltlich unkritisch. Dennoch fühlt sich das falsch an, bei einem update zu downgraden.

Also versuchen wir die erste Variante und aktualisieren zuerst OpenSSL. Klar, über die Paketverwaltung.

wget ...
pacman -U ...

und schon geht alles kaputt.
ssh, wget, curl, wpa_supplicant, pacman,... alles. OK, das kam nicht soo überraschend, aber wie bekomme ich denn jetzt die alte lib wieder zurück aufs Gerät um handlungsfähig zu bleiben?

Ah, ich weiß! Klartext reden! Einfach per netcat, ist ja für den Moment egal. Und ich mag netcat.

Also auf 'nem anderen PC das backup-image von vorher einhängen (Jap, hab 'n Backup, bin lernfähig):

tar c * | nc -l -p 42024

und auf dem Gerät:

nc 192.168.42.23 42024 | tar x

Pustekuchen, kein netcat installiert. Mist. Ich war schon kurz davor irgend 'ne Krücke in 10 Zeilen python hinzurotzen, aber zum Glück geht es weit eleganter, denn bash kann das auch selbst:

tar x </dev/tcp/192.168.42.23/42024

Whoa, praktisch¹! Also fix wieder zurück auf den alten Stand und OpenSSL 1.1.1 aus den Quellen kompilieren.
Auf besagtem Device (ein Freescale i.MX233 454MHz mit 64MB RAM) dauert das, aber was solls, es lief immerhin sauber durch.

Gut, openssl ist also in Version 1.0.0 und 1.1.1 vorhanden, das müsste passen, kann ich ja nun curl updaten.
Am besten auch aus den Quellen. Aber irgendwie kommt der beim Kompilieren durcheinander.
Configure sagt mir, daß die korrekte OpenSSL-Version benutzt wird, aber make wirft einen Fehler, der auf die falsche (1.0.0) API hindeutet.

Nach zahllosen, zeitfressenden und ergebnislosen Versuchen habe ich aufgegeben.
Ich bin auch einfach nicht so drin in der C-Welt und muss bei den meisten Flags und Schalten raten. Zum Glück kann curl auch diverse andere SSL-Bibliotheken verwenden, daher ist der nächste Versuch WolfSSL (die Entscheidung fiel relativ wahllos, hauptsache keine weiteren Abhängigkeiten).

Für WolfSSL genügte es, die Quellen zu laden und

./configure
make
make install

Anschließend konnte ich mit den richtigen Parametern (auch das erforderte einige Versuche) sowohl configure als auch make von curl sauber durchführen. Und zwar so:

LDFLAGS="-Wl,-rpath,/lib" LD_LIBRARY_PATH=/usr/local/lib \
./configure --with-wolfssl=/usr/local/lib --without-ssl \
  --disable-ldap     --disable-ldaps    --disable-rtsp     --disable-proxy    \
  --disable-dict     --disable-telnet   --disable-tftp     --disable-pop3     \
  --disable-imap     --disable-smb      --disable-smtp     --disable-gopher   \
  --disable-manual   --disable-pthreads --disable-threaded-resolver

Und siehe! Curl ist im Jahr 2019 angekommen und ich brauche keinen schmutzigen Workaround für meinen https-zugriff auf den Server. Sehr gut.
Warum das jetzt mit genau dieser Kombination ging weiß ich zwar nicht, insbesondere ist mir nicht ganz klar, warum ich threading abschalten musste, aber die ganze Odysee dauert nun schon fünf Tage und ich habe keine Lust mehr, dem auf den Grund zu gehen. Es läuft. Das genügt.

Ich bin gespannt was das wird, wenn mir dann in 2-3 Jahren SSH um die Ohren fliegt...

1: Wobei Fefe auch nicht ganz unrecht hat: Warum muss eine Shell tcp können? Das bringt nur unnötige Komplexität und Angriffsfläche rein. Ich finde es trotzdem praktisch.