Zertifikat nutzen

[Codehunter]

Oh weh. Grundsätzlich müssen Zertifikat, IP-Adresse und Hostname zusammen passen. Am Ende wird das auf beiden Seiten irgendwie zusammengeschustert. Hauptsache es läuft. Könnte mir vorstellen, so ähnlich ist es zwischen BRAK und ATOS auch gelaufen beim beA. Sicherheit kommt dabei aber mit Sicherheit nicht heraus. Tu dir selbst einen Gefallen und lehn den Auftrag ab.

OT: Weisst warum ich die REST-Komponenten nicht mag und wieder auf Indy zurück gewechselt bin? Weil man bei Indy per TLS-Intercept die Schlüssel abgreifen und dann per Wireshark den Protokollfluss analysieren kann. Dann sieht man nämlich auch Fehler bei der Aushandlung der Verschlüsselung, ob schon TLS 1.2 verwendet wird oder noch 1.1 oder 1.0. Von SSL mal gar nicht zu reden.

[Zwirbel]

Zitat von Codehunter:

Oh weh. Grundsätzlich müssen Zertifikat, IP-Adresse und Hostname zusammen passen. Am Ende wird das auf beiden Seiten irgendwie zusammengeschustert. Hauptsache es läuft. Könnte mir vorstellen, so ähnlich ist es zwischen BRAK und ATOS auch gelaufen beim beA. Sicherheit kommt dabei aber mit Sicherheit nicht heraus. Tu dir selbst einen Gefallen und lehn den Auftrag ab.

Das ist leider keine Option. Unsere Software läuft schon seit 3,5 Jahren beim Kunden. Unser Kunde bekommt nun vom IT-Dienstleister - der dem Kunden die Hardware und das Netzwerk zur Verfügung stellt - die Aufforderung zukünftig die Daten die der Kunde vom IT-Dienstleister bezieht, mit Zertifikat abzufragen.

So wie es aussieht kriege ich das mit dem Zertifikat und den REST-Komponenten nicht gebacken und muss wohl in den sauren Apfel beissen nur deswegen auf Indy umstellen.

[Codehunter]

Die REST-Komponenten basieren (bei Win32 und Win64) auf WinInet und "erben" sozusagen diverse Sicherheitseinstellungen aus der Abteilung Internet Explorer. Dort wäre auch der Ansatz, das Zertifikat zumindest testweise einzuspielen. Bevor jetzt alles auf Indy umgestrickt wird.

Ich wollte mit meinen Bedenken nur zum Ausdruck bringen, dass SSL/TLS ja eigentlich erfunden wurde um die Transportsicherheit zu erhöhen. So wie du das beschreibst, bestehen auf beiden Seiten viele Ungewissheiten über die Problematik. Daher befürchte ich, wird das Vorhaben nicht den gewünschten Erfolg bringen. Egal ob nun mit WinInet oder Indy. Möglich, dass es "irgendwann" "irgendwie" läuft. Nur ob das dann auch das Prädikat "gesicherte Verbindung" verdient, steht in den Sternen.

[Zwirbel]

Zitat von Codehunter:

Die REST-Komponenten basieren (bei Win32 und Win64) auf WinInet und "erben" sozusagen diverse Sicherheitseinstellungen aus der Abteilung Internet Explorer. Dort wäre auch der Ansatz, das Zertifikat zumindest testweise einzuspielen. Bevor jetzt alles auf Indy umgestrickt wird.

Das hatte ich evtl. nicht klar genug geschrieben. Das Zertifikat habe ich in meiner Testumgebung installiert. Einfach Doppelklick auf der .CER Datei und dann immer <Weiter>, zum Schluss kam auch eine Meldung, dass die Installation erfolgreich abgeschlossen wurde. Aber ich habe ja gar keine Ahnung, weil mir die IT-Abteilung die mir das Zertifikat geschickt hat, nicht sagen kann, wie ich das Zertifikat zu installieren habe, ob ich es auch am richtigen Platz abgelegt habe. Man kratzt sich jetzt evtl. etwas am Kopf und fragt sich, wieso können die die einem so ein Zertifikat schicken auch nicht sagen was man damit zu machen hat. Aber so ist es leider. Mir sagt man lediglich, dass sie mit der Verwendung der Zertifikate unter Windows kaum/keine Erfahrungen haben, sie arbeiten nur unter Linux.

Zitat von Codehunter:

Ich wollte mit meinen Bedenken nur zum Ausdruck bringen, dass SSL/TLS ja eigentlich erfunden wurde um die Transportsicherheit zu erhöhen. So wie du das beschreibst, bestehen auf beiden Seiten viele Ungewissheiten über die Problematik. Daher befürchte ich, wird das Vorhaben nicht den gewünschten Erfolg bringen. Egal ob nun mit WinInet oder Indy. Möglich, dass es "irgendwann" "irgendwie" läuft. Nur ob das dann auch das Prädikat "gesicherte Verbindung" verdient, steht in den Sternen.

Das sehe ich auch so. Die Sicherheit erhöht das Zertifikat um kein Jota. Denn die URL ist aus dem öffentlichen Internet eh nicht erreichbar. Und die Daten die man von der Schnittstelle geliefert bekommt sind trotzdem alles andere als streng geheim, im Gegenteil, das sind Infos, die man auf anderem Weg, jederzeit als Privatmann abrufen kann. Ich möchte hier keine Namen und Institutionen nennen.

Es ist zum Haareraufen.

[Codehunter]

Zitat von Zwirbel:

Mir sagt man lediglich, dass sie mit der Verwendung der Zertifikate unter Windows kaum/keine Erfahrungen haben, sie arbeiten nur unter Linux.

Geil. Der Traum einer ganzen Generation von Nerds Aber das gibts in den letzten Jahren immer öfter. Windows ist nicht mehr das Allheilmittel.

Zitat von Zwirbel:

Denn die URL ist aus dem öffentlichen Internet eh nicht erreichbar.

Naja, die Grenze zwischen öffentlichen und privaten Netzen sind weicher als man gemeinhin denkt. Ich kenne Unternehmen, die hohe Beträge in Sicherheit investiert und die Mitarbeiter das noch am Start-Tag mit einem einzigen Tethering-fähigen Handy ausgehebelt haben.

Ich würde dir raten, die Insider bei deinem Dienstanbieter zu einem Grillabend einzuladen. Es geht nix über Vitamin B um solche Probleme aus der Welt zu schaffen

[EmWieMichael]

@Zwirbel
Hast Du meinen Code mal getestet?

[Zwirbel]

Zitat von EmWieMichael:

@Zwirbel
Hast Du meinen Code mal getestet?

Asche auf mein Haupt, ich hatte diesen Post von dir nicht mitbekommen. In der Zwischenzeit habe ich Stunden damit verbracht das Windows-Zertifikat, das ich vorher in den Zertifikatsspeicher von Windows installiert hatte, zu verwenden, alles ohne Erfolg. Am Freitag war ich nun auf eine ganz andere Lösung gestoßen. Mit dem Test-Projekt "OverbyteIcsHttpsTst" von den ICS-Komponenten ("ICS - Internet Component Suite - V8 - Delphi 7 to RAD Studio 10.3 Rio"). Da verwende ich die PEM-Datei die man mir auch zur Verfügung gestellt hatte und ich konnte in der Tat Daten abfragen. So weit so gut.

Aber das würde bedeuten, ich müsste meinen bisherigen Code komplett umwerfen, all die schönen und simplen TRest-Komponenten von Delphi in Zusammenhang mit einem RESTResponseDataSetAdapter, das war ja einfach genial, nach der Datenabfrage marschiert man einfach durch ein DataSet durch, kein Gepfriemel das JSON auseinander zu pflücken etc.

In diesem BlogPost:
http://blog.marcocantu.com/blog/2018...ents-1022.html

steht etwas von "New REST Client Events OnNeedClientCert and OnAuthEvent", das liest sich eigentlich genau so, als ob das meine Lösung wäre, einfach in dem OnNeedClientCert das Zertifikat bestimmen und fertig. Leider gibt es mal wieder keine brauchbare Online-Hilfe zu diesem Event.

Hier:
https://quality.embarcadero.com/browse/RSP-15857

steht nur:
"It uses the computer's certificate store. Install the certificate, then when OnNeedClientCert fires, you return the index of the certificate from the provided Certificate you want to use."

Der Witz ist nur dieser Event feuert bei mir nicht.

Der Kommentar eines Nutzers:
"Without this feature, the Rest Debugger is useless when you need certificates. Sample code on the doc also would be fine."

Dem kann ich nur zustimmen. Es ist frustrierend, dass in Delphi so viele Möglichkeiten schlummern, die man aber mangels vorhandener tauglicher Beispiele in die Praxis nicht umsetzen kann. Die Entwickler die diesen Event "OnNeedClientCert" implementiert haben, die müssen das doch auch mal irgendwie getestet haben. Ist es da zu viel verlangt "einfach" ein paar Code-Schnippsel in die Online-Hilfe zu pappen. So suchen sich hunderte und tausende von Entwicklern dusselig bis sie es sich dann selbst aus den Fingern gesogen haben oder die Sache in die Ecke feuern...

Hat jemand hier praktische Erfahrung mit dem Event "TRestClient.OnNeedClientCert"?

Danke im Voraus. Gruß, Markus