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

[gmc616]

Hallo DP.

Ich möchte einen REST-Client schreiben, der eine SSL-Verbindung zu einem REST-Server aufbauen soll.
Für die SSL-Verbindung wird mir pro Benutzer ein P12-Zertifikat(??) und ein Passwort bereit gestellt.

Ich habe im Umgang mit Zertifikaten keinerlei Erfahrung.
Das Zertifikat soll zur Laufzeit geladen werden, nicht aus dem Windows-Zertifikatsspeicher.

Funktioniert sowas mit Delphi-Rio-Boardmitteln? Oder brauche ich Fremd-Komponenten?
Wie muß ich vorgehen?

Evtl. hat jemand ein Beispiel für mich?

Danke.

[jaenicke]

Zitat:

Zitat von gmc616 (Beitrag 1515481)

Das Zertifikat soll zur Laufzeit geladen werden, nicht aus dem Windows-Zertifikatsspeicher.

Funktioniert sowas mit Delphi-Rio-Boardmitteln?

Leider gab es da einen Bug, der erst mit Delphi 11 behoben ist. Hier findest du meinen entsprechenden (gelösten) Bugreport:
https://quality.embarcadero.com/brow...4451?filter=-2
Der Bug bezieht sich zwar auf THTTPRIO, aber das gilt genauso für TRestClient.

Bei Delphi 10.3 kannst du, um Zertifikate zur Clientauthentifikation aus dem Speicher oder Dateien zu nutzen, nur andere Komponenten verwenden oder mit Hooks und Pointerspielerei auf die intern dafür vorhandene Funktionalität zugreifen (die vor Delphi 11 zwar vorhanden aber nicht nutzbar war). Ich habe das mit Hook usw. gelöst.

[himitsu]

Wir hatten es letztendlich manuell gemacht. (wir haben auch nur eine Hand vol API/Methoden, welche wir ansprechen)
Indy/TIdHTTP mit der kranken JSON-Komponente vom Delphi, zum Ansprechen des REST-Servers,
und OpenSSL für die Behandlung des Zertifikats beim Login-Prozess. (das aktuelle Zettifikat wird runtergeladen und zur Berechnung des Key benutzt, für die weitere Kommunikation)
https://code.google.com/archive/p/openssl-delphi/

Für XE + 10.4 (bzw. nun auch noch so im 11.2)



Jupp, war nicht zugreifbar und Kollege hatte dann eine andere Komponente gesucht, wo es ohne Krämpfe ging.
Außerdem XE und TRestClient :roll:

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1515484)

Jupp, war nicht zugreifbar und Kollege hatte dann eine andere Komponente gesucht, wo es ohne Krämpfe ging.

Einen entsprechenden Bugeintrag hatte ich allerdings nicht gefunden. Und meiner wurde ja nach etwa einem Jahr dann gelöst, was ich für einen solchen Bug (vorgesehene spezielle Funktionalität funktionierte noch nie) auch für völlig akzeptabel halte. Nur muss es halt auch jemand melden.

[himitsu]

Da wir das Problem vorrangig in XE lösen mußten und Emba da sowieso nix mehr macht, hatten wir keine Lust dazu sinlos was zu melden.
(bin grade dabei D11 endlich mal zum laufen zu bekommen, damit wir endlich produktiv umstellen können, aber da knallt noch genug Anderes)

[gmc616]

Hmm ... Sorry, aber jetzt bin ich genau so schlau wie vorher.
Die Aussage "Leider gab es da einen Bug, der erst mit Delphi 11 behoben ist." hat nicht unbedingt eine motivationsfördende Wirkung. :zwinker:

Nun gut. Natürlich hab ich ne Reihe rumgegoogelt.
Unter anderem hab ich Dinge gefunden über TIdHTTP, dort kann man mittels IdSSLIOHandlerSocketOpenSSL-Handler ein Zertifikat laden.
Nach einem Blick in den Source ist es offenbar auch möglich, P12 bzw. PFX Zertifikate zu laden.
Das hab ich getan und nach der Angebe des korrekten Passworts in IdSSLIOHandlerSocketOpenSSL1GetPassword, gab es auch keine Fehler mehr.

Es sieht ganz danach aus, als ob man so eine SSL-Verbindung mit dem P12-Zertifikt aufbauen kann.
Wenn ich allerdings einen REST-Endpoint abrufen möchte, bekomme ich einen HTTP-Error 403 zurück.
Okay. Eine 403 ist keine 401.

Aber heißt das nun das die Verbindung tatsächlich funktioniert, oder das nicht?

[DeddyH]

Eine 403 (Forbidden) bedeutet normalerweise, dass Du versuchst, auf eine Ressource zuzugreifen, auf die Dir die Berechtigung fehlt. Das kann sein, wenn Du entweder nicht angemeldet bist (wobei ich da eher eine 401 erwarten würde), oder Deine Anmeldung das entsprechende Recht zum Zugriff nicht beinhaltet. Andererseits kann der Server Dir ja zurückschicken, was er für richtig hält, hier sollte ein Blick in die Dokumentation oder eine Rückfrage beim Betreiber Klarheit schaffen.

[jaenicke]

Zitat:

Zitat von gmc616 (Beitrag 1515725)

Hmm ... Sorry, aber jetzt bin ich genau so schlau wie vorher.
Die Aussage "Leider gab es da einen Bug, der erst mit Delphi 11 behoben ist." hat nicht unbedingt eine motivationsfördende Wirkung. :zwinker:

Ich habe ja geschrieben, dass ich es trotzdem damit umgesetzt habe. Dafür muss man sich allerdings über den Speicher des Objekts, das man in einer gehookten Methode übergeben bekommt, weiterhangeln, um an die Interna der Windows-spezifischen REST-Umsetzung zu kommen. Darüber bekommt man dann das Handle der Verbindung aus der WinHTTP-API und kann darüber das Zertifikat selbst setzen.

Zitat:

Zitat von gmc616 (Beitrag 1515725)

Wenn ich allerdings einen REST-Endpoint abrufen möchte, bekomme ich einen HTTP-Error 403 zurück.
Okay. Eine 403 ist keine 401.

Aber heißt das nun das die Verbindung tatsächlich funktioniert, oder das nicht?

Das kann z.B. heißen, dass das Zertifikat die Verbindung absichert, du dich aber zusätzlich als Benutzer einloggen musst, weil sich über das Zertifikat mehrere Benutzer verbinden können.

[mjustin]

Zitat:

Zitat von gmc616 (Beitrag 1515725)

Aber heißt das nun das die Verbindung tatsächlich funktioniert, oder das nicht?

Ja, denn einen HTTP Statuscode erhält der Client nur wenn eine Verbindung aufgebaut werden konnte und auf der Gegenseite ein HTTP Server läuft.
Wenn die TLS/SSL Verbindung nicht hergestellt werden kann, erhält man Fehler der TLS/SSL Bibliothek.

403 kann man interpretieren als: "ich (der Server) kann Dich anhand des Zertifkats und des Passwort zwar als Benutzer erkennen, aber Dir wurde nicht der Zugriff auf die Resource gegeben":

Zitat:

Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”

https://stackoverflow.com/a/6937030/80901

Anscheinend wird das auch im RFC so beschrieben:

"Forbidden means that the client has authenticated successfully, but is not authorized."

(Kommentar unter der verlinkten Stackoverflow-Antwort)

[gmc616]

@jaenicke
Ich merke schon, du steckst wesentlich Tiefer in der Materie als ich. Begriffe wie z.B. "Hooks" sind mir zwar schon ein paar mal über den Weg gelaufen, habe sie aber links liegen lassen, weil ich nie wirklich eine Verwendung dafür finden konnte.
Ich bin Anwendungsentwickler, eher in Richtung Massendatenverarbeitung, Datenbanken und Co., Datenaustausch (jetzt immer mehr per REST) und einiges mehr.
Hooks (ich verbinde damit im Kopf Tastatur-Hooks) sind eher System-nahe Dinge, mit denen ich eigentlich nie etwas zu tun habe/hatte. Ich kann dir also nicht folgen, so gern ich das auch möchte.
Leider ist es auch so, dass dein Link (oben) nicht funktioniert. Er funktioniert nur, wenn ich den Parameter "filter" weglasse, dann komme ich aber lediglich in den Jira-BugTracker von Emba. Ist aber keine Lösung zu finden. :cry:

Deswegen bis ich aktuell etwas irritiert. Und deswegen auch die blöden Fragen.

@DeddyH
Der Hersteller hat auf dem Server eine SwaggerHub-Doku laufen. Diese Doku kann man nur aufrufen, wenn man im Windows-Zertifikatspeicher das P12-Zertifikat importiert hat. Rufe ich dort den gleichen Endpoint auf, bekomme ich einen "Code" "Undocumented" zurück, mit dieser "Erklärung":

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 403 bekomme ich nur in meinem Code zurück.

@mjustin
Siehst du das genau so wie ich?
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?
Wenn das so wäre, wäre ich einen kleinen Schritt weiter.

Ich wollte mich halt nicht als "komplett bescheuert" an den Support wenden, wenn ihr versteht...
Wie gesagt, mit Zertifikaten hatte ich bis eher nicht viel zu tun.

Danke für eure Unterstützung. :dp:

[jaenicke]

Zitat:

Zitat von gmc616 (Beitrag 1515733)

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:

Zitat von gmc616 (Beitrag 1515733)

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:

Zitat von gmc616 (Beitrag 1515733)

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 ... :oops:
Dennoch wäre ich an einem Beispiel-Code interessiert ... :zwinker:

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:

Zitat von gmc616 (Beitrag 1515751)

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:

Zitat von gmc616 (Beitrag 1515751)

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.