Bestehende TCP/IP-Kommunikation sicher machen

[361]

Hallo zusammen,

ich habe das Internet und auch das Forum hier bereits durchforstet aber stehe nach wie vor ohne Lösung dar. Folgender Sachverhalt:

Ich habe ein Delphi-Projekt, bestehend aus zwei Windows-Anwendungen, eine Server- und eine Client-Anwendung. Die Server-Anwendung nutzt TIdTCPServer und die Client-Anwendung die zugehörige TIdTCPClient-Komponente. Beide tauschen Daten darüber mittels "TIdIOHandler.ReadLn" und "TIdIOHandler.WirteLn" aus. Nun gibt es die Anforderung, diese Daten verschlüsselt zu übertragen. Also dachte ich mir, suche ich mir eine Komponente, welche einfach eine Verschlüsselung darüber legen kann und bin bei meiner Suche bei Devart SecureBridge gelandet. Anscheinend kann man den "ScIdIOHandler" dem Client zuweisen, nicht jedoch dem Server und nun gehe ich davon aus, dass das gar nicht für meinen Anwendungsfall gedacht ist. Es gibt auch kein Beispiel hierfür.

Welche Möglichkeiten seht Ihr hier, eine Verschlüsselung einzubringen? Ich möchte keine DLLs verwenden, würde auch Geld für eine Komponente ausgeben und ich würde auch einen Kryptoalgorithmus, der die zu sendenden Strings verschlüsselt in Betracht ziehen. Ich freue mich, auf Eure Antworten und auch Hinweise.

[Daniel]

Du könntest auf HTTPS setzen.
Dann hast Du zwar etwas mehr Overhead als in Deiner jetzigen Variante, die vmtl. tatsächlich ausschließlich die Nutzdaten überträgt aber Du würdest auf einen allseits bekannten und akzeptierten Standard setzen. Ob Dein HTTP-Stream dann rein aus den Nutzdaten besteht oder ob Du diese z.B. in JSON verpackst, steht Dir dann frei. Wenn die Daten wirklich nur zwischen Deinen eigenen Anwendungen ausgetauscht werden und keinerlei Fremdsysteme im Spiel sind, bist Du da ja recht frei in der Gestaltung.

[361]

Hallo Daniel,

vielen Dank für Deine Antwort. Ich habe vergessen zu erwähnen, dass es sich bei den Verbindungen um Satellitenverbindungen handelt, welche recht langsam ist und wo es auch auf den Traffic ankommt. Ich habe lediglich einen bestimmten Port (den ich hier nicht nennen darf) zur Verfügung. Mit HTTPS kenne ich mich gar nicht aus, ich weiß nur, dass die Maschinen die über meine Lösung kommunizieren wollen, kein DNS und keinen sonstigen Zugang ins Internet haben. Vielleicht schränkt das HTTPS und andere Lösungen ein?

[Benedikt Magnus]

Keine DLLs? Schließt das nur deren direkten Gebrauch ein oder ganz generell?
Wenn du nämlich mit der Nutzung der Bibliotheken von OpenSSL einverstanden bist, kann man SSL-Verschlüsselung ganz einfach durch die Nutzung der SSL-Handler (TIdSSLIOHandlerSocketOpenSSL und TIdServerIOHandlerSSLOpenSSL) der Indys erreichen. Das ist ziemlich einfach und dank SSL/TLS auch mit guter, standardisierter Verschlüsselung.
Ein nettes Beispiel gibt es hier: https://github.com/rlove/Indy-SSL-Ex...o/TestForm.pas

[361]

Hallo Benedikt,

Vorgabe ist, nur die Anwendung ohne zusätzliche Dateien wie DLLs oder ähnliches. Alles soll in der Anwendung drin sein. Ich habe bereits die OpenSSL-Variante an einem Beispeil getestet und es wäre recht einfach aber widerspricht der Anforderung. Hat jemand Erfahrungen mit Indy und SecureBridge im Bereich TCP/IP oder zur Not eine kommerzielle Alternative zu Indy, die Verschlüsselung bereits implementiert hat? Zur Not würde ich den Bestands-Code dazu auch noch mal umschreiben...

[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

[taveuni]

Zitat von 361:

Hallo Benedikt,

(..) Ich habe bereits die OpenSSL-Variante an einem Beispeil getestet und es wäre recht einfach aber widerspricht der Anforderung.(..)

Inwiefern kann OpenSSL einer Anforderung an die Verschlüsselung widersprechen?