Re: HTTP mit RfC 3156 (MIME/OpenPGP)?

[Martin <martin@xxxxxxxxxxxx>]

Hi,

Ein ordentliches modul fuer einen verbreiteten Webserver das ein
"Upgrade: hkps://...." (Vorsicht: siehe nochmal ganz unten...)

2014-05-09 22:28 GMT+02:00 Raphael Eiselstein <rabe@xxxxxxxxx>:
> SSL ist ja bekanntermassen kaputt. Was gibt es denn an Alternativen?

Das hier scheint gerade "teh! kool-new aid" zu sein:
http://web.monkeysphere.info/why/#index1h2

Ansonsten gibts noch das hier: https://en.wikipedia.org/wiki/Mod_openpgp

Das Problem an der Sache ist eben wie immer das Vertrauen... wer sagt
mir denn das dein Key wirklich der ist mit dem ich reden will ohne das
ich validiere. Technisch ist es kein Problem einen signing/encryption
key von opengpg zu verwenden um damit die verschluesselung tamper
proof und/oder verschluesselt zu machen.

Wo es bricht ist eben an der fehlenden Authorisierungstelle, ohne die
ist jedes Protokolle (fuer den Paranoiden Menschen) genauso wie ein
self-signed X.509 Zertifikat durch eine MITM-Attack kompromittiert.
Mir bestaetigt ja niemand das du tatsaechlich du bist...

> Ich bin sicher nicht der erste, der auf die Idee kommt,
> HTTP mit MIME+OpenPGP (zB nach RfC 3156) zusammen zu werfen.

Interpretation des HTTP Body ist seit jeher spezifisch fuer die
jeweilige Applikation...

> Jedenfalls bin ich nach einigem Suchen nach bereits existierenden
> Implementierungen bei RfC 3156 gelandet, was das ganze immerhin fuer
> MIME beschreibt.
>
> Im Grunde ist ein HTTP-Response-Body nichs anderes als Daten, deren Typ
> und Eigenschaft im Response-Header deklariert sind. Daten koennen hier
> zum Beispiel ein HTML-Dokument oder etwas aehnliches sein.

Leider nicht... Beispiel HTML/XML:

Dein Server kann sagt:

Content-Type: application/xml; charset=KOI8-RU

dein Body sagt:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Was nimmst du dann?


> Man koennte den Response-Body serverseitig "einfach" zB signieren oder
> verschluesseln, indem man ihn vor dem Versand an den Client nochmal durch
> "gpg --clearsign" oder meinetwegen "gpg --encrypt ..." nachbehandelt.

Damit kommst du beim selben Problem wie non-SSL verschluesselte Mails
deren Content aber verschluesselt ist an. Allein durch die Header
Information hinterlaesst du genug Informationen um dich sinnvoll
tracken zu koennen.

SMTP wurde nicht umsonst um ein STARTTLS erweitert, das existiert in
HTTP unter dem "Upgrade"-Header IMHO verwendest das aber kein Eber
(HTTP-STS ist auch noch nicht verbreitet). Wie auch immer: Ohne das
ich dir vertraue (oder es eine Vertrauenskette gibt) wurde unsere
Kommunikation bereits durch MITM kompromittiert.

OpenPGP + $RANDOM_SERVICE scheitert nicht an den Algorithmen mit dem
sondern einfach daran das es eben keine CA stellen gibt.

Du kannst bereits heute einen OpenPGP Key erstellen der sich
Problemlos mit einem SSH-Server verbinden kann
(https://gist.github.com/serverhorror/26e33ed7de9f89be71a9#file-gistfile1-sh-session-L76)
+ ein wenig gpg-agent Magic. Es haengt also nicht am RSA-Key (was ja
durchaus relativ verbreitet ist) sondern an der Akzeptanz.


So zumindest meine Meinung.

LG,
Martin

PS: Das Paradoxe ist ja das hkps:// nur ein hkp:// mit
.....(Trommelwirbel)..... TLS (bekannte Zertifikate) drauf ist. Siehe
auch das hier: https://lists.nongnu.org/archive/html/sks-devel/2014-02/msg00006.html
-- IOW: Selbst die OpenGPG Menschen verwenden das ;)

-- 
https://plus.google.com/+MartinMarcher
http://www.xing.com/profile/Martin_Marcher
http://www.linkedin.com/in/martinmarcher

-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/