AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Delphi Indy SSL DLLs woher nehmen wenn nicht stehlen?
Thema durchsuchen
Ansicht
Themen-Optionen

Indy SSL DLLs woher nehmen wenn nicht stehlen?

Ein Thema von Codehunter · begonnen am 13. Jul 2018 · letzter Beitrag vom 21. Jul 2018
Antwort Antwort
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
562 Beiträge
 
Delphi 10.3 Rio
 
#1

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 13. Jul 2018, 16:04
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.

  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.079 Beiträge
 
Delphi 10.4 Sydney
 
#2

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 13. Jul 2018, 23:10
  Mit Zitat antworten Zitat
DieDolly

Registriert seit: 22. Jun 2018
2.175 Beiträge
 
#3

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 13. Jul 2018, 23:53
Bei so langen Antworten habe ich immer den Eindruck, dass da ein Bot antwortet.
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.291 Beiträge
 
Delphi 12 Athens
 
#4

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 14. Jul 2018, 04:49
Manchmal ...
Angehängte Grafiken
Dateityp: gif Verwirrung.gif (9,6 KB, 36x aufgerufen)
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
562 Beiträge
 
Delphi 10.3 Rio
 
#5

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 16. Jul 2018, 16:39
Aber ich schreibe so schnell. Manchmal drifte ich etwas in den lokalen Slang hier ab. HAK der 80er Jahre und 3mal in der Woche Steno und Schreibmaschine schreiben. Ich bin voll die Tippse.

asdf jklö asdf jklö fdsa ölkj ... und die ganzen Permutationen korrekt über eine zweistellige Anzahl von Seiten.

Wir waren so in der Übergangszeit mit dem letzten PL/I Praktikum am IBM Host mit Ausdrucken über Nacht mit Compilierfehler am Ausdruck. Hoch gepriesen sei der PC.

Auch wenn sich manche Beiträge ähnlich anhören die darunterliegende Thematik ist ähnlich. Delphi als Vertreter zwischen zwei Welten Peer 2 Peer (Desktop) und teils historisch gewachsen durch die Formularanwendungen die MS tunlichst hat versucht zu vermeiden haben wir teils the best und anderensfalls the worst of both worlds. Der PC Server ist ein IBM Mainframe genauso.

Terminal Services. Bis diese Rechner mal verschwinden gibt es immer Zwischenschritte, wo andere die keine fertigen Komponenten nehmen 'Kompetenz' am Ende umsonst aufbauen, wenn sie zu tief ins Detail abgleiten.

Du kannst nicht gleichzeitg zentralisieren und dezentralisieren. Entweder dominiert im Netz draußen, hinter dem Gateway der Zentralismus, dann wird das LAN eher Peer 2 Peer (UNIX und Windows bis 98 in Reinform) und sonst umgekehrt.

Ich habe in keinem Unternehmen mit Delphi im Umfeld von KMU (neighborly help) troubles. Klarerweise sind die Anforderungen nicht groß.

Ich bin mir schon bewusst, dass die meisten das alles klar ist. Aber sollte sich mal ein junger Entwickler hierher verirren, dann ist es nicht schlecht wenn man die Geschichte aufbereitet. Delphi hat mal keine kurze.

Manche Diskussion, nicht unbedingt hier, drehen sie oft um Themen die für die keine Lösungserfordernis gegeben ist. Diesen Dialog basierten Anwendungen wohnt etwas die Vorstellung und auch dem Trend in Richtung 'Einmal auf das Knöpfchen gedrückt und das Tagewerk ist erledigt' inne.

Das Modell ginge aber davon aus, dass bezüglich Security man selbst alles darf und alle anderen nichts.

Es ist aber unterhaltsam über die Jahre wie Themen immer wieder aufpoppen und dann probiert wieder eine Generation mit IDE Extension die Produktivität hinauszudrehen. Im VS schon ein Weilchen sehr beliebt.

btw. Fulgan funktioniert wieder.

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

Registriert seit: 22. Jun 2018
2.175 Beiträge
 
#6

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 16. Jul 2018, 21:43
Ich finde es ist nicht leicht deine Texte zu lesen und zu verstehen. Besonders wenn nicht ein einziges "SSL" drin enthalten ist.
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#7

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 16. Jul 2018, 21:55
Ich finde es ist nicht leicht deine Texte zu lesen und zu verstehen.
Das ist doch ganz einfach: Roll mal mit den Augen dabei
  Mit Zitat antworten Zitat
DieDolly

Registriert seit: 22. Jun 2018
2.175 Beiträge
 
#8

AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?

  Alt 20. Jul 2018, 19:17
https://indy.fulgan.com/SSL/

ist wieder erreichbar.
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz