Windows mit libcrypto
« | 28 Oct 2023 | »Wenn man vergisst die SSL/TSL
Bibliotheken ins Zielverzeichnis zu kopieren, sollte das Laden eines davon
abhängigen Programms fehlschlagen.
Doch so “zur Hälfte” konnte doch was geladen werden … und das war für mich
ein intessantes Rätsel.
Wie sich herausgestellt hat liefert Microsoft sein Windows seit 2018 offenbar
mit einer libcrypto Variante aus.
Wer SSL/TLS Features benötigt, ist grundsätzlich von Fremdbibliotheken
abhängig. Unter Linux war das schon immer so und Windows … naja dort
eigentlich auch. Die alte (wincrypt) und neue (bcrypt) Implementierung
in der WinAPI ist immer auf dem Stand, als die Windows Version auf den
Markt kam … also immer veraltet.
Zum Glück stehen mit OpenSSL und libreSSL zwei hervorragende Kandidaten parat, die die Lücke problemlos füllen … wenn man sie eingebunden bekommt.
Linkt man die beiden Teilbibliotheken libcrypto und libssl dynamisch,
darf man sich beim Deployment ärgern, wenn sie nicht vorhanden sind oder in
der falschen Version vorliegen.
Link man sie statisch, hat man garantiert das Richtige dabei, bekommt aber
eine 2 MB+ große EXE, die sonst nur 200 KB groß gewesen wäre.
Ich habe daher wie so oft eine duale Strategie für SSL vorgesehen und kann entweder mit der statischen Variante arbeiten, oder lade zur Laufzeit die notwendigen Funktionspointer per Hand nach, womit ich ebenso nicht gegen SSL-Libs linken muss und beim Start einfach die “nächst-greifbare” Variante geladen wird.
Windows 10 and Server 2019 mit libcrypto
Microsoft hat interessanterweise im Jahr 2018 erstmals eine ältere Version
der libcrypto.dll aus dem libreSSL Projekt ins Windows\\System32
Verzeichnis gelegt, jedoch nicht den SSL/TLS Teil.
Im Server 2016 und älteren Windows-10 IOT Versionen von 2016 ist die DLL noch
nicht vorhanden.
Genau das führte bei mir zu einigen Problemchen beim “dynamischen” Nachladen
der Funktionalität. Denn statt wie erwartet nichts zu finden, wenn keine
DLLs von mir ausgeliefert werden, wurde plötzlich libcrypto geladen und
die nachfolgenden libssl schlug fehl.
Auf diesen Halbstand war ich nicht vorbereitet und somit musste ich die
Fehlerbehandlung anpassen.
… doch aus dieser interessanten Erkenntnis leitet sich ein anderer Vorteil
ab.
libssh2 mit Boardmitteln betreiben
libssh2 nutzt für den Aufbau von SSH Sitzungen ausschließlich Funktionen der
libcrypto aber braucht keinen SSL/TLS Support. Bisher musste ich immer eine
vollständige libreSSL oder OpenSSL Schnittstelle bereitstellen, wenn ich SSH
einsetzen wollte … doch mit einem aktuellen Windows kann man diese
Funktionalität auch vom OS Kern beziehen.
Da Import-Bibliotheken für die libcrypto fehlen, habe ich einfach statische
Wrapper um die notwendigen APIs erstellt und nun kann libssh2 gegen meinen
statischen Wrapper linken, der im Hintergrund dann nur die libcrypto lädt
und die Funktionspointer importiert.
So entsteht dann eine schlanke SSH Implementierung, die vom OS mitverwaltet wird und fette Crypto/SSL Kopien entfallen.
Fazit
Windows wird langsam OpenSource-tauglich.
Ich kann wieder mal nicht nachvollziehen, warum diese freie Bibliothek erst so spät in Windows Einzug gehalten hat und verstehe schon gar nicht, warum der SSL/TLS Teil wieder fehlt.
Im allgemeinen Fall ist es weiter sicher besser die ganze Crypto/SSL Implementierung selbst bereitzustellen … aber für neu entwickelte Tools ist das Vorhandensein von OpenSource-Kryptographie zumindest mal ein guter Start.