Verschlüsselungstechnik (2-Wege)

[niklaskamenisch]

hi,

kein aktuelles Problem, aber doch immer wieder interessant:
Wir nehmen den Fall an, dass wir zwischen 2 Servern arbeiten.
Server 1 setzt eine Anfrage an Server 2 ab. Dieser Antwortet mit einem XML-String (ganz normal über HTTP eventuell HTTPS).

• Sicherungsmaßnahmen wie feste IP usw. außen vor
• Maßnahmen wie VPN, SSH, ... auch nicht möglich
  => Es geht nur drum, wie mans verschlüsseln würde, nicht ob das so überhaupt sinnvoll ist

Wie würdet Ihr diese Anfrage und den Rückgabe-XML-String oder eben die Teile davon, sinnvoll verschlüsseln, so dass jemand der eventuell dazwischen hockt, es nicht entziffern kann.
Auf HTTPS alleine vertrauen?
Für Server 1 können auch 3-4 andere "Clients" die anfrage stellen. Wäre es dann gut, über z.b. einzelne Schlüsselpaare das ganze zu machen?

Es kommen ja ganz klar nur 2-Wege-Verschlüsselungen in Frage, da quasi alles übertragen werden kann.

Ich persönliche Nutze zwischen den Servern ein VPN bzw. nutze die Tatsache, dass es VMs sind und somit mir keiner reinpfuschen kann.

Ich bin mal auf eure Ideen gespannt und die Diskussion, was die Vor- und Nachteile sind, bzw. wann es eventuell übertrieben wäre ($x Verschlüsselungen ineinander, ...

Gruß Niklas

[Jens Holzkämper]

Tach,

Wie würdet Ihr diese Anfrage und den Rückgabe-XML-String oder eben die Teile davon, sinnvoll verschlüsseln, so dass jemand der eventuell dazwischen hockt, es nicht entziffern kann.
Auf HTTPS alleine vertrauen?

ja, ich würde TLS als sicher genug betrachten (potentiell mit von Hand ausgewählten Zertifikaten).

Es kommen ja ganz klar nur 2-Wege-Verschlüsselungen in Frage, da quasi alles übertragen werden kann.

Was meinst du mit 2-Wege-Verschlüsselung?

mfg
Woodfighter

[niklaskamenisch]

hi,

Es kommen ja ganz klar nur 2-Wege-Verschlüsselungen in Frage, da quasi alles übertragen werden kann.

Was meinst du mit 2-Wege-Verschlüsselung?

1-Wege: z.b. md5 => kann nicht entschlüsselt werden, außer durch ausprobieren, und dann gibts noch kollisionen (hash eben)

2-Wege: z.b. rsa => kann mit einem schlüssel verschlüsselt und mit dem anderen entschlüsselt werden, ohne das man es ausprobieren muss

oder kurz:

1-Wege: kein weg zurück
2-Wege: hin und zurück

mfg
Woodfighter

Gruß Niklas

[Jens Holzkämper]

Tach,

1-Wege: z.b. md5 => kann nicht entschlüsselt werden, außer durch ausprobieren, und dann gibts noch kollisionen (hash eben)

ja eben, ein Hash hat mit Verschlüsselung ja erstmal nix zu tun. Beides ist Kryptographie, aber das ist nicht gleichbedeutend mit Verschlüsselung.

2-Wege: z.b. rsa => kann mit einem schlüssel verschlüsselt und mit dem anderen entschlüsselt werden, ohne das man es ausprobieren muss

Ah, also asymmetrische Verschlüsselung, und wie nennst du dann symmetrische Verfahren — 1.5-Wege?

mfg
Woodfighter

[niklaskamenisch]

hi,

Tach,

1-Wege: z.b. md5 => kann nicht entschlüsselt werden, außer durch ausprobieren, und dann gibts noch kollisionen (hash eben)

ja eben, ein Hash hat mit Verschlüsselung ja erstmal nix zu tun. Beides ist Kryptographie, aber das ist nicht gleichbedeutend mit Verschlüsselung.

2-Wege: z.b. rsa => kann mit einem schlüssel verschlüsselt und mit dem anderen entschlüsselt werden, ohne das man es ausprobieren muss

Ah, also asymmetrische Verschlüsselung, und wie nennst du dann symmetrische Verfahren — 1.5-Wege?

ich hatte es ja im kurzen schon korrekt geschrieben: 2-Wege => ich kann ver und entschlüsseln.
Ob ich jetzte 2 keys brauche oder einen macht für die bezeichnung "2-Wege" dabei nichts aus, sondern nur für die handhabung später dann.

Gruß Niklas

[Jens Holzkämper]

Tach,

ich hatte es ja im kurzen schon korrekt geschrieben: 2-Wege => ich kann ver und entschlüsseln.
Ob ich jetzte 2 keys brauche oder einen macht für die bezeichnung "2-Wege" dabei nichts aus, sondern nur für die handhabung später dann.

ich wollte nur darauf hinaus, dass Verschlüsselung immer "zwei Wege" ist, ein Hash, auch wenn er erstmal ähnlich aussieht, ist keine Verschlüsselung.

mfg
Woodfighter

[Whouzuo]

hi,

kein aktuelles Problem, aber doch immer wieder interessant:
Wir nehmen den Fall an, dass wir zwischen 2 Servern arbeiten.
Server 1 setzt eine Anfrage an Server 2 ab. Dieser Antwortet mit einem XML-String (ganz normal über HTTP eventuell HTTPS).

• Sicherungsmaßnahmen wie feste IP usw. außen vor
• Maßnahmen wie VPN, SSH, ... auch nicht möglich
  => Es geht nur drum, wie mans verschlüsseln würde, nicht ob das so überhaupt sinnvoll ist

Wie würdet Ihr diese Anfrage und den Rückgabe-XML-String oder eben die Teile davon, sinnvoll verschlüsseln, so dass jemand der eventuell dazwischen hockt, es nicht entziffern kann.
Auf HTTPS alleine vertrauen?

Kommt darauf an, was die Folge wäre, wenn jemand mitliest.
 somit mir keiner reinpfuschen kann.

Ich bin mal auf eure Ideen gespannt und die Diskussion, was die Vor- und Nachteile sind, bzw. wann es eventuell übertrieben wäre ($x Verschlüsselungen ineinander, ...

Das ist eigentlich recht einfach. Wenn du nicht willst, dass niemand mitliest (= nur Server 2 kann mit den Informationen von Server 1 was anfangen), musst du verschlüsseln. Hier gibt es zwei möglichkeiten: 1. Du verschlüsselst asymmetrisch oder 2. symmetrisch. Beides ist möglich. Bei asymmetrischer Verschlüsselung ist gleichzeitig noch die Authentizität gesichert, d.h. Server 2 kann sich sicher sein, dass die Nachricht auch von Server 1 stammt. Dafür ist die asymmetrische Verschlüsselung rechenaufwändiger. Bei symmetrischer Verschlüsselung kann man die Authentifizierung auch mit Zertifikaten sicherstellen.
Außerdem sollten noch Maßnahmen (z.B. Checksummen) vorhanden sein, die auch dagegen absichern, dass die verschlüsselt Nachricht manipuliert wurde. Zu guter letzt könnte noch Steganographie eingesetzt werden, wenn niemand erkennen soll, dass überhaupt verschlüsselte Daten übermittelt werden.

[Reiner]

Hi,

kein aktuelles Problem, aber doch immer wieder interessant:
Wir nehmen den Fall an, dass wir zwischen 2 Servern arbeiten.
Server 1 setzt eine Anfrage an Server 2 ab. Dieser Antwortet mit einem XML-String (ganz normal über HTTP eventuell HTTPS).

• Sicherungsmaßnahmen wie feste IP usw. außen vor

brauchst nicht, geht z.B. auch mit dyndns, man muss den Server nur finden.
Die (feste) IP hat nichts aber auch rein gar nichts mit Sicherheit zu tun!
(Es gibt eine Ausnahme bei z.B. htaccess, also dass nur eine bestimmte IP zugreifen darf, aber das ist ein wohl anderes Thema).

• Maßnahmen wie VPN, SSH, ... auch nicht möglich

Warum ist ssh nicht möglich?

=> Es geht nur drum, wie mans verschlüsseln würde, nicht ob das so überhaupt sinnvoll ist

Wie würdet Ihr diese Anfrage und den Rückgabe-XML-String oder eben die Teile davon, sinnvoll verschlüsseln, so dass jemand der eventuell dazwischen hockt, es nicht entziffern kann.

Das ist der Sinn einer Verschlüsselung!
Desw. ist DE-Mail ja auch aus dem #neuland geborener Unsinn.

Auf HTTPS alleine vertrauen?

Ja, zB!

Ich persönliche Nutze zwischen den Servern ein VPN bzw. nutze die Tatsache, dass es VMs sind und somit mir keiner reinpfuschen kann.

Eine VM ist prinzipell genauso angreifbar!
Das einzige (aus der Praxis), was da etwas schützen kann, ist die Tatsache, dass man die Ports wohl per NAT u.ä. durchleiten muss also somit nur ausgewählte Ports öffnet.
Das kann und sollte man beim Host aber auch tun. Und zudem ist der Host ja angreifbar und damit auch die VM - Vorsicht!

[niklaskamenisch]

hi,

• Sicherungsmaßnahmen wie feste IP usw. außen vor

brauchst nicht, geht z.B. auch mit dyndns, man muss den Server nur finden.
Die (feste) IP hat nichts aber auch rein gar nichts mit Sicherheit zu tun!
(Es gibt eine Ausnahme bei z.B. htaccess, also dass nur eine bestimmte IP zugreifen darf, aber das ist ein wohl anderes Thema).

Siehe unten

• Maßnahmen wie VPN, SSH, ... auch nicht möglich

Warum ist ssh nicht möglich?

siehe unten und eine zeile tiefer

=> Es geht nur drum, wie mans verschlüsseln würde, nicht ob das so überhaupt sinnvoll ist

Wie würdet Ihr diese Anfrage und den Rückgabe-XML-String oder eben die Teile davon, sinnvoll verschlüsseln, so dass jemand der eventuell dazwischen hockt, es nicht entziffern kann.

Das ist der Sinn einer Verschlüsselung!
Desw. ist DE-Mail ja auch aus dem #neuland geborener Unsinn.

Auf HTTPS alleine vertrauen?

Ja, zB!

Ich persönliche Nutze zwischen den Servern ein VPN bzw. nutze die Tatsache, dass es VMs sind und somit mir keiner reinpfuschen kann.

Eine VM ist prinzipell genauso angreifbar!
Das einzige (aus der Praxis), was da etwas schützen kann, ist die Tatsache, dass man die Ports wohl per NAT u.ä. durchleiten muss also somit nur ausgewählte Ports öffnet.
Das kann und sollte man beim Host aber auch tun. Und zudem ist der Host ja angreifbar und damit auch die VM - Vorsicht!

Um alle Sicherungsmaßnahmen zu erläutern, wäre das hier eh zu viel. Es geht mit meiner Diskussionsanregung auch nur um wirklich die Verschlüsselung. Daher auch die Eingrenzung der Alternativen. Steht aber auch im Original-Posting schon drin!

Gruß Niklas

[Felix Riesterer]

Lieber niklaskamenisch,

was spricht dagegen, eine Liste an "Passwörtern" auf beiden Maschinen bereitzuhalten, die in bestimmten Zeitfenstern gelten? Darauf basierend kannst Du dann die HTTP-Daten (also alles nach den Headern) mit mcrypt_encrypt() bzw. mcrypt_decrypt() ver- bzw. entschlüsseln.

Liebe Grüße,

Felix Riesterer.

[niklaskamenisch]

hi,

Lieber niklaskamenisch,

was spricht dagegen, eine Liste an "Passwörtern" auf beiden Maschinen bereitzuhalten, die in bestimmten Zeitfenstern gelten? Darauf basierend kannst Du dann die HTTP-Daten (also alles nach den Headern) mit mcrypt_encrypt() bzw. mcrypt_decrypt() ver- bzw. entschlüsseln.

Es spricht nichts dagegen und ist sogar mal auch eine nette Idee.
Genau so Antworten hab ich eigentlich erwartet ;)
Ideen was geht und was ihr für gut/schlecht haltet.
Rein auf die verschlüsselung bezogen.
Danke

Gruß Niklas