#!/bin/blog

December 15, 2005

PGP Universal = Braindead

Filed under: Sicherheit — martin @ 5:39 pm

Kurze Niederschrift von ein paar Sachen, die ich heute über den PGP Universal Server gelernt zu haben glaube.

Ein Anwender bei $KUNDE beschwerte sich, daß bei verschlüsselten Mails, die er von bestimmten externen Absendern bekommt, die Namen der Dateianhänge nur “Attachment1”, “Attachment2” usw. lauten und die Dateien umbenannt werden müssen, um geöffnet werden zu können. Viel Spaß damit, wenn man nicht weiß, wie die Dateien heißen sollen, in welchem Programm man sie öffnen soll, und man auch nicht unter Linux arbeitet, wo man den file-Befehl zur Hand hätte.

Mir fiel darüber hinaus auf, daß bei Multipart/Alternative-Mails der HTML-Teil als Attachment mit dem Namen “PGPExch.htm” anhängt. Bei näherer Betrachtung des Body der besagten Multipart/Alternative-Mail findet sich im MIME-Header des “PGPExch.htm”-Anhangs Header-Zeilen nach folgenden Muster:

X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/html;
	charset="iso-8859-2"
Content-Type: application/octet-stream;
  name="PGPexch.htm"
Content-Disposition: attachment;
  filename="PGPexch.htm"
X-PGP-MIME-Structure: alternative
Content-Transfer-Encoding: base64

Was hier passiert ist, ist dann wohl klar: PGP Universal packt den Dateinamen irgendwie ins Ergebnis der Verschlüsselung, gibt dem Anhang einen generischen Namen und eine generisches Encoding und speichert die alten Daten (bis auf den Namen natürlich) in den “X-Content-PGP-Universal-Saved”-Headern ab.

Eine schnelle Google-Suche fördert keinerlei vernünftige Informationen zutage, außer einem Textfragment im Archiv einer Mailingliste:

If the binary attachment being signed/encrypted does not have a filename,
it is given one. The attachment’s name is “Attachment” + a number +
an extension. The number is a simple counter, starting at one, used to
ensure uniqueness. The extension is a three letter code inferred from
the part’s MIME type. An anonymous binary attachment with Content-Type
of image/jpeg might be named “Attachment1.jpg”, for example.

When a binary part is encrypted, the part’s file name is hidden in
the encrypted data. The publicly-viewable name of an encrypted binary
part is always a generic name. Encrypted binary have a MIME type of
application/octet-stream. An encrypted part’s headers are prefixed with
“X-Content-PGP-Universal-Saved-” to prevent them from being interpreted
by mail clients. When the part is decrypted, the process is reversed
and the original headers are reunited with the content.

(http://www.imc.org/ietf-openpgp/mail-archive/msg09389.html)

Grundsätzlich eine gute Idee, denn der Dateiname an sich kann auch Informationen rauslassen, die besser geheim bleiben sollten. (Im selben Text wird auch der o.g. Dateiname “PGPExch.htm” erwähnt, wobei mir nicht ganz klar ist, was damit bewerkstelligt werden soll.)

Gut gedacht ist aber noch längst nicht gut gemacht, denn während ich mir noch gerade so vorstellen kann, daß es möglich sein könnte, den irgendwie als Attribut ins Produkt der Verschlüsselung gepackten Dateinamen mit einer passenden PGP-Version zu extrahieren (leider habe ich nur entschlüsselte Mails zur Hand, kann also nicht experimentieren), kann ich mir nicht vorstellen, daß irgendjemand den proprietären X-Header implementiert haben könnte, um das Attachment zurückzukonvertieren. PGP Universal scheint also zu erwarten, daß auch auf der Gegenseite ein PGP Universal Server vorhanden ist, um die Mail zu entschlüsseln.

Crosspoint hat vor vielen Jahren übrigens sowas ähnliches mit der Betreffzeile gemacht. Die wurde in den Body verlegt und der Betreff wurde zu “PGP encrypted message” umgeschrieben. Das war zwar auch zu nichts kompatibel, beeinträchtigte die Funktion beim Empfänger aber nicht ganz so eklatant.

Früher, als wir nur Inline-PGP hatten (PGP nennt das “Partitioned PGP”), war das mitunter ein ganz schöner Krampf, verschlüsselt zu mailen. Schmutzige PGP/MIME-Erweiterungen und -Umbauten sind aber wirklich noch sehr viel krampfiger.

$KUNDE will dabei einfach nur Inline-PGP, so wie man es z.B. mit Thunderbird und Enigmail vollkommen ohne Bastelarbeit senden und empfangen kann.

Nachdem ich beim selben Kunden an anderer Stelle schon einmal große Probleme mit einer Gegenstelle unter PGP Universal hatte (das manuelle Zuordnen von Schlüsseln zu Mailempfängern, deren Mailadresse nicht als User-ID im Schlüssel eingetragen ist, ist dort nicht möglich), kann ich nur hoffen, daß es wenigstens beim Encoding der verschlüsselten Mails ein wenig Konfigurationsspielraum gibt und der Admin der Gegenseite erstens klug genug ist, das Problem zu verstehen und zweitens eine Lösung auf die Reihe bekommt.

Wer’s glaubt, wird selig.

Update, 24.2.2006: Zumindest das Rätsel mit den eincodierten Dateinamen ist gelöst.

Advertisements

Create a free website or blog at WordPress.com.

%d bloggers like this: