Bestehende TCP/IP-Kommunikation sicher machen

[Mavarik]

Nimm einfach Lockbox.

Mach einen Handshake um die Infos auszutauschen und dann go...

Im Prinzip wie es HTTPS auch "unten drunter" macht...

Mavarik

[Daniel]

Wenn es aufgrund von Restriktionen Theater im Netzwerk geben könnte, dann kannst Du natürlich auch überlegen, nicht die Verbindung als Ganzes, sondern nur Deine Nutzdaten zu verschlüsseln.

Da gibt es Bibliotheken, die sich vollständig in Deinen Quellcode integrieren lassen (z.B. LockBox oder auch von TMS) und z.B. AES-256 oder dgl. anbieten. Auch da reden wir dann über anerkannte Standards. Wichtig wird dann jedoch deren korrekte Verwendung - die schönste Verschlüsselung nützt nichts, wenn man bei der Aufbewahrung des Schlüssels schlampt. Stell Dir einen wirklich guten Tresor vor, dessen Schlüssel außen mit einem Streifchen Tesafilm befestigt wurde, damit er nicht verloren geht.

[Daniel]

Welche Zielplattformen hast Du denn zu unterstützen? Die neuen HTTP-/Net-Komponenten von Delphi unterstützen z.B. direkt die Windows-Schnittstellen, um gesicherte Verbindungen aufzubauen. Dabei wäre OpenSSL nicht erforderlich.

[361]

Hallo Mavarik, hallo Daniel,

vielen Dank für den Hinweis mit Lockbox, habe ich mir angesehen und scheidet wegen der Lizenzen aus. TMS meint Ihr sicherlich das "TMS Cryptography Pack"? Das würde bedeuten, man verschlüsselt nur die Strings? Das wäre sehr interessant für mich.

Mit den neuen HTTP-/Net-Komponenten von Delphi kenne ich mich noch gar nicht aus. Immer wenn ich HTTP lese, denke ich an Port 80, weil ich keinerlei Erfahrungen hier habe und dieser Port würde sich ja ausschließen. Auch kenne ich mich nicht mit Zertifikaten aus, die Software muss relativ leicht einrichtbar sein, aktuell einfach eine Service-DLL welche mittels kleinem Setup installiert und registriert wird. Eigentlich sollte dann schon die Kommunikation losgehen.

"Aufbewahrung des Schlüssels": Kannst Du hier Tipps oder Hinweise geben? Um es mal zu sortieren. Wenn ich eine String-Verschlüsselung verwende, ist dieses Thema dann auch wichtig? Ich würde den Schlüssel gern im Code haben, jedenfalls ist es aktuell so. Oder bezieht sich das bei der Verwendung eines Zertifikats?

Ich bin parallel auch noch auf RCx von Hagen/Himitsu gestoßen. Ein paar Empfehlungen von Euch wären jetzt schön oder auch Input wie das mit dem HTTP/Net-Komponenten von Delphi grob ginge.

VG

[Mavarik]

Zitat von 361:

Hallo Mavarik, hallo Daniel,

vielen Dank für den Hinweis mit Lockbox, habe ich mir angesehen und scheidet wegen der Lizenzen aus.

LGPL3?
Habe ich da etwas übersehen?

Mavarik

[arnold mueller]

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.

[361]

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.

[scrat1979]

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

[timog]

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.

[slemke76]

Hallo,

Zitat von timog:

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.

Zitat von timog:

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.