Open SSL statisch linken?

[Hedge]

Hallo,

Zur Nutzung von SSL in Indy werden ja die libeay32.dll und die ssleay32.dll benötigt.

Ist es möglich diese in Delphi statisch zu linken damit sie direkt in der .exe-Datei drinstecken?

[sx2008]

Kann ich mir nicht vorstellen, dass das funktionieren kann.
Open SSL dürfte in C/C++ programmiert sein.
Du kannst nicht einfach Objektdateien einer fremden Programmiersprache in deine Delphi Anwendung linken.

[generic]

Zitat:

Zitat von sx2008

Du kannst nicht einfach Objektdateien einer fremden Programmiersprache in deine Delphi Anwendung linken.

Doch kannst du, ein Beispiel ist die ZLib.
Diese befindet sich u.a. auf deiner Delphi Comp. CD.

[Assertor]

Hallo,

Zitat:

Zitat von generic

Zitat:

Zitat von sx2008

Du kannst nicht einfach Objektdateien einer fremden Programmiersprache in deine Delphi Anwendung linken.

Doch kannst du, ein Beispiel ist die ZLib.

Natürlich kann man das, generic hat absolut recht. Abeeeer: Damit stehst Du alleine da, hedge. Von Indy Seite wird es nichts geben, da wir nicht nur Delphi & Windows unterstützen und ein statisches Linken einen ungleich höheren Aufwand darstellt und unter Betriebssystemen die OpenSSL nativ mitbringen keinen Sinn macht.

Ich verweise mal für Anfänger auf die Tutorials von Rudy zum Thema Linken von Object C/C++:
http://rvelthuis.de/articles/articles-cppobjs.html
http://rvelthuis.de/articles/articles-cobjs.html

Prinzipiell mußt Du aus dem C/C++ Source Objekt-Dateien erzeugen, die der Delphi Linker mag (geht nicht mit jedem C Compiler). Außerdem müßten die OpenSSL Header von Indy angepasst werden und unter Umständen auch ein paar Basis-Geschichten gelinkt werden auf die die C Objects angewiesen sind (String Funktionen etc).

Es ist also nicht ganz so einfach.

Aber folgendes sei mal gesagt - wenn der Hintergrund ist, daß externe Dateien unsicher sind - Windows Crypto und TCP Libraries sind auch extern. Man geht also immer von einem unkompromitierten System aus. Wenn jemand physischen Zugriff zu Deinem Programm hat (mit höchsten Rechten) dann ist ein Angriff auf die DLLs ebenso möglich wie ein Auslesen des Speichers (Deine unverschlüsselete Daten) oder Debugging. OpenSSL sehe ich hier also nicht als schwächstes Glied in der Kette.

Gruß Assertor

[Hedge]

Hört sich ja nicht so prickelnd an.

Den Speicher würde ich ein bisschen sichern indem ich die Daten verschlüssele und mit ner Prüfsumme schaue ob auch alles mit den rechten Dingen zugeht.
Doll ist das natürlich auch nicht, aber zumindest kann nicht jeder Horst dran rumfuddeln.

Das Manko der DLLs bei der Nutzung von Open SSL ist, dass Jemand einfach abfängt was in SSL-Write ankommt und das manipuliert.
Das ist ein bisschen schwerer wenn die dll's statisch gelinkt werden.

Auf dem Server gibt es dann heuristische Analysen die wohl wesentlich bringen.

[Assertor]

Hi,

Zitat:

Zitat von Hedge

Den Speicher würde ich ein bisschen sichern indem ich die Daten verschlüssele und mit ner Prüfsumme schaue ob auch alles mit den rechten Dingen zugeht.
Doll ist das natürlich auch nicht, aber zumindest kann nicht jeder Horst dran rumfuddeln.

Das Manko der DLLs bei der Nutzung von Open SSL ist, dass Jemand einfach abfängt was in SSL-Write ankommt und das manipuliert.
Das ist ein bisschen schwerer wenn die dll's statisch gelinkt werden.

Auf dem Server gibt es dann heuristische Analysen die wohl wesentlich bringen.

Also, für jemanden der in der Lage ist die OpenSSL DLLs richtig gut zu manipulieren, stellen die o.g. Schutzmaßnamen auch kein Problem dar. Wenn jemand (Du?) eine statisch gelinkte Version erzeugt, gerne her damit. Ich wollte nur sagen: Ich werde das nicht machen, da fehlt mir die Zeit und der Nerv.

Gruß Assertor