Komunikation verschlüsseln, https, openssl oder ähnlich

[d0ne]

Hallo,

ich suche im Moment nach einer sicheren/einfachen/praktischen Möglichkeit, die Kommunikation zwischen einem Client-Programm (in C++) und dem Webserver (in PHP) zu verschlüsseln.
Im Grunde ruft das Client-Programm ein PHP-Script auf dem Webserver auf und übergibt per GET/POST verschiedene Daten. Der Webserver mach dann - abhängig von den GET/POST-Parametern - eine echo-Ausgabe. In dieser echo-Ausgabe stehen dann die Daten für das Client-Programm.
Zur Zeit werden alle Daten unverschlüsselt gesendet - das soll sich nur ändern, es ist nur noch nicht ganz klar, wie.

Eine Idee ist, https zu benutzen. Damit habe ich mich noch nicht groß beschäftigt. So wie ich das verstanden habe, muss ich an den PHP-Scripten nichts ändern, wenn ich auf https umsteige, alles (Auslesen von GET/POST-Paramtern etc.) funktioniert genau so, wie ohne Verschlüsselung (mit http) - ist das so richtig? Man müsste wahrscheinlich "nur" am Client-Programm etwas ändern!?
Wenn das so stimmt, währe das IMHO eine gute Lösung, allerdings müssten wir und um Zertifikate etc. kümmern, und meines Wissens ist das nicht ganz billig. Auch ist noch nicht klar, wie groß die Änderungen am Client-Programm wären, bzw. wie weit das überhaupt geht.

Eine andere Möglichkeit, welche ich mir überlegt habe, ist dass die Übertragung nicht verschlüsselt wird, sondern die Daten selber.
Ich habe an eine asymmetrische Verschlüsselung, mit Public/Private-Key, gedacht. Der Server und das Client-Programm haben einen Public-Key, welcher dem jeweils anderen bekannt ist. Damit werden die Daten verschlüsselt bevor sie gesendet/ausgegeben werden.
Vorteil wäre, dass man kein Zertifikat brächte und hier Kosten sparen könnte.
Nachteil wäre, dass auf jeden auch am Webserver geändert werden müsste, wenn die openssl-Funktionen überhaupt auf dem Webserver vorhanden sind.

Und jetzt eure Meinung, habe ich irgendetwas grob falsch verstanden und das was ich mir oben gedachte habe ist Blödsinn/nicht machbar? Gibt es vll. noch eine viel bessere Möglichkeit oder "Fallen" auf die man achten muss?
Wenn beide Verschlüsselungen möglich wären, welche sollte man wählen?
Währen beide Möglichkeiten "gleich sicher"? (Bei https wäre doch z.B. MITM möglich, beim Public/Private-Key-Verfahren nicht, oder!?)

Es gibt noch ein Zusatzproblem:
Es müssen zum Teil auch Dateien (Bilder, Ton, etc.) übertragen werden - per POST. Wenn man die Verbindung per https geschützt, werden dann auch diese Dateien verschlüsselt? Und, es sollte doch Möglich sein, mit den PHP-openSSL-Funktionen auch Dateien verschlüsseln!?

mfg
d0ne

[Sirke]

Die Variante mit SSL/TLS ist eine Verschlüsselung auf der Transportschicht und damit unterhalb von der Anwendungsschicht (HTTP), dh die Klartextdaten des HTTP werden an die Transportschicht gereicht, dort verschlüsselt und dann an die Transportschicht des anderen Kommunikationspartners gesendet, um dort entschlüsselt zu werden und an die Schicht des HTTP zu reichten. Dadurch musst du deinen Client meist nur gering ändern, wobei das jedoch stark von den verwendeten Bibliotheken und Programmiersprachen abhängt. Der Server muss ebenfalls nur um Module und Konfigurationen erweitert werden.

Die Möglichkeit der Datenverschlüsselung ist natürlich etwas komplizierter zu erreichen, da beide Anwendungen um die Ver-/Entschlüsselung erweitert werden müssen. Grundsätzlich ist dieses Vorhaben jedoch möglich!

Grundsätzlich ist die Frage nach der "Sicherheit" hier nicht beantwortbar, da die Verfahren selbst alle "sicher" sein können, aber die Kombination totaler Müll...
Grundsätzlich hast du nur falsch verstanden, dass Zertifikate nicht zwingend gekauft werden müssen, sondern auch von dir selbst erzeugt werden können, du dann aber deine eigene Vertrauenskette bauen musst, anstatt auf ein Grundvertrauen eines bekannten Anbieters zu setzen.

Die Lösung mit dem Besten Kosten/Nutzen-Verhältnis ist sicherlich TLS mit einer eigenen Vertrauenskette, weil die andere Lösung viele Gedanken und ein Verständnis von Kryptographie benötigt, um die gewünschten Sicherheitsziele auch zu erreichen und nicht Lücken zu schaffen!

[chorn]

Zu den Zertifikate einen konkretes Stichwort: openssl

[Gast]

Vielleicht ist ja auch gar kein Zertifikate notwendig?

[G.Schuster]

allerdings müssten wir und um Zertifikate etc. kümmern, und meines Wissens ist das nicht ganz billig. Auch ist noch nicht klar, wie groß die Änderungen am Client-Programm wären, bzw. wie weit das überhaupt geht.

"Um Zertifikate kümmern"?
Das ist in aller Regel mit einer eMail pro Jahr erledigt.
Ein Zertifikat bekommst du ab ca. 30 Euro pro Jahr, die Einbindung in z.B. den Apache ist in 2 Minuten erledigt.
Und Änderungen am C++-Client sollten sich in Grenzen halten, ich wette mit dir, dass es da eine super simple Lib gibt, um SSL zu nutzen.
Und die wird, egal wie bescheiden implementiert, in 99,999% der Fälle leichter und schneller implementiert sein als jede Verschlüsselung der Daten.

[Flor1an]

Wenn du nur deine zwei eigenen Client/Server implementierungen miteinander sprechen lassen möchtest brauchst du ja kein offizielles Zertifikat. Du kannst dir dein eigenes generieren und die Public Keys entsprechend in deinen zwei Seiten fest integrieren. Somit ist ein PK Lookup nicht nötig. Von daher brauchst du kein Geld für Zertifikate ausgeben solang niemand "anderes" deine Zertifikate überprüfen muss.

[Gast]

kostenloses SSL Zertifikat von startcom (wobei es irgendeine Einschränkung gab, sowas wie nur für subdomains oder nicht für subdomains)

Wenn du ein Zertifikat hast dann installieren:

apache 2 mit ssl

Du kannst natürlich auch Bilder und andere Dateien im Text verlinken. Wenn du diese nicht über https sondern über http verlinkst, dann werden die aber wahrscheinlich unverschlüsselt übertragen.

[Flor1an]

Ich weiß nicht was ihr mit euren Zertifikaten habt. Wenn niemand diese Zertifikat überprüfen muss (also z.B. im Browser wie bei Onlinebanking) dann ist es egal wer das Zertifikat ausstellt. Denn Wenn die Public Keys von vorne rein her bekannt sind ist es nicht möglich da "andere" PKs einzuschleusen als MITM.

Die kostenpflichtigen sind ja nur dafür gut dass wenn du dich als Webseite vor wild fremden authentifizieren möchtest! Dann braucht du ein Zertifikat dass von einer CA erstellt wurde die dem User bekannt ist, also einer CA die im Browser eingestellt ist und somit dein Zertifikat als gültig betrachtet.

In diesem Fall geht es aber nur um die Verschlüsselung zwischen zwei Programmen, da hat der User selbst gar nix mit zutun, also muss nur der Programmierer dafür sorgen dass die entsprechenden Zertifikate gültig sind und dies kann er dadurch erreichen dass er die PKs eben direkt im Programm verankert.

[d0ne]

Ok, erst einmal vielen Dank für die Antworten!

Florian hat recht, daa der User nichts von den Zertifikaten mit bekommen und nur wir ihnen vertraunen müssen, können wir diese (wenn wir können :P) natürlich auch selber erzeugen.

Wir werden das morgen besprechen, die Entscheidung wie/was wir machen liegt nicht (allein) bei mir ...

Aber eine Frage habe ich noch:

Die Variante mit SSL/TLS ist eine Verschlüsselung auf der Transportschicht und damit unterhalb von der Anwendungsschicht (HTTP)

Darf ich daraus schließen, dass Auch Dateien, die per POST hochgeladen werden verschlüsselt sind? Bzw. ich mache in einer Datei ein "file_get_contents($fileUrl)" - auch diese Daten werden verschlüsselt!?

mfg
d0ne

[nikosch]

Hängt davon ab, ob Du die Ziel-Url mit https ansprichst.

[Flor1an]

Ja was du überträgst ist prinzipiell mal unabhängig ob SSL verwendet wird oder nicht. Egal ob du im Formular hochlädst (Ziel muss dann eben eine https Adresse sein) oder von einer Adresse etwas herunter lädst kannst du dafür SSL nutzen.

Wenn du wirklich nur Daten senden und empfangen willst musst du vielleicht gar nicht den Weg über HTTP gehen sondern kannst direkt auf einem Socket arbeiten. Wobei es durchaus auch praktisch sein kann das ganze über HTTP abzuwickeln