[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Fri, May 09, 2014 at 11:15:22PM +0200, Martin wrote:
> 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.

Das ist ein generelles Problem von Web-of-Trust. 

Nicht fuer jeden Anwendungsfall interessiert mich das Vertrauen zum
Server sondern zB dass der Server mit Daten fuer mich verschluesselt
uebermittelt, meinetwegen auch mit einer Signatur, die ich nicht
unmittelbar sofort pruefen kann. 

Anders herum allerdings: Ich als Dienstanbieter koennte damit gesicherte
Kommunikation *anbieten* ohne dass ich sie meinem Dienste-Nutzer
in jedem Fall *aufzwaenge*. 

Der Client entscheidet ggf, welchen Sicherheitsbedarf er hat, ich als 
Anbieter kann - sofern eine Policy nicht dagegen spricht - Verschluesselung 
und Vertrauen auf Request-Ebene fuer den Client *optional* anbieten.

> 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...

Ein WoT kann durchaus auch "synthetisch" aufgebaut und als Service dem
Endverbraucher ("Weidevieh") angeboten werden. Das haben wir mit
CA-ist-im-Browser heute auch schon.

Letztlich muesste ich dann eine *Liste* von mir vertrauten Systemen 
befragen, wie sie jeweils das fuer mich bisher unbekannte System bewerten 
(Scoring). Welche das sind und warum ich ihnen vertrauen sollte, das ist 
das gleiche Problem, was ich heute mit CAs auch habe. 

Aber ich koennte vertrauensunwuerdige Systeme rauswerfen und bekaeme im 
Zweifel immernoch auswertbare Antworten. Werfe ich eine CA raus, dann 
wird es in meinem "Internet" etwas dunkler.

Mehrere Systeme koennten ihrerseits jeweils autonom eine Bewertung ueber 
die "Vertrauenswuerdigkeit" treffen und mir diesen Score eben mitteilen. 
So ein score koennte auch beinhalten, wie alt eine Identitaet bereits ist 
oder wessen Signaturen sie bereits besitzt ...

Das ist durchaus ein Overhead, den habe ich allerdings bei SSL und OCSP
und so weiter auch. Fuer jeden Zugriff (wenn ich es ernst nehme).

Allerdings, indem jeder Teilnehmer mit "seinem" Key unterwegs ist, also
auch Clients, waere zum einen das Thema Authentifizierung geloest (OAuth,
OpenID, SSH, HTTP-Auth, ... ) allerdings auch das Thema Anonymitaet gefaehrdet.
 
Theoretisch liesse sich durch ein WoT auch SSL als "Layer" erhalten, auf
dem ueberwiegend mit selbstsignierten Zertifikaten gearbeitet wird, deren
Authentizitaet dann ueber OpenPGP und WoT unabhaengig von einer einzelnen 
CA ueberprueft oder bewertet werden koennte. Es liesse sich damit sogar fuer
jede einzelne Session ein individueller SSL-Key und Zertifikat
verwenden, sofern dieses Zertifikat wiederum mittels WoT verifiziert
werden kann.

Natuerlich, fuer das "Weidevieh im Internet" muesste man das dann
entsprechend vor-verDAUt anbieten, damit es nutzbar bleibt. 

Usability ist fuer mich hier gerade Out-of-scope.

Meine aktuelle Motivation in diesem Thema kommt aus der Ecke von Webservices, 
bei denen der Inhalt einzelner Dokumente bzw. Requests clientseitig verifiziert 
werden koennen sollen as in 
"Mir ist egal wer (Server, MITM, NSA, BND, Marcel D'Avis, ×?×?×?ס×?
×?×?×?×?×?×¢×?×? ×?×?תפק×?×?×?×? ×?×?×?×?×?×?×?, Merkel, ã??ã?©ã?«ã?¼ã?·å?½å®¶ä¿?å®?å§?å?¡ä¼?,
ì¤?í??ì?¸ë¯¼ê³µí??êµ­ êµ­ê°?ì??ì ?ë¶?) mir die Daten tatsaechlich liefert solange 
die *Signatur* fuer *mich* passt".
 
> > 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?

In *diesem* Fall: Aus den HTTP-Header das, was ich zum decrypten
benoetige (also irgendein mime/multipart/*), aus dem meta-Tag des dann
entschl+sselten Dokuments (HTML, XML) das, was es nachher inhaltlich 
darstellen soll. Ich sehe hier keinen Widerspruch.

***
 
mod_openpgp is an Apache 2.x module that enhances web-sites to suport
OpenPGP-signed requests, OpenPGP-encrypted requests and OpenPGP-based
Session Initiation. 

Das ist gut fuer das Vertrauen des Dienstes gegenueber einem Nutzer
(Authentifizierung, Session Management). Ich als Benutzer bekomme aber 
hier bei einem GET-Requests keine verschluesselten oder signierten Daten 
soweit ich das sehe:
http://wiki.buanzo.org/index.php?n=ModOpenpgp.WebDeveloperInformation

Gruss
Raphael

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
PGP (neu):            4E63 5307 6F6A 036D 518D  3C4F 75EE EA14 F625 DB4E
.........|.........|.........|.........|.........|.........|.........|..




-- 
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/