TRestClient mit SSL-P12-Zertifikat, wie funktioniert das?

[jaenicke]

Zitat von gmc616:

Also der SSL-Verbindungsaufbau zum Server steht (ohne P12 hat noch nicht mal das funktioniert), nur der Server (eine Ebene weiter) lässt mich nicht zugreifen?

Danach sieht es aus, ja.

Zitat von gmc616:

Code:

Failed to fetch.
Possible Reasons:
* CORS
* Network Failure
* URL scheme must be "http" or "https" for CORS request.

Was auch immer das bedeutet.

Die Same-Origin-Policy soll verhindern, dass Skripte Daten von fremden Servern nachladen. Mit CORS kann man im Header angeben, dass Inhalte bestimmter Server erlaubt sind.

Was genau dabei dort das Problem ist, lässt sich aus der Fehlermeldung aber nicht ersehen. Dafür müsste man schauen, welche Requests dort abgesendet werden usw.

Zitat von gmc616:

Ich kann dir also nicht folgen, so gern ich das auch möchte.

Das ist gar nicht so schwer. Man muss lediglich wissen, dass die virtuellen Methoden einer Klasse in einer Tabelle im Speicher liegen, die direkt hinter dem Pointer auf die Klasse selbst liegt.
Castet man also die Klasse auf Pointer und schaut an der Stelle in den Speicher (in der CPU-Ansicht), kann man dahinter nach der Adresse der Methode suchen, die man ersetzen möchte. Die Differenz zwischen dieser Speicherstelle und der der Klasse muss man dann zum Pointer auf die Klasse addieren.

An die Stelle kann man dann die Adresse der neuen Methode schreiben und schon wird diese statt der ursprünglichen Methode ausgeführt.

Erschwerend kommt hier hinzu, dass die Klasse TWinHTTPClient unterhalb von implementation steht, so dass ich an die Klasse gar nicht heran kam. Deshalb musste ich die Klassenadresse über die an das BeforePost übergebene Clientinstanz ermitteln (Client.ClassType). So konnte ich dann TWinHTTPClient.DoGetClientCertificates überschreiben.

DoGetClientCertificates wiederum bekommt den Request übergeben und so konnte ich im Speicher nach dem Handle der Verbindung suchen und fand es 164 Byte hinter dem Pointer auf das Objekt. Auf diesem Wert konnte ich dann mit WinHttpSetOption(<Handle>, WINHTTP_OPTION_CLIENT_CERT_CONTEXT, ...) den Zertifikatskontext als Clientzertifikat setzen.

Den Kontext wiederum konnte ich erhalten, indem ich im Speicher mit PFXImportCertStore einen temporären Zertifikats-Store erstellt habe und darin mit CertFindCertificateInStore den passenden Kontext ermittelt habe.

Das führt an der Stelle vielleicht zu weit, aber vielleicht interessiert es ja jemanden, wie man das bis Delphi 10.4 umgehen kann. Ab Delphi 11 gibt es einfach Properties, so dass man den Dateinamen oder einen Stream mit den Zertifikatsdaten angeben kann.

[gmc616]

Das hört sich alles interessant an. Und ist sicherlich ein Thema, wenn es darum geht, Methoden auszuführen oder zu überschreiben, die vom Entwickler einer Klasse so nicht vorgesehen waren. So wie hier mit der TRestClient-Klasse. Ich habe dich doch richtig verstanden?
Rein interessehalber, funktioniert diese Methodik, dieses "Hooking", generell mit jeder Klasse, egal aus welchem Compilier sie stammt, Borland , M$, C++ / C# / usw., oder nur mit Delphi-Binarys?
Ansonsten grenzt das Ganze i.m.A ja fast schon an Hacking von fremden Bibliotheken.
Wenn wir hier nicht aufpassen, kriegen wir evtl. ein "bösen" Kommentar von Daniel ...
Dennoch wäre ich an einem Beispiel-Code interessiert ...

Aber zurück zum eigentlichen Thema:
Ich hab jetzt den Betreiber angeschrieben, nach dem ich hier die Info mitgenommen habe, das offenbar "nur" noch der REST-Server meine Anfrage verweigert.
Mal kucken was rauskommt.

[jaenicke]

Zitat von gmc616:

Und ist sicherlich ein Thema, wenn es darum geht, Methoden auszuführen oder zu überschreiben, die vom Entwickler einer Klasse so nicht vorgesehen waren. So wie hier mit der TRestClient-Klasse. Ich habe dich doch richtig verstanden?

Ja, richtig. Leider hat Embarcadero schon eine Kunstform daraus gemacht, erweiterte Funktionalitäten so zu verstecken, dass man sie von außen nicht nutzen kann. Dann bleibt leider nur, den Code selbst ein zweites Mal zu schreiben, die Unit herauszukopieren und zu ändern oder in die Funktionalität einzugreifen wie hier.

Leider stößt man darauf immer wieder, dass Funktionalität in RTL, VCL usw. eigentlich schon vorhanden ist, aber leider nicht so genutzt werden kann, wie man es braucht. Das ist wirklich schade, vor allem, weil solche Einschränkungen an einigen Stellen wirklich keinerlei Sinn machen.

Und auch mit Delphi 11 kommt man im konkreten Fall an den Request selbst nicht so einfach heran, kann also andere ggf. nicht unterstützte Optionen weiter nicht ohne solche Tricks über die Windows API setzen.

Zitat von gmc616:

Rein interessehalber, funktioniert diese Methodik, dieses "Hooking", generell mit jeder Klasse, egal aus welchem Compilier sie stammt, Borland , M$, C++ / C# / usw., oder nur mit Delphi-Binarys?

Das Prinzip funktioniert mit objektorientierten Sprachen, die ein late binding unterstützen (sprich, wo die konkret aufzurufende Methode aufgrund der Vererbung mit überschreiben usw. zur Laufzeit ermittelt werden muss), recht universell. Ja, z.B. in C++, Java und C# funktioniert das.

Es gibt dafür auch Bibliotheken, so dass man die Umleitung nicht mehr manuell im Speicher machen muss, z.B. DDetours, die Delphi Detours Library. Da ich ohnehin im Speicher herumfummeln musste, um hinterher an das Handle der Verbindung zu kommen, habe ich es aber manuell gemacht.

[gmc616]

Kurzer Zwischenstand:
Das P12-Zertifikat-Laden funktioniert soweit.
Es ist tatsächlich so, dass ich vom Betreiber noch nicht freigeschaltet war.
Muß jetzt "nur" noch (schon wieder) ne Reihe an "Zetteln" ausfüllen, dann sollte das seinen Gang gehen.

Thema gelöst.