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

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Sat, 10 May 2014 02:47:55 +0200
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 für jeden Anwendungsfall interessiert mich das Vertrauen zum
Server sondern zB dass der Server mit Daten für mich verschlüsselt
übermittelt, meinetwegen auch mit einer Signatur, die ich nicht
unmittelbar sofort prüfen kann. 

Anders herum allerdings: Ich als Dienstanbieter könnte damit gesicherte
Kommunikation *anbieten* ohne dass ich sie meinem Dienste-Nutzer
in jedem Fall *aufzwänge*. 

Der Client entscheidet ggf, welchen Sicherheitsbedarf er hat, ich als 
Anbieter kann - sofern eine Policy nicht dagegen spricht - Verschlüsselung 
und Vertrauen auf Request-Ebene für 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 müsste ich dann eine *Liste* von mir vertrauten Systemen 
befragen, wie sie jeweils das für 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 könnte vertrauensunwürdige Systeme rauswerfen und bekäme im 
Zweifel immernoch auswertbare Antworten. Werfe ich eine CA raus, dann 
wird es in meinem "Internet" etwas dunkler.

Mehrere Systeme könnten ihrerseits jeweils autonom eine Bewertung über 
die "Vertrauenswürdigkeit" treffen und mir diesen Score eben mitteilen. 
So ein score könnte auch beinhalten, wie alt eine Identität 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. Für jeden Zugriff (wenn ich es ernst nehme).

Allerdings, indem jeder Teilnehmer mit "seinem" Key unterwegs ist, also
auch Clients, wäre zum einen das Thema Authentifizierung gelöst (OAuth,
OpenID, SSH, HTTP-Auth, ... ) allerdings auch das Thema Anonymität gefährdet.
 
Theoretisch ließe sich durch ein WoT auch SSL als "Layer" erhalten, auf
dem überwiegend mit selbstsignierten Zertifikaten gearbeitet wird, deren
Authentizität dann über OpenPGP und WoT unabhängig von einer einzelnen 
CA überprüft oder bewertet werden könnte. Es ließe sich damit sogar für
jede einzelne Session ein individueller SSL-Key und Zertifikat
verwenden, sofern dieses Zertifikat wiederum mittels WoT verifiziert
werden kann.

Natürlich, für das "Weidevieh im Internet" müsste man das dann
entsprechend vor-verDAUt anbieten, damit es nutzbar bleibt. 

Usability ist für 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 können sollen as in 
"Mir ist egal wer (Server, MITM, NSA, BND, Marcel D'Avis, המוסד
למודיעין ולתפקידים מיוחדים, Merkel, ベラルーシ国家保安委員会,
중화인민공화국 국가안전부) mir die Daten tatsächlich liefert solange 
die *Signatur* für *mich* passt".
 
> > Im Grunde ist ein HTTP-Response-Body nichs anderes als Daten, deren Typ
> > und Eigenschaft im Response-Header deklariert sind. Daten können hier
> > zum Beispiel ein HTML-Dokument oder etwas ähnliches 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
benötige (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 für das Vertrauen des Dienstes gegenüber einem Nutzer
(Authentifizierung, Session Management). Ich als Benutzer bekomme aber 
hier bei einem GET-Requests keine verschlüsselten oder signierten Daten 
soweit ich das sehe:
http://wiki.buanzo.org/index.php?n=ModOpenpgp.WebDeveloperInformation

Gruß
Raphael

-- 
Raphael Eiselstein <rabe@uugrn.org>               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/

Empfangen am 10.05.2014

Dieses Archiv wurde generiert von hypermail 2.2.0 : 10.05.2014 CEST