Indy SSL DLLs woher nehmen wenn nicht stehlen?

[Codehunter]

Ahoi!

Beide Downloadseiten die auf der Indy-Homepage angegeben werden, sind offline. Auch der bei Emba genannte Downloadlink (32-Bit- und 64-Bit-Windows > Option 2) geht nicht mehr.

Wie war denn das, die originalen OpenSSL-DLLs funktionierten doch nicht mit Indy, weshalb es gepatchte Versionen gab. Oder hat sich daran was geändert?

Grüße
Cody

[KodeZwerg]

OpenSSL for Win64, download funktioniert, reicht Dir das aus? (FreePascal Edition, ist die auch mit Delphi kompatibel?)

[mjustin]

Zitat von KodeZwerg:

OpenSSL for Win64, download funktioniert, reicht Dir das aus? (FreePascal Edition, ist die auch mit Delphi kompatibel?)

Der Link (http://www.indyproject.org/Sockets/f...SSL-0_9_8g.zip) führt zu einer alten Version der OpenSSL DLLs, die mit aktuellen Indy-Versionen nicht kompatibel ist.

Es wäre interessant zu erfahren, was aus der semi-offiziellen Downloadseite (http://indy.fulgan.com/SSL/) geworden ist, auf der regelmäßig die aktualisierten OpenSSL DLL Versionen veröffentlicht wurden. Ob diese nur temporär offline ist, oder für längere Zeit.

[Codehunter]

Zitat von mjustin:

Es wäre interessant zu erfahren, was aus der semi-offiziellen Downloadseite (http://indy.fulgan.com/SSL/) geworden ist, auf der regelmäßig die aktualisierten OpenSSL DLL Versionen veröffentlicht wurden. Ob diese nur temporär offline ist, oder für längere Zeit.

Noch interessanter: A) Wenn offline und B) Indy nicht mit den Standard-OpenSSL-DLLs kompatibel, ist Indy dann eigentlich nicht komplett wertlos bzgl. verschlüsselter Kommunikation? Denn wenn keine Security-Patches mehr geliefert werden (Stichwort Heartbleed und so) wäre man gezwungen, seine Programme mit "irgendwelchen" SSL-Libs auszuliefern. Wenn demnächst TLS 1.3 spezifiziert ist, kann Indy damit mal gar nicht umgehen. Oder sehe ich das jetzt falsch?

[Schokohase]

Nein, das siehst du richtig.

Und du hast gerade erkannt, das billig (hier kostenlos) ganz schön teuer werden kann.

[mjustin]

Zitat von Codehunter:

A) Wenn offline und B) Indy nicht mit den Standard-OpenSSL-DLLs kompatibel, ist Indy dann eigentlich nicht komplett wertlos bzgl. verschlüsselter Kommunikation?

Anwendungen, die einen embedded HTTPS Server verwenden, sind davon betroffen. Bei Anwendungen, die sich über einen Reverse Proxy mit dem Internet verbinden lassen, verwendet man auf der Indy Seite kein HTTPS, daher läuft das weiter wie bisher (auch mit TLS 1.3).

p.s. Indy 10 ist mit den Standard-DLLs kompatibel. Die im Beitrag weiter oben angegebene Seite zeigt auf einen Download einer alten Version (0.x), Standard-OpenSSL DLLs waren nicht mit Indy 9 kompatibel. Das Problem ist also nicht akut, solange noch jemand den aktuellen Sourcecode der DLLs und einen Compiler besitzt, und Indy 10 verwendet

Zitat:

... Remy Lebeau (TeamB) replied on 25-Apr-2011:

wrote in message news:✉forums.embarcadero.com...
(snip)

These are major differences between how Indy 9 and 10 handle SSL.
Indy 9 uses custom OpenSSL DLLs that have Indy-specific functions exported
from them. Indy 10 uses the standard official DLLs instead.

https://www.codenewsfast.com/cnf/thr...hr-ng1921q6077

[MichaelT]

Bei den Fulgan DLLs geht es um die Dependencies auf die Microsoft Runtime DLLs so ich mich recht erinnere.

Wenn du Apache unzippst, dann kommt der genauso wenig auf die Füße. Deswegen nimmt man den Installer. Dazu gleich später.

---

Eine Anwendung ist ein eigenes Betriebssystem. Du kannst ruhig eine eigene Version Implementieren.

Das mit den Abhängigkeiten hat damit zu tun, dass Delphi Anwendungen oft im UNIX Style verteilt werden.

Der Installer kommt von geschlossenen Systemen. Die ursprünglichen geschlossenen Systeme kannten keine Workstation. Der Operator hat ein Band eingelegt das sich selbst installiert hat mehr oder weniger. Bei IBM Rechner hattest du je nach Ergebnis eine Zahl auf einem Display am Server (Return Code wenn man so will). Es gab nur einen Rechner.

---

Eine Oracle wir ja nicht am Server installiert. Die wird auf einer Workstation installiert und dann vom Systemadministrator kopiert. Der Sysadmin weiß was installiert ist. (Dependency Management)

Ein Teil der Installation das Linken der statischen Libraries oder der Stubs ... Die Schnittstelle nach außen ist gleich und die Implementierung im Kontext des OS eine andere.

Denke an die Java Application Server. Jeder hat ein JBOSS installiert und dann wird wild herumkopiert.

---

UNIX ist ein Peer to Peer Konzept. Die hatten Workstations.

UNIX Style Deployment heißt, dass du lokal übersetzt und Sysadmin kopiert 'manuell'.

Jetzt ist man immer wieder gefangen in der Welt zwischen Infrastruktur das vom OS bereitgestellt wird und dem Linken der Security relevanten Teile in die Applikation.

Windows ist der Versuch von DEC auf dem sich verbreitenden Anachronismus dem PC Server ein geschlossenes System anzubieten (Windows NT). Was heute in die Cloud wandert entspringt der Logik der geschlossenen Systeme, spätestens beim Thema Security.

Der Nachbau des IBM Mainframe mit Terminals sit die Web Applikation. Jetzt hast du auf einmal so die Idee, dass der Apache mit Scripting die Security des OS bemüht. Der Weg das nachzubilden ist die Shared Library (oder auch DLL unter Windows).

In der UNIX Philosophie der frühen Tage ist der Server und Client dasselbe Programm. Wenn du die Library statisch linkst. Das entspräche in der Delphi Welt bspw. dem Linken von ELDOS SSL oder eine anderen Delphi SSL Implementierung.

---

SSL sichert an sich ja nur den Client vor einem 'bösen' Server und in weiter Folge die Kommunikation. SSL sowie das im Moment im C/S Stil verwendet greift grad mal so weit wie die Anforderungen an einen Webshop. Two-sided SSL käme dem näher was der Benutzer so glaubt ...

---

Eine nettes für eine echte Multi Tier Implementierung von Anwendungssecurity wird bei SecurBrige mitgliegert (SSH).


---

An sich wird aus der Idee des geschlossenen Systems heraus bspw. ein Zertifikat oder die Anmeldung von der Infrastruktur verwaltet. Sonst musst du die dir selbst bauen.

---

Ansonsten nehme ich einfach irgendwelche SSL dlls. Fulgan ist nicht Pflicht unter Indy 10. Warum Fulgan im Moment down ist weiß ich nicht.

---

Am Netz sudern viel Leute die ein wenig Hudri Wudri unterwegs sind. Das ist typisch Windows Welt. Windows ist Peer To Peer einersteits und geschlossen auf der anderen.

Auch sehr typisch für die Windows Welt ist, dass es extrem viel Funktionalität in den APIs gibt sich Security in seinem eigenen OS nämlich der Anwendung anzupassen. Da beginnt der Konflikt. Wenn man das unter Windows durchzieht müsste man fast auf die Funktionen bpsw. in JEDI Windows Security Code Library zurückgreifen.

Mit SSL aktiv und der Tag ist gerettet machst du keine Meter. Ansonsten kann man nur wie .net oder auch Mono eine Certificate Storage machen usw...

Du hast im Indy aber die Interceptoren. Auf dem Weg kannst du in eine bestehende Infrastruktur durchaus auch nicht praxisfern dich integrieren.

---

Sobald die Server in der Cloud wo dann der Anachronismus PC Server verschwindet, dann ist man eher wieder sauberer in der geschlossen Welt. Ob das erstrebenswert ist sei dahingestellt.

[TiGü]

[DieDolly]

Bei so langen Antworten habe ich immer den Eindruck, dass da ein Bot antwortet.

[Codehunter]

Manchmal ...