Server-Client Verschlüsselung

Ich möchte zwischen meinem php-Webserver und einigen Clients (Python und AutoIt) verschlüsselt kommunizieren.
Der Transport ist per SSL/TLS verschlüsselt, die Abfragen selbst möchte ich aber auch noch verschlüsseln.

Der Server ist gemietet und ich kann keine extra Programme (wie pgp) installieren (php 5.3.2).
Am Client sollte es auch am besten mit Board-Mitteln funktionieren.
Am liebsten wäre mir eine asymetrische Verschlüsselung, nur weiß ich nicht wie ich das umsetzten kann.

Das soll jetzt keine super unknackbare Lösunge sein (gibt es eh nicht) sondern was vernünftiges, das für den kleinen Rahmen taugt.

Wie kann ich da was am besten Server- und Clientseitig umsetzten?

/edit: Bitte keine persönliche Meinungen!

Wenn die Verbindung per TLS verschlüsselt ist, was ist denn dann nicht verschlüsselt? Außerdem ist Krypto selber basteln immer eine ganz ganz schlechte Idee.

Transportverschlüsselung ist keine Ende-zu-Ende-Verschlüsselung

PHP hat in der default Installation keine PGP/GPG Funktionalität. Es bleiben dir als eigentlich nur die symetrischen Algos. aus der mcrypt lib die bei jeder Installation dabei sein sollte.

Crys schrieb:

Transportverschlüsselung ist keine Ende-zu-Ende-Verschlüsselung

Zum Vergrößern anklicken....

Welcher Teil ist denn deiner Meinung nach nicht verschlüsselt? Weisst du denn was TLS bzw https genau ist bzw. wie es funktioniert?

Wenn du deine Clients nicht ändern kannst/willst und sie auch kein https können, bleibt dir eigentlich nur ein VPN. Was aber daran scheitert das du am Server nichts ändern kannst.

PS: falls es dir nicht klar ist: die URL die du via https sendest ist vollständig verschlüsselt, und https ist eine Ende zu Ende Verschlüsselung.

@ HominiLupus:
Laut deiner Aussage ist PGP oder S/MIME reine Zeitverschwendung!?

Crys schrieb:

Das soll jetzt keine super unknackbare Lösunge sein (gibt es eh nicht) sondern was vernünftiges, das für den kleinen Rahmen taugt.

Zum Vergrößern anklicken....

AES256 ist mit realistischen Mitteln nicht knackbar. Wenn man das gesamte Bruttoinlandsprodukt der USA sowie den halben Stromverbrauch selbiger Nation opfert, könnte man aber tatsächlich einzelne Nachrichten in brauchbarer Zeit entschlüsseln...

Crys schrieb:

Laut deiner Aussage ist PGP oder S/MIME reine Zeitverschwendung!?

Zum Vergrößern anklicken....

Es kommt immer drauf an, WAS du verschlüsselst.

Du klingst so, als hättest du im Zuge der Snowden-Affäre mal was von Mail-Verschlüsselung gehört und wirfst jetzt alles wild in einen Topf. Damit machst du aber einen gravierenden Fehler.

Angenommen, dein Mailserver verwendet Secure SMTP via TLS, dann ist deine Passworteingabe sowie deine Mail auf dem Weg von dir zu deinem Postausgangsserver verschlüsselt. Der SMTP - Server muss aber jetzt mit weiteren Maschinen im Internet kommunizieren. Er muss MINDESTENS mit dem Empfänger-Server reden, und das geschieht nicht zwingend über eine verschlüsselte Verbindung. Hier wandert deine Mail höchstwahrscheinlich im Plain Text durch all die Knotenpunkte.
Beim Empfänger landet die Mail jetzt unverschlüsselt im Postfach. Wenn er sie abholt, wird sie, dank TLS, während der Übertragung wieder verschlüsselt. Sie liegt aber weiterhin im Plain Text im Postfach, weil alles andere ziemliche Probleme mit Web-Mailern macht.


Du willst aber direkte Kommunikation zwischen einem HTTP-Dienst und nem HTTP-Client verschlüsseln. Dafür reicht HTTPS vollkommen.
Wenn jemand in deinen Client eindringt, kann er dei Nachricht vor jeder Verschlüsselung sowieso lesen. Wenn jemand in deinen Server eindringt, kann er die Nachricht spätestens dann lesen, wenn dein Server-Tool die Nachricht mal entschlüsselt, um sie praktisch zu verarbeiten.
Wenn statt dessen jemand zwischen dir und dem Server hockt, kriegt er nur verschlüsselte Datenklumpen.

Teste und optimiere (ggf. Stichwort PFS) deine SSL-Konfiguration ggf. noch zusätzlich: https://www.ssllabs.com/ssltest

Da wir nicht wissen, was exakt du machst und überträgst sind präzisere Tipps auch nicht möglich. Die Implementierung von asymetrischer Kryptologie ist nichts anderes als eine Entschlüsselung am Endgerät (siehe Daaron) die mal sinnvoll (Mails), mal sinnlos (Kommunikation mit einem Server, welcher die Daten entschlüsselt verarbeiten muss) sein kann. Ich bin aber sicher auch kein Krytpo-Experte.

@ Darron:
Ich habe da nur was aufgeschnapt, sonder schon reichlich darüber gelesen und recherchiert. Das meiste aber zu Mail Verschlüsslung.

Bei Mails ist TLS ja eine Transportverschlüsselung. Wenn eine Mail verschickt wird, dann ist diese nur vom Client bis zum ersten Server verschlüsselt. Intern wird die Mail (i.d.R) unverschlüsselt weitergereicht. Soweit ja richtig!?
Wenn man die Mail selbst noch per S/Mime oder PGP verschlüsselt ist es dann egal, da erst der Empfänger die Mail wieder entschlüsseln kann.


Ich dachte das ist bei HTTPS auch so.
Wenn ich mittels HTTPS Daten verschicke, z.B. meine Benutzernamen per POST-Request an den Server. Diese Anfrage aber über mehrere Server geht, kann dann nur mein Server den Benutzernamen lesen oder schon der erste (von der NSA vorgeschaltete ) Server?

Crys schrieb:

Bei Mails ist TLS ja eine Transportverschlüsselung. Wenn eine Mail verschickt wird, dann ist diese nur vom Client bis zum ersten Server verschlüsselt. Intern wird die Mail (i.d.R) unverschlüsselt weitergereicht. Soweit ja richtig!?

Zum Vergrößern anklicken....

Korrekt, die Verschlüsselung läuft nur zwischen dir und deinem SMTP-Server. Vornehmlich dient die Verschlüsselung dazu, deine Zugangsdaten zu schützen.
Dein SMTP-Server, bzw. dessen IMAP-Postfach, lagert die Daten jetzt als Klartext in deinem Postausgang/Gesendete Objekte

Ich dachte das ist bei HTTPS auch so.

Zum Vergrößern anklicken....

Ist es auch, im weitesten Sinne. Deine Kommunikation mit dem Ziel-Server ist verschlüsselt. Was der Zielserver dann damit anstellt...

Diese Anfrage aber über mehrere Server geht, kann dann nur mein Server den Benutzernamen lesen oder schon der erste (von der NSA vorgeschaltete ) Server?

Zum Vergrößern anklicken....

HTTP-Requests gehen normalerweise nicht über mehrere Server, wie du es hier beschreibst. Sie machen natürlich ein Routing durch, aber keiner dieser Knotenpunkte fasst irgend etwas an, und du verschlüsselst auch nicht gegen die Knotenpunkte (du kennst sie vorher nicht einmal), sondern gegen den, dir bekannten, Endpunkt der Kommunikation.

Was du hier hingegen beschreibst ist eine Man-In-The-Middle - Attacke.
Hierfür muss man...
a) zwischen Client und Server kommen. Spätestens mit einem Proxy oder durch Dritte betriebenen VPN-Server hast du hier schon eine Schwachstelle. In einem WLAN, vor allem einem offenen, bist du direkt in den Hintern gekniffen.
b) dem Client glaubhaft machen, man selbst sei der gewünschte Server. Hier wird es viel schwerer. Man muss das SSL-Zertifikat fälschen. Im Zuge von Heartbleed ist das gelegentlich etwas leichter als früher, und auch sonst existierten immer wieder mal Lücken gegenüber SSL.

Zu einer MITM gehören nicht nur eine gehörige Menge krimineller Energie, sondern auch schwere Lücken in den beteiligten Systemen. Wir reden hier von schweren SSL-Lücken gepaart mit wahlweise ungesichertem WLAN, physischem Eindringen in das kabelgebundene Netzwerk oder aber irgendwelchen Proxy-Changer - Viren.

Danke für deine schnellen und kompetenten Antworten!