[Discuss] router verliert alle routen
Bernd Petrovitsch
(spam-protected)
Mo Nov 17 12:04:48 CET 2008
On Mon, 2008-11-17 at 06:17 +0100, Michael Blizek wrote:
[...]
> On 19:06 Sun 16 Nov , Bernd Petrovitsch wrote:
> > On Son, 2008-11-16 at 18:43 +0100, Michael Blizek wrote:
> > [...]
> > > On 18:12 Sun 16 Nov , Bernd Petrovitsch wrote:
> > [...]
> > > > Wozu?
> > > > Hintern Tunnel - spätestens am Backbone - ist sowieso alles
> > > > unverschlüsselt. D.h. drüber muß ich sowieso https/imaps/,... oder TLS
> > > > o.ä. verwenden, wenn ich auf Verschlüsselung Wert leg'.
> > > > Und dann bringt ein 2. Mal teilweise verschlüsseln drunter wenig - mbMn
> > > > nur zusätzlichen CPU/Strom-Verbrauch.
> > >
> > > Bei einer End-to-end Verschluesselung muss der andere Teilnehmer auch
> >
> > Der andere Teilnehmer ist idR ein sshd, imapd oder sonst ein Daemon. Und
> > wenn man https/imaps/TLS/... haben will und die "andere Seite" es nicht
> > spielen will, sucht man sich einer andere andere Seite.
> > BTW wenn die andere Seite nicht https/imaps/TLS/... spielen will, wird
> > sie kaum openvpn+Verschlüsselung spielen wollen (und drüber IP fahren).
> >
> > > mitspielen. Der Tunnel macht deswegen Sinn, weil sich die Funkverbindungen
> >
> > Tunnel? Es ging um Verschlüsselung am Layer3/4.
> >
> > > viel leichter abhoeren lassen, als der Backbone.
> >
> > Nochmal:
> > Die Frage war: Welches akute Problem löst man mit dem Verschlüsseln am
> > Layer 3/4 auf einem Teil der Strecke?
> > Antwort: Keines, weil man sowieso weiter oben sichere Protokolle
> > end-to-end verwenden *muß*, wenn man Wert drauf legt, daß niemand[0]
> > mitliest.
> > Deshalb ist es *vollkommen* sinnlos "unten" auf einem Teil der Strecke
> > nochmal zu verschlüsseln.
> > q.e.d
> >
> > Und genau darauf zielte die unbeantwortete Frage ab: Welches Problem
> > willst du lösen?
> > Meinetwegen ist WLAN-Traffic "leichter" abhörbar wie Backbone-Traffic
> > (für wen BTW?). Aber das erschweren desselben bringt nichts
> > nennenswertes.
>
> Es kommt darauf an, wo du die Schwachstellen siehst. Fuer mich ist die WLAN
So ist es.
> Verbindung *die* Schwachstelle. Der Tunnel bis zum letzten Funkfeuer Router
> sichert dir diese Verbindung ab.
Wenn das WLAN die einzige Schwachstelle bis zum anderen Ende ist, ja.
Ist es die einzige Schwachstelle?
Bei mir nicht.
> Bei SSL/TLS liegt die Schwachstelle beim Schluesseltausch. Wenn bei 20% von
Zum einen hast Du gerade das Them gewechselt - das Problem existiert bei
jeglicher Art von Verschlüsselung - auch bei openvpn - und deshalb
bringt es nichts, hier damit zu "pro Verschlüsselung von derhlaben
Verbindung" zu argumentieren.
> allen Seiten eine Warnmeldung auftaucht, dass das Zertifikat self-signed oder
> abgelaufen abgelaufen ist und jeder es nur noch wegklickt, ist ein man-in-the-
Zum anderen haben wir gerade die technische Ebene verlassen und befinden
uns mind. 1 Stufe höher auf der organisatorischen und sozialen.
Und für eine technische Lösung ein organisatorisches/soziales Problem zu
konstruieren, daß damit gelöst wird, ist trivial - man führt nur
genügend Argumente a la "das ist normal" oder "anders kann man es nicht
machen" oder "$OS kann es nicht und ich darf/will nichts installieren"
oder "das ist mir zu kompliziert" oder "Kunde will es so" oder ... ein
(oder erfindet es). Voila.
Versteh mich nicht falsch - ich kann damit leben, wenn die Leute alles
im Klartext machen (und wer weiß wer aller irgendwo irgendwie mitliest).
Aber dann ist es zu 100% die Entscheidung des Menschen und damit dessen
Verantwortung.
Nur gerade den Leuten, die reflexartig bei jeder Box "OK" drücken
(Pawlow läßt grüßen), einen verschlüsselten openvpn Tunnel über die
halbe Strecke zu bauen, gibt denen ein vollkommen falsches Gefühl der
Sicherheit. Selbst wenn man denen alles erklärt (oder in ein Wiki
schreibt) mEn bleibt dort nur "ich hab ja einen verschlüsselten Tunnel
und bin deshalb sicher unterwegs" hängen - und derartige Nicht-Lösungen
forcier' ich nicht.
> middle Angriff moeglich... Wenn man ueberhaupt die Moeglichkeit hat, SSL/TLS
> zu verwenden. Es geht an ein einigen wichtigen Stellen, aber kaum ueberall.
Bei mir geht es überall. Und inzwischen gibt es mbMn genug Alternativen
- auch in der proprietären Welt -, daß man "telnet" und Konsorten
pensionieren kann.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Mehr Informationen über die Mailingliste Discuss