Menü
Avatar von M76
  • M76

mehr als 1000 Beiträge seit 06.10.2008

Re: Zusammensetzen von geheimen und nicht geheimen Teilen?

Dangerous Beans schrieb am 15.05.2018 23:14:

M76 schrieb am 15.05.2018 21:34:

...nunja, unterschiedliche Verschlüsselungs-Schlüssel (also der Pub-Key des Senders) sollten doch wohl eine erhebliche Unterscheidung sein! Und mittels fehlenden Vertrauensstatus für unbekannte Pub-Keys für EINE e-Mail sollte der Mail-Client da auch Alarm schlagen.

Der Public Key des Absenders wird für die Verschlüsselung überhaupt nicht verwendet. Der wird höchstens verwendet, um die Nachricht (oder einen Teil davon) zusätzlich noch zu signieren. Das ist aber optional, ein Mail-Reader zeigt eine Nachricht auch ohne Signatur an.

Du hast mich hier falsch verstanden:
Auf meine urspr. Nachricht "ein explizites Unterschieden zw. verschlüsselten und unverschlüsselten Elementen - {sollte} ein Lösungsansatz bieten" war dein Einwand "Nein, denn dann könnte der Angreifer seine "Gadgets" einfach ebenfalls verschlüsseln. Dazu braucht er nichts weiter als den Public Key des Empfängers."
Nur mit welchem privaten Schlüssel sollte ein Angreifer denn die Nachricht verschlüsseln?

D.h. also etwa so...
- nicht verschlüsselter Header
- org. Nachricht - verschlüsselt mit PubKey des Empfängers + PrivKey des Senders
- Fake-Ergänzung - verschlüsselt mit PubKey des Empfängers + ??? (hier bleibt ja nur der PrivKey des Angreifers)

Den öffentlichen Schlüssel des Empfängers mag er ja haben, den privaten des Senders doch wohl kaum. Also müsste er - deiner Logik folgend - seinen privaten nutzen - das meinte ich mit "unterschiedliche Verschlüsselungs-Schlüssel".
Beim Empfänger mag der öffentliche Schlüssel des Angreifers vielleicht sogar automatisch heruntergeladen werden. Aber der Unterschied zum öffentlichen Schlüssel des echten, ursprünglichen Senders sollte dem Mailprogramm schon auffallen!

Natürlich wird der Mail-Client dann darauf hinweisen, dass keine Signatur vorhanden oder diese nicht verifizierbar ist, aber wenn er bis dahin die Nachricht schon zusammengesetzt und den resultierenden Link aufgerufen hat, ist der geheime Inhalt schon futsch.

Korrekt.
Schon das Zusammensetzen von Teilen unterschiedlicher Vertrauensstufen ist ein BUG!

Genau diese "fails" sind doch o.g. Bugs!
Es bleibt also ein Fehler in der Implementierung, nicht in der Konzeption.

Ja, definitiv! PGP als Grundlage ist ziemlich solide; S/MIME hat offensichtlich ein paar Designschwächen, aber nichts Unlösbares.

Die Frage ist, kann man konzeptionell abfangen, dass schlechte Implementierungen derart durchschlagen, dass jede Vertraulichkeit hin ist.

Das Problem sollte sich mit ein paar einfachen Grundsätzen bei der Implementierung eines Mail-Clients in den Griff bekommen lassen:

1. Kein Nachladen von Remote-Inhalten ohne Nachfrage (das hat sich ja mittlerweile schon ein wenig rumgesprochen)!
2. Teile einer Multipart-Nachricht strikt getrennt behandeln. Es darf nicht sein, dass ein nicht geschlossener HTML-Tag in einem Teil irgendeinen Einfluss auf einen folgenden Teil hat.
3. Keine aktiven Inhalte (JavaScript) ausführen.

Dangerous Beans

Beim Rest stimme ich voll zu. :-)

Bewerten
- +
Anzeige