AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Delphi Bestehende TCP/IP-Kommunikation sicher machen

Bestehende TCP/IP-Kommunikation sicher machen

Ein Thema von 361 · begonnen am 29. Mär 2018 · letzter Beitrag vom 30. Mär 2018
Antwort Antwort
Seite 3 von 3     123
Benutzerbild von sh17
sh17

Registriert seit: 26. Okt 2005
Ort: Radebeul
1.458 Beiträge
 
Delphi 10.3 Rio
 
#21

AW: Bestehende TCP/IP-Kommunikation sicher machen

  Alt 29. Mär 2018, 12:58
Da das Ganze über das Internet läuft, sollte es schon SEHR sicher sein.
Also die implementierten Verschlüsselungsalgorithmen funktionieren. Ob Du sie dann richtig und sicher anwendest (Schlüsseltausch etc.) liegt an Dir.

Soweit ich SecureBridge kenne, arbeitet es ohne DLLs und Du wirst sogar die Indys los

https://www.devart.com/sbridge/docs/
Sven
--
  Mit Zitat antworten Zitat
arnold mueller

Registriert seit: 27. Jul 2005
86 Beiträge
 
#22

AW: Bestehende TCP/IP-Kommunikation sicher machen

  Alt 29. Mär 2018, 16:47
Ich kann dir Real Thin Client empfehlen https://rtc.teppi.net Das sind sehr schnelle und robuste Komponenten für Client-Server-Kommunikation mit eingebauter Verschlüsselung über Property schaltbar.

Wenn du dein Protokoll nicht auf das native RTC-Format oder auf JSON oder XML umstellen willst, kannst du auch die RawTCP-Komponente benutzen.
  Mit Zitat antworten Zitat
Benutzerbild von scrat1979
scrat1979

Registriert seit: 12. Jan 2007
Ort: Sulzbach a.d. Murr
875 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#23

AW: Bestehende TCP/IP-Kommunikation sicher machen

  Alt 29. Mär 2018, 17:45
Wenn die Verbindung per se unverschlüsselt bleiben kann / soll dann empfehle ich ComponentAce EasyCompression Library. Verschlüsselt und komprimiert Streams. Dies habe ich bei meine C/S- Anwendung in Verwendung und bin begeistert.
Michael Kübler
  Mit Zitat antworten Zitat
361

Registriert seit: 27. Okt 2005
Ort: Berlin und Brandenburg
81 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#24

AW: Bestehende TCP/IP-Kommunikation sicher machen

  Alt 29. Mär 2018, 18:00
Hallo zusammen,

@Sven: also SecureBridge habe ich abgebrochen, da in der Demo bereits ein nerviger Fehler war.

@arnold mueller: Vielen Dank, die teste ich jetzt als nächstes, wird ein langer Tag...

@scrat1979: Vielen Dank, schaue ich mir auch an, waren das nicht die ZipForge-Entwickler? Unterstützen die auch einfach Strings? NACHTRAG: Anscheinend schon, habe ich jedenfalls im Manual gefunden. Das probiere ich auch gleich mal aus.

Geändert von 361 (29. Mär 2018 um 18:05 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von scrat1979
scrat1979

Registriert seit: 12. Jan 2007
Ort: Sulzbach a.d. Murr
875 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#25

AW: Bestehende TCP/IP-Kommunikation sicher machen

  Alt 29. Mär 2018, 22:25
Meine Komponenten für den Server sowie die Clients wurden übrigens von den sgcWebSocket-Komponenten abgeleitet nachdem ich mit vielen anderen Komponenten verzweifelt bin. Funktionierte auf Anhieb perfekt! Noch eigenes Protokoll und Userdatenbank integriert - Fertig. Vielleicht auch einen Blick wert
Michael Kübler
  Mit Zitat antworten Zitat
Benutzerbild von timog
timog

Registriert seit: 26. Sep 2006
Ort: Landkreis Oldenburg (Oldb)
95 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#26

AW: Bestehende TCP/IP-Kommunikation sicher machen

  Alt 30. Mär 2018, 07:59
Zu TMS: Die RandomDLL wird nur bei 64bit Anwendungen benötigt. Es gibt keinen Quellcode zu den Komponenten, nur kompilierte Obj-Files. Quellcodeverfügbarkeit finde ich persönlich immer wichtig.

Es gibt auch noch SecureBlackBox ohne externe Abhängigkeiten zu DLLs. Updates erscheinen sehr regelmäßig. SourceCode gibt es allerdings nur im teuersten Paket und nicht mehr als Abo. Die EULA/Lizenz findest Du hier http://www.secureblackbox.com/company/legal/eula/

Komponenten zur Kommunikation mit dem Zertifikat-Store des OS sind bei SBL ebenfalls enthalten, das könnte Dir bei der Frage zum Speichern des Schlüssels helfen (Client-Zertifikate). Insgesamt ist die Lernkurve bei SBL aber eher steil, man muss noch an einiges selber denken, wie Prüfen auf Zertifikat-Revocation, etc. Es gibt einige Beispiele und ein Forum, mit dem man sich am Anfang etwas behelfen kann, da SBL aber für mehrere Programmiersprachen verfübar ist, findet man nicht immer gleich ein Delphi-Beispiel.

Sicherheit ist halt nicht einfach und braucht Zeit.
Timo
Real Programmers are surprised when the odometers in their cars don't turn from 99999 to 9999A.
  Mit Zitat antworten Zitat
slemke76

Registriert seit: 29. Mär 2005
Ort: Quakenbrück
121 Beiträge
 
#27

AW: Bestehende TCP/IP-Kommunikation sicher machen

  Alt 30. Mär 2018, 12:17
Hallo,

Es gibt auch noch SecureBlackBox ohne externe Abhängigkeiten zu DLLs. Updates erscheinen sehr regelmäßig. SourceCode gibt es allerdings nur im teuersten Paket und nicht mehr als Abo.[..]
Habe auch die SBB im Einsatz - das einzige, was mich immer noch ärgert ist, dass mit Übernahme durch /n software meine Lifetime Lizenz hinfällig war/ist.

Was ich auch gut finde, ist der Source (ja, ich habe dann das "große" Paket gekauft), keine DLLs, 64bit Unterstützung - und ein wirklich guter & schneller Support.

Insgesamt ist die Lernkurve bei SBL aber eher steil, man muss noch an einiges selber denken, wie Prüfen auf Zertifikat-Revocation, etc.
Stimmt nicht ganz

Delphi-Quellcode:
    idUri:=TIdUri.Create(FRemoteURL);
    CertificateValidator.ValidateForSSL(Certificate, idUri.Host, '', hrServer, nil, true, Now, Validity, Reason);
https://www.secureblackbox.com/kb/he...ateforssl.html

Ich benutze die Komponenten zusammen mit Indy (IdHTTP.IOHandler) - ich glaube, in es sind aber auch Komponenten enthalten, die die Indys komplett ablösen könnten (bin mir nicht ganz sicher, fahre sehr gut mit den Indys). Die .ValidateForSSL wird in der Funktion OnCertificateValidate der TElClientIndySSLIOHandlerSocket Klasse aufgerufen. Es gibt bei der SBB auch ein paar Beispiele.

Persönlich bin ich noch einen Schritt weiter gegangen - ValidateForSSL prüft die komplette Chain (lässt sich auch noch weiter parametrisieren) - inklusive Revokes, Gültigkeitszeitraum, etc. Um einen MITM Angriff zu verhinden (man könnte ja selber eine CA erstellen, die man im Zertifikatsspeicher als vertrauenswürdig kennzeichnet) prüfe ich zusätzlich den public Teil des Serverzertifikates gegen einen hard codierten Wert (klar, bei einem Reissue muss man den Source anpassen). Alternativ könnte auch prüfen, ob es sich um die korrekte CA handelt.

Kurzum: Für das Vorhaben würde ich persönlich wahrscheinlich auf HTTPS setzen mit entsprechender Prüfung der Zertifikate. Ist sicher und man muss nicht ganz tief in die Krypto einsteigen. Halb oder falsch implementierte Krypto wiegt einen meistens in falscher Sicherheit. Hinzu kommt, dass HTTPS auch durch Firewalls i.d.R. problemlos druch geht

Optional auch noch - wie schon erwähnt - Client-SSL Zertifikate und/oder CA nutzen, dann kann der Server ebenfalls die Identität prüfen.

Grüße
Sebastian


Nachtrag:
unbedingt SBHTTPCRL und SBHTTPOCSPClient in dies uses Klausel aufnehmen, wenn man die Komponenten zur Laufzeit erzeugt (so mache ich das immer, dann muss man nach einer Delphi Neuinstallation nicht wieder etliche Packages installieren), sonst könnte der Revocation Check fehlschlagen.

Geändert von slemke76 (30. Mär 2018 um 12:26 Uhr) Grund: Nachtrag hinzugefügt
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 23:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf