Ideen für Netzwerkkommunikation (Sockets, TCP)

[XXXBold]

Hallo zusammen

Ich möchte eine Bibliothek für die Kommunikation übers Netzwerk erstellen, aktuell nur über TCP.

Funktionieren soll das ganze über die Netzwerk-APIs des jeweiligen OS (Sockets). Als Sprache kommen also am sinnvollsten entweder C/C++ infrage, wobei ich aus div. Gründen eher zum ersten tendiere.

Die Umsetzung alleine ist eigentlich weniger das Problem, mich würde in erster Linie interessieren, was aktuell die best-Practice mit Blick auf die Sicherheit ist. Habe ein aktuelles Projekt angefangen, welches auf OpenSSL aufbaut, und quasi ähnlich wie HTTPS im Browser funktioniert (Also via TLS1.3, mit CAs/Zertifikaten/Privatekeys usw.).

Ist der Einsatz von OpenSSL so sinnvoll, oder gibts dafür besser Ansätze? Muss auch nicht unbedingt OpenSSL sein, aber ich halte mich hierbei an das was etabliert ist. Ausserdem bietet OpenSSL ja noch jede Menge anderer Funktionen als nur TLS.
Es sollte auf jeden Fall möglich sein, mit der Bibliothek eine E2E-Verschlüsselung zu realisieren (Komfortfunktionen wie autom. Schlüsselaustausch u.ä. mal aussen vor gelassen für den Anfang).

Verwendungszwecke der Bibliothek wären z.B.

• Chat
• Dateiübertragung
• Nicht-latenzkritische Spiele/Anwendungen (z.B. rundenbasiertes wie Schach, Kartenspiele o.ä.)

Es ist mir klar, dass solches bereits existiert und ich das nicht machen müsste. Finde das Thema aber interessant und sehe es als Erweiterung meiner Fähigkeiten, sowas selbst zu realisieren. Das Projekt werde ich ggf. (soferns einen gewissen Stand erreicht) auch als OpenSource veröffentlichen.

Hoffe ich war konkret genug, um zu beschreiben was ich vorhabe. Bei Unklarheiten bitte nachfragen.
Freue mich auf eure Ideen & Anregungen.

Grüsse

XXXBold

 

[new Account()]

mich würde in erster Linie interessieren, was aktuell die best-Practice mit Blick auf die Sicherheit ist.

Es sollte auf jeden Fall möglich sein, mit der Bibliothek eine E2E-Verschlüsselung zu realisieren

Verwendungszwecke der Bibliothek wären z.B.

• Chat
• Dateiübertragung
• Nicht-latenzkritische Spiele/Anwendungen (z.B. rundenbasiertes wie Schach, Kartenspiele o.ä.)

Wenn es um solche Anwendungen geht, sollte man definitiv mal einen Blick auf MEGOLM ( auch geeignet für größere Gruppen ) und das Signal Protocol (eher für Kommunikation zwischen zwei Partnern oder kleinen Gruppen) werfen.

Am besten wird sowas unabhängig vom Netzwerk implementiert (also gegen eine Abstraktion oder Netzwerk-agnostisch programmiert), sodass man die Verschlüsselung mit einem beliebigen Transportmittel einsetzen kann.

 

[AW4]

Die Umsetzung alleine ist eigentlich weniger das Problem, mich würde in erster Linie interessieren, was aktuell die best-Practice mit Blick auf die Sicherheit ist.

Ich möchte zu diesem Thema Vorweg anmerken, dass ich dich voll und ganz verstehen kann.
Sehr interessantes Thema und absolut kein Problem ... solang dus "for the lulz" und "for science" machst.
Ich muss dich darauf hinweisen, dass der Bereich eine enorme Komplexität, Tiefe und seine Tücken mit sich bringt, dass es einem in den allermeisten Fällen (außer du bist einfach ein Naturtalent) unmöglich macht, ohne umfangreiche Vorkenntnisse und jahrelange Erfahrung alle Fallstricke bzgl. Sicherheit zu vermeiden.

Das Best-Practice im Blick auf die Sicherheit ist hier also:
Kein Homebrew einsetzen, etablierte und aktiv gepflegte Bibliotheken nutzen.

Aber solange du keine tatsächlich kritische Kommunikation damit absichern willst, hau rein!
Ich selbst habe (anfangs aus der Not und später, nach der "Erleuchtung", rein aus Interesse) eine Crypto-Suite über Microsofts CNG API mit umfangreichen Funktionen für Hashing, Passwort-Hashing, symmetrischer Verschlüsselung und asymmetrischer Verschlüsselung implementiert.
Die rottet jetzt vor sich hin und aktuell im produktiven Einsatz ist jetzt Libsodium.
Aber die Erfahrung, die Erkenntnisse und das Hintergrundwissen, durch die mehreren dutzend Stunden an Recherche und der Umsetzung selbst, sind halt Gold wert.
Außerdem hats auch Spaß gemacht.

Ist der Einsatz von OpenSSL so sinnvoll, oder gibts dafür besser Ansätze? Muss auch nicht unbedingt OpenSSL sein, aber ich halte mich hierbei an das was etabliert ist. Ausserdem bietet OpenSSL ja noch jede Menge anderer Funktionen als nur TLS.

OpenSSL ist schon sinnvoll. Ist etabliert, meist hoch optimiert (auf den geläufigsten Plattformen) und aktiv gepflegt.
Es gibt nur Stimmen, die dazu raten einfachere Bibliotheken zu nehmen, bzw. Bibliotheken, die bestimmte Crypto-Algorithmen explizit weg lassen, von denen bekannt ist, dass sie selbst von den Besten im Feld nicht immer oder/und ohne weiteres fehlerfrei implementiert werden können oder von denen bestimmte theoretische aber praxisnahe Schwächen bekannt sind oder eben nicht alles bekannt ist.
NaCL und dessen Forks (z.B. Libsodium) wären z.B. solche Bibliotheken.

 

[XXXBold]

Danke euch beiden für eure Antworten!

@new Account() Ich plane auch, das Ganze so gut wie möglich modular zu gestalten, dass z.B. die Verschlüsselung auch austauschbar ist. (Bei OpenSSL geht das ja nicht so einfach, resp. man ist recht eingeschränkt mit TLS soviel ich weiss, da halt OpenSSL da viel Arbeit abnimmt.)

@AW4 Danke für deine Warnung, es ist nicht mein Ziel eine Verschlüsselung (Also einen eigenen Algorithmus) selber zu erstellen, ist mir klar dass das in 99% der Fälle wohl eine blöde Idee ist. Für die Verschlüsselung selbst würde ich eh z.B. auf eine bestehende AES-Implementierung zurückgreifen (Hat OpenSSL z.B. auch integriert). Ich sehe den Punkt, dass viele OpenSSL deswegen nicht nutzen wollen, da es tatsächlich extrem fett und komplex ist, und die API (Zumindest für TLS) kommt teilweise wohl direkt aus der Hölle... NaCL & Libsodium werde ich mir mal ansehen, danke für die Tipps!

 

[AW4]

Danke für deine Warnung, es ist nicht mein Ziel eine Verschlüsselung (Also einen eigenen Algorithmus) selber zu erstellen, ist mir klar dass das in 99% der Fälle wohl eine blöde Idee ist.

Das meinte ich so direkt auch gar nicht.
Auch für die Crypto-Suite habe ich keinerlei Algorithmen selbst implementiert, da die in Microsofts API schon alle implementiert waren.
Die CNG-API ist sowas wie ein Baukasten, die dir alle Basisoperationen fertig anbietet und du musst das Ganze am Ende "nur noch" zusammenstöpseln.
Das allein bietet aber auch schon immenses Fehlerpotential.
AES im Modus GCM z.B. ist einer der am wenigsten fehleranfälligen Modi von AES, aber trotzdem musst du den richtig initialisieren und ausschließlich Zufallswerte aus einem geeigneten CSPRNG beziehen.
Ich weiß jetzt natürlich nicht 100%ig, was du da vor hast und evtl. schätze ich das auch komplett falsch ein, aber es reicht z.B. schon die Implementation eines eigenen "simplen" Handshakes, um gravierende Sicherheitslücken einzubauen.

Danke für die Tipps!

Gerne, hoffentlich sind sie auch hilfreich!

 

[XXXBold]

Hmm, AES mit GCM kannte ich bisher tatsächlich noch nicht, nur ECB/CBC. Werde mir das mal anschauen.

Die CNG-API ist sowas wie ein Baukasten, die dir alle Basisoperationen fertig anbietet und du musst das Ganze am Ende "nur noch" zusammenstöpseln.
Das allein bietet aber auch schon immenses Fehlerpotential.

Okay, danke dir, werde das mal im Hinterkopf behalten, wenn ich mich dann an die Verschlüsselung mache. Bin mir durchaus bewusst, dass diese Dinge alles andere als trivial sind.