denn die setzt unter Windows auf WinInet und da ist man bei SSL/TLS-Verbindungen auf Gedeih und Verderb deren Zertifikatspeicher ausgeliefert - und den hat Microsoft schon mehrfach per Windowsupdate sabotiert.
Das stimmt nicht. Ich verwende die delphieigenen Klassen für Rest und Http und nutze Zertifikate aus Dateien. In Delphi 11.2 funktioniert das nun auch direkt ohne Tricks.
Da neuere Verschlüsselungen oder Kurven nicht unbedingt von allen Frameworks unterstützt werden, ist es gut, wenn man das Framework bei Bedarf relativ einfach wechseln kann.
Das meinte ich nicht. SSL und TLS sind so aufgebaut, dass es (mehr oder weniger) vertrauenswürdige Zertifizierungsstellen gibt,z.B. Letsencrypt oder Symantec. Ein Server im Web liefert seine öffentlichen Schlüssel und der Client prüft dann entlang der Keychain zur Zertifizierungsstelle. Das ist aus gutem Grund so gewollt, wie man an den verschiedenen Skandalen rund um die Zertifizierungsstellen in der Vergangenheit gesehen hat. Dieser Tage wollten Mozilla und Google z.B.
die Trustcor-Rootzertifikate sperren.
Die Browser bringen diese Prüfinfrastruktur selbst mit, Microsoft liefert aber mit WinInet auch eine
API zu einer solchen Infrastruktur. Die meinte ich, die hat Windows Update schon mehrfach kaputt gepatched. Aus Anwendungssicht ist der Effekt dann der selbe: Du bekommst keine verschlüsselte Verbindung aufgebaut. Also neben der gewollten Sollbruchstelle noch eine ungewollte.