Re: PGP und VPNs

From: Peter Ross <Peter.Ross(at)alumni.tu-berlin.de>
Date: Mon, 12 May 2014 11:59:45 +1000 (EST)

Hi Marcus,

On Thu, 8 May 2014, Marcus Franke wrote:

>>> Plan B der von Olli genannte Weg, irgendwas zu skripten, um die
>>> "richtigen" Schlüssel für den Verbindungsaufbau PGP-verschlüsselt zu
>>> bekommen.
>>>
>>> Ich vermute (befürchte), Plan B bräuchte dann wieder ein noch nicht
>>> existierendes Protokoll und einen Dienst, der das bereitstellt
>>
>>
>> Genau. Die Partner würden z.B. IKE-Schlüsselpaare erzeugen und die
>> öffentlichen Schlüssel per PGP-signierter E-Mail austauschen.
>>
> und dann braucht der Gegenüber auch noch dieses Konstrukt,
> um überhaupt mit dir kommunizieren zu können.

Ja. Das gehört dazu.

> Wäre es nicht viel einfacher ein Script zu bauen, dass ihm ein
> eigenes Zertifikatsset für OpenVPN erzeugt, es mit Hilfe des
> öffentlichen PGP Schlüssels deines Kommunikationspartners
> verschlüsselt und ihm schickt, damit er sich in deinem VPN
> einloggen kann?
>
> Ausserdem willst du ja nicht mit deinem Key arbeiten sondern
> mit dem deines Kommunikationspartners, und von dem hast du
> nur den öffentlichen Schlüssel und aus dem kann man, das ist
> jetzt geraten, sicherlich nicht den RSA Schlüssel extrahieren?
>
> Für mich klingt das nach viel Aufwand ohne echten Mehrwert,
> was versprichst du dir von dem Aufwand mit den PGP Schlüsseln,
> ausser, dass du einen Schlüssel weniger speichern musst?

Was nicht ganz unwichtig ist.

Bis jetzt scheitert vieles im Bereich Sicherheit an "zu kompliziert" für
den Nutzer, zumindest so empfunden.

Eigentlich ist das Internet ja nicht wirklich hierarchisch. Trotzdem haben
wir (oder die meisten) uns daran gewöhnt, zentralen Diensten zu vertrauen.
Ob Facebook, Twitter, Android oder Apple - überall sind Leute sehr von
zentral bereitgestellten Diensten abhängig.

Ich finde es schon ganz erfrischend, mit meinem ZTE Open ein Firefox OS
in der Tasche zu haben, bei dem ich nicht das Gefühl habe, ständig zu
meiner Zentrale zu senden. Du darfst mir z.B. Dein LAN-Paßwort geben, ohne
daß Google es weiß;-)

Dieser Zustand sollte eigentlich selbstverständlich sein.

Nun werden die Geräte ja immer kleiner und billiger. Es sollte z.B.
einfach sein, eine "Basisstation" zuhause zu haben. Ich brauche keine
cloud, um meine eigenen Daten irgendwo bei Amazon oder Google oder Apple
zu speichern.

Wenn ich dann noch direkt auf Paketebene via VPN mit Dir kommunizieren
kann - z.B. direkt vom Handy zu Deiner "Basisstation" oder von Handy zu
Diese Basisstation kann in vielen Fällen auch mein Knotenpunkt für den
Rest der Welt sein. Meine Datenverbindung geht halt nach Hause und dann
woanders hin, und wenn möglich, erreiche ich Dich komplett von Ende zu
Ende verschlüsselt, um mit Dir Daten oder Meldungen auszutauschen. (Wenn
nicht, ist meine Basisstation z.B. PABX und ruft Dich unverschlüsselt an)

Und als Vertrauensnetz hat sich bis jetzt vorallem PGP bewährt. Wenn ich
das zum Aufbau der Verbindung benutzen kann, ist das doch mehr als gut.

VPN deswegen, weil ich dann darüber nicht eingeschränkt bin, welche
Dienste und Nachrichten ich mit Dir austauschen kann, die müssen dann
nicht zwangsweise darauf angepaßt werden.

Desweiteren schafft das auch Redundanz und kürzere Wege, wenn meine
Basisstation "weit weg" oder gar ausgefallen ist. Es ist auch hilfreich
als Anonymisierungshilfe und zur Umgehung von Sperren etc.

Ich habe das Gefühl, es gibt eine Menge "Bausteine", die, sinnvoll
eingesetzt, ein anderes Netz ermöglichen, welches wesentlich weniger
anfällig ist gegen Übergriffe in die Privatspäre, ob von Großkonzernen
oder staatlicherseits.

Einfache Bedienung sollte Teil dieses Konzepts zu sein.

Das ist für mich der technische Aspekt dieser Krise der Privatheit.

Der gesellschaftliche hat IMHO nach wie vor mit dem Respekt vor dem
Grundgesetz in Deutschland und der Verteidigung der Demokratie im weiteren
Sinne zu tun. Aber das ist vielleicht off-topic auf einer
BSD-Frage-Liste;-)

Es grüßt
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 12 May 2014 - 04:00:11 CEST

search this site