On Mon, Aug 25, 2003 at 12:58:04PM +0200, Andreas Jellinghaus wrote:
> wenn ich das richtig sehe, dann verschickt dein slrn
> utf-8 als iso-8859-1 gekennzeichnet...
Nein, das w�re sehr ungew�hnlich.
> > K�ntest Du (mir privat) ausf�hren, warum Du IPSec derartig mi�traust,
> > gleichzeitig eine technisch equivalente L�sung bevorzugst?
>
> die handhabung dieser beiden ist mit nichten equivalent.
Nat�rlich. SSL ist ein Applikationstunnel und IPSec ein Netztunnel.
SSL bietet Layer4, IPSec Layer2.
> ssl/tls ist fein abgekapselt, es f�hrt zu keinen probleme mit
> unterliegenden protokollen, und dar�ber liegende protokolle haben
> keine oder nur leichte anpassungn ("https" im url etc.).
Technisch gesehen, ist https etwas v�llig anderes als http. Die Anwendung
mu� statt connect(2), ssl_connect(3) aufrufen. Es geht also nur mit
Anwendungen, die explizit ssl beherrschen.
> das macht das debugging recht einfach und angenehm, und
> man kann sich leicht kleine hilfsprogramme zusammenschustern
> (etwa 10 zeilen perl f�r http proxy mit ssl entzerrung und
> flickerei im html source).
HTTP �ber IPSec ist noch leichter zu debuggen: Au�erhalb des Tunnels mit
einem Sniffer oder normalen Proxy.
> die interaktion von routing und firewall ist kaum da, das kann
> man noch gut verstehen. wenn ip tunnel ins spiel kommen, dann
> wussten selbst rusty russel und harald welte nicht, wie die
> genaue interaktion ist. wenn man es herausfindet, kann man das
> aber auch noch in den griff bekommen und verstehen, es ist
> sogar sinnvoll geregelt (zumindest linux 2.4.*).
IPSec bietet schlicht einen Layer2 Link. Darauf kann man routen oder
sonstwas treiben. Das ist sehr trivial.
> wenn in dieses mix aber noch die spd von IPsec mit hereinkommt
> in der implementation von linux 2.6.*, dann gibt es nicht nur
> eine regeldatenbank (routing) oder zwei (firewalling), sondern
> nun drei, und wie diese interaggieren ist sehr schwer zu verstehen,
> insbesondere wenn IPsec tunnels ohne explizites tunnel interface
> konfiguriert wurden.
Man kann sich nat�rlich gern und fix in den Fu� schie�en, wenn man bei der
Implementation die Layer2 Funktion nicht sehen will. Aber das ist nicht das
Problem von IPSec.
> zudem ist debugging aktuell ein alptraum, und es ist unwahrscheinlich
> das sich daran was �ndert.
Ich kann IPSec gut und schnell debuggen.
> beispiel:
> eingehend sieht man ein ipsec packet im firewalling
> zwei mal, ausgehend ins ipsec nur einmal.
Depends. Ich kann es zweimal sehen eingehend sehen.
> oder routing entscheidung: vor oder nach dem einpacken in einem ipsec
> tunnel, oder gar zweimal? (freeswan: zweimal, linux 2.6: je nach
> konfiguration.)
Es sind verschiedene Ebenen. Ein Tunnel ist ein Interface, dessen Pakete
selbst geroutet werden. Einmal verstanden, immer begriffen.
> ipsec als isolierten teil betrachten geht nicht: wird
> ipsec hinzugef�gt oder entfernt, so muss oft routing- oder
> firewall tabelle ver�ndert werden, oder beides.
Das ist bei allen Tunneln so.
> ja, es gibt simple, kleine, verst�ndliche ipsec scenarien,
> die ganz einfach sind und in howtos beschrieben sind. daf�r
> taugt ipsec. f�r mehr IMO nicht.
Ich verwende IPSec oft und viel. Ich kann Deine Einsch�tzung also nicht
teilen. F�r jemanden, der ohne Grundkenntnisse an IPSec geht, dabei noch die
grottenschlechten Howtos bekommt, ist es aber sehr wohl ein Problem.
Im �brigen gilt das auch f�r SSL und SSH. Jedenfalls wenn man wie bei IPSec
hinter die Kulissen schauen will.
> ein ah/espdump programm w�re sehr praktisch zum debugging:
tcpdump exisitiert, tcpdump kann (wenn Schl�ssel bekannt) auch reinschauen.
> ah/esp packete wie tcpdump sniffen und speichern, aber aus
> der lokalen sad die schl�ssel zum dekodieren ziehen, und
> so den inhalt extrahieren.
Das geht.
> momentan wird der nutzen von diagnose tools wie tcpdump und co durch
> ipsec stark eingeschr�nkt.
Das ist allerdings der Sinn von Krypto im Netz. Auch ssl/ssh Verbindungen
kann man ohne Schl�ssel nicht mitlesen.
> dieser effekt ist bei tls/ssl wesentlich geringer.
Nein. Man hat dort nur durch geschickte serverseitige Konfiguration einen
Gro�teil der Konfigurationsfreiheiten versteckt. Und man mu� f�r SSL alle
Anwendungen umschreiben. �ber IPSec l�uft aber selbst Windows mit Broadcasts.
> zudem ist ssl sehr gut in viele anwendungen integriert
> und funktioniert im grossen ganzen. ipsec funktioniert
> im wesentlichen genau dann, wenn die anwendungen davon
> nichts wissen m�ssen. das ist richtig und auch ganz
> nett f�r die gesicherten filialnetze und auch den
> roadwarrior.
Eben. Jedes hat seinen Zweck.
> wenn aber spontan irgendwelche verbindungen zu bisher
> unbekannten gegenstellen aufgebaut werden sollen:
> mit tls/ssl kein problem. ipsec?
Mit IPSec w�rde das auch gehen, ist aber sinnlos. Man will keinen
Kryptotunnel zum Server, sondern eine verschl�sselte Kommunikation. SSL
bietet letzteres unter Verzicht auf ersteres. Das ist f�r diese F�lle
ausreichend.
> mal eben ipsec konfigurieren um eine webseite anzuschauen oder ein
> formular dort auszuf�llen? das macht keinen sinn. web server haben ja
> wenigstens meist statische ip addressen, da k�nnte man sich mie OE
> helfen. aber ip telefonie?
IP Telefonie macht man �ber IPSec am schnellsten. Besonders, wenn man
Hardware IP Telefone hat. Der IPSec Tunnel endet aber nicht am Telefon,
sondern am Gateway, da� man eh' zum W�hlen braucht. Geht problemlos.
>> Deine Argumentation st��t mir wieder mal auf: Warum hatte ich auch nur
>> angenommen, Du k�nntest den ernsthaft nachvollziehbaren Gedankengang
>> auch nur sachlich in Erw�gung ziehen?
>
> Wer ein Scenario aufstellt, der muss sich auch die Frage gefallen lassen,
> wie das Scenario eintretten kann, welche Voraussetzungen damit m�glich
> sind, wie wahrscheinlich es ist.
Sicher. Nur ist Deine Antwort nicht in der Form ausgefallen. Sondern als
Angriff gegen den Fragesteller.
> In dieser Diskussion haben sich viele beteiligt, die solchen
> �berlegungen ausweichen, die nicht begr�nden k�nnen oder wollen,
> warum ihr Scenario mehr Relevanz hat als eines, in dem 1+1=3 ergibt.
Da sind sie in bester Gesellschaft. Denn Du behautest auch nur die
(Nicht)Relevanz von Szenarien.
> zum thema p2p mit tcpa:
> [ ] du hast die diskussion verfolgt und die referenzierten
> artikel gelesen.
Korrekt.
> cypherpunks, juli/august 2002, Argh! Anonymous.
> Wenn es probleme beim googeln gibt, so kann ich dir
> die artikel gerne schicken.
Danke, nicht n�tig.
> kurzzusammenfassung: es geht nicht um den tausch von DRM
> gesch�tzten dateien, sondern um ein p2p netz, das nicht von
> riaa und mpaa mit falschen daten geflutet werden kann, weil
> nur authorisierte software teilnehmen kann. ebenso kann nicht
> gelogen werden (z.B. bei den freigegebenen dateien).
Dazu hatte ich bereits in dem vorigen Artikel etwas geschrieben. TCPA kann
das nicht leisten. TCPA kann eben nicht die Mentalit�t und Motivation des
Anwenders zertifizieren. Deswegen kann die RIAA problemlos an solchen Netzen
teilnehmen und die b�sen Buben ermitteln.
> tcpa kann nicht nur das knacken von DRM software erschweren,
> sondern auch software f�r private kommunikation sicherer machen.
Sicher, allerdings begr�ndest Du auch hier nicht die Relevanz dieses
Szenarios. Ich k�nnte es unter 1+1=3 einsortieren und neige auch dazu.
> als positives beispiel werden meist chinesische dissidenten
> o.�. zitiert, als negatives der feind des tages (z.Zt. brauner sumpf,
> terroristen, kinder pornographie).
Chinesische Dissidenten werden mit TCPA eher Schwierigkeiten bekommen, weil
auf den ausgelieferten Systemen sichergestellt werden kann, da� eine
Nachinstallation von Fremdsoftware nicht zul�ssig ist. Der Internetzugang
kann mit TCPA so gebaut werden, da� er nur noch bei unmodifiziertem Rechner
funktioniert. Irrelevant? Nicht mehr als Deine unsubstanzierten Vorteile f�r
den Dissidenten.
> wie werden listen von vertraunswerter hardware und software erstellt
> und verwaltet? Ein paar Leute bef�rchten, das es nur eine zentrale
> liste gibt, die jeder benutzt. Dann muss aber die Video komponente
> bestandteil sein, damit die Online Videotheken mit DRM zufrieden
> sind. Und dann taucht beschriebens Problem auf.
Die Lobbyarbeit von MPAA und Co. wird diese L�sung vorziehen.
> Wenn dagegen f�r jeden zweck oder gar jedem anbieter eigene listen
> gef�hrt werden, so ist das erheblich mehr arbeit, erlaubt zwar
> mehr flexibilit�t, aber ob das noch skaliert oder sicher ist?
Es skaliert nicht (einfache �berlegung) und ist nicht sicher (Gegenbeispiele
sind �ber Installation fremder CryptoProvider durch Fehler in den NSA Keys
bekannt).
> Ich frage mich, warum Pay per view schlecht ist.
Ich mag es nicht. Mehr schrieb ich auch nicht.
> Mit einem solchen Gesch�ftsmodell kommt die Filmwelt aber nicht
> klar, und es ist fraglich, ob es daf�r viele Kunden gibt.
> Daher braucht die Filmwelt eine M�glichkeit den Preis auf
> viele Kunden zu verteilen. Wenn die Privatkopie nach deutschem
> Verst�ndnis m�glich und erlaubt ist, inclusive der Kopie von
> der Kopie, so kann sich ein verkaufter Film rasant auf sehr, sehr
> viele Leute verteilen, und nur sehr wenige m�ssen den Film kaufen.
Korrekt. Trotzdem existiert die Industrie seit Jahren. Trotz Video- und
Kassettenrekorder die beide als Untergang der Kultur betrachtet wurden.
Internet ist nichts weiter als ein weiterer Aufschrei der Industrie.
> Interessant ist, das nur in der heutigen Welt mit weitgehend
> aufgepresstem Einheitsgeschmack ein solches Problem auftritt.
Richtig. Die sinkenden Verkaufserl�se der Musikindustrie sind in der
schlechten Qualit�t begr�ndet.
> Wo die Geschm�cker sehr unterschiedlich sind, so bilden sich
> eher kleine Cluster von Leute mit einem bestimmten Geschmack,
> und wenn jeder solcher Cluster eine Kopie kauft, so k�nnte
> das ausreichen.
So funktioniert das auch. Nur ist es f�r Nichtmainstream-Geschm�cker (wie
praktisch meine gesamte Umgebung) sehr schwer geworden, �berhaupt etwas zu
kaufen, da der Mainstream die Alternativen erdr�ckt. Also geht praktisch
meine gesamte Umgebung in den Medien- und Kaufboykott. Das hat nichts mit
selbstgemachten Kopien zu tun. Ja, interessante Konzerte und Co. werden
bezahlt.
> Zudem scheitert das ganze modell nat�rlich an der M�glichkeit,
> das Freunde einen Film durchreichen.
Das Szenario kannst Du knicken. Es ist zu aufwendig. Die Motivation fehlt.
> Wenn jeder nur f�r direkte Freunde und Bekannte kopien macht,
Bitte h�re auf, f�r die MPAA Gedankenketten zu entwickeln, die der Realit�t
nicht entsprechen. Es nervt.
> Ich w�rde mich sehr freuen, wenn es finanziell weiter eine
> tragf�higes Gesch�ft ist, Filme zu produzieren und damit
> Einnahmen zu bekommen.
Kein Problem. Es w�rde reichen, wenn die produzierten Filme/Musik meinen
Geschmack auch nur ann�hernd treffen w�rden. Ich war das letzte Mal vor der
Jahrtausendwende im Kino (insgesamt vielleicht sechs mal seit 1990) und der
Fernseher ist bei uns daheim etwas eine Stunde pro Woche an. Dann l�uft
irgendwas auf arte/3sat oder so. Nebenbei wird geb�gelt (Wer b�gelt, w�hlt
das Programm aus). Auf der Kulturarena haben wir dagegen echtes Geld gelassen.
> Das Modell, Filme zu verkaufen, kann scheitern, wenn Kopien m�glich
> sind. Welche Alternativen gibt es?
Mehr als den Mainstream bedienen. Ich betrachte das derzeitige industrielle
Angebot an Musik/Film als intellektuelle Beleidigung. Lieber les ich ein Buch.
(Daf�r wird auch viel Geld ausgegeben, obwohl es Kopierer/Scanner/eBook gibt.)
> Ein solches Pay per view System muss ja nicht kundenfeindlich sein, es
> kann trotzdem erlauben anzuhalten, zu spulen, denn film gleich ein
> zweites mal zu sehen und so weiter.
Man kann sich vieles ausdenken. Es ist nur irrelevant, solange das Angebot
dahinter schrottig ist. Man wird dem Mainstream zwar mehr Geld aus der
Tasche ziehen k�nnen, doch wird es den Rest nicht zur Geldausgabe verleiten.
Im Gegenteil.
> Nur wenn ich zwei monate sp�ter einen Film noch einmal
> sehen will, ich habe kein Problem damit, nocheinal
> zu zahlen.
Das Modell hei�t Kino.
> Ich habe kein Problem mit Pay per View per se,
> das Problem sind akzeptable Rahmenbedingungen.
Ich habe ein Problem mit Pay per View. Und?
> Ich kann mit vorstellen, das am Ende ein Pay
> per View System sich durchsetzt, das f�r Kunden
> angenehme Konditionen hat, die weltweite Vielfalt
> der Musik und Filme bieted und K�nstler und
> Produzenten einen vern�nftigen Ertrag bringt.
Ich m�chte das bezweifeln. Alle Erfahrungen mit industrieller
Rechteverwertung in der Unterhaltung zeigen, da� das Niveau bei steigenden
Entgelten immer weiter abrutscht. Pay per View wird das nur noch verst�rken.
> Wie man dahin kommen kann ist schwierig. Im wesentlichen
> f�llt mir auf, das in der Vision die Distribution keine
> wichtige Rolle mehr spielt. Damit ist klar, wer viel zu
> verlieren hat.
Die 'Verleiher'? T�usche Dich da bitte nicht.
Die 'Raubkopierer'? *Lach* �ble Industriepropaganda.
> So, zur�ck zu TCPA:
> > >> Naja - so unportabel wie mit TCPA waren Daten noch nie;-)
> > >
> > > Ach? Daten aus einem IBM Sicherheitsmodul f�r Geldautomaten
> > > auszulesen ist einfacher? Erkl�re mir das bitte.
> >
> > Geheime Schl�sseldaten sind schon etwas anderes als die privaten Briefe.
>
> Verschl�sselte emails sind portabel - egal ob der schl�ssel nun
> vom Typ PGP oder TCPA ist.
TCPA ist KEIN Verschl�sselungssystem. Es ist ein Authentifizierungssystem
f�r Datenumgebungen. TCPA ist daf�r da, die Portabilit�t zu unterbinden.
> Aber erkl�r mir doch bitte, wie du auf private Briefe kommst?
Ich komme von der Idee eines Dokumentenaustausches und vom Backup.
TCPA gestattet mir, meine Dokumente auf fremden Systemen immer noch zu
kontrollieren. Das ist gut, denn das bef�rdert den Datenschutz.
Der Umkehreffekt von TPCA, n�mlich der, da� umgekehrt Dokumente, die nicht
von mir stammen, bei mir Restriktionen unterliegen, macht mir Bauchschmerzen.
> Warum sollte jemand private Briefe mit TCPA verschl�sseln wollen? In der
> Diskussion mit Peter dachte ich so etwas wie einen Konsenz zu entdecken,
> das TCPA auf dem Server nur Probleme macht, und das es auf dem Client nur
> f�r Daten ist, die der Server nochmal im klar text hat.
Deine Vorstellung von TCPA deckt sich mit den Informationen, die ich �ber
TCPA habe, in keiner Weise. TCPA ist keine portable Verschl�sselung.
