* Andreas Jellinghaus wrote: > ich wundere mich das du erst eine private Antwort m�chtest > "(mir privat)" und dann die private Antwort mit CC: an > die Liste beantwortest. Im vorliegenden Fall aber ok.
Ob der Generalit�t der Antwort, ja. > Es zeigt sich jedoch auch, das deine Sicht teilweise etwas > begrenzt ist: beim Thema IP Telefonie f�llt dir die IPsec > Verbindung zum Gateway ein, eine Telefonie ganz ohne POTS > und Telefonnummern bleibt aussen vor. Ich schrieb von IPSec Tunnel ab dem Gateway, nicht bis zum Gateway. Der Lokal Loop sei unverschl�sselt, weil das das Hardware-Phone nicht kann. > Deine Kenntnisse von IPSec scheinen mir aber leider unvollst�ndig. >> IPSec bietet schlicht einen Layer2 Link. > > Ist zum Beispiel falsch. Es ist richtig. Layer2 Links sind nicht notwendig an Interfaces gekoppelt. Diese Implementationsfreiheit als Vor-/Nachteil von IPSec zu werten, zeugt von Unverst�ndnis der zugrunde liegenden Technik. > Deine Aussagen zu den routing und firewall tabellen gehen am Problem > vorbei: wird der Endpunkt eines Tunnels geschwenkt, so sollte IMO keine > �nderung der Firewall und Routing Tabellen notwendig werden. Abgesehen von der Umkonfiguration des Tunnelendes sind keine weiteren �nderungen n�tig. Jedenfalls nicht in meinen Installationen. > Das Problem mit der Firewall scheint an dir vor�bergegangen sein. > Der Kommentar >> Depends. Ich kann es zweimal sehen eingehend sehen. > l�sst nicht erkennen, das es ein Problem sein kann, > wenn Packete vor der Verschl�sselung nicht durch die > Firewall Regelwerke greifbar sind. Ich kann aus Deiner Interpretation nicht herauslesen, da� Du verstanden hast, was ich schrieb. Denn da steht (von Dir zitiert), da� ich sehr wohl an allen Stellen filtern kann. Wenn Du es nicht kannst, ist Deine Implementation oder Konfiguration kaputt. Das ist aber kein generelles Problem von Protokollen. > Weiter ist deine Vorstellung >> Ein Tunnel ist ein Interface > im IPSec kontext nicht korrekt: ein blick auf die dokumentation > zu setkey zeigt, wie IPsec im tunnel modus arbeiten kann, > ohne das Interfaces dadurch erzeugt werden. Bitte verwechsle nicht Implementation und Protokoll. Ich bin mit der Formulierung 'Interface' auf Deine Ausf�hrungen eingegangen, obwohl ich auch einige IPSec Tunnel ohne explizite Tunnelinterfaces in Betrieb habe. > Das die Howtos zu IPsec grottenschlecht sein sollen kann > ich nicht nachvollziehen, z.B. die NetBSD Dokumentation > fand ich sehr hilfreich. Problem ist, das es kaum > weitergehende Dokumentation gibt, zur Kombination > Routing, Firewall, Tunnel und IPsec gibt es nicht viel. Die Anspr�che an Doku unterscheiden sich bei uns. Was Du als gute Doku empfindest, ist mit zu trivial. Was Dir an fortgeschrittener Doku fehlt, habe ich in Schulungsunterlagen, Literatur, etc. pp. Meine Einsch�tzung der Howtos unterscheidet sich somit nicht von Deiner. > Weitere kritik an der IPSec Implementierung in linux 2.6.* > w�re noch, das die SAD packete verwirft, details bekommt > man leider nicht. Ich m�chte aus gutem Grunde nicht �ber Implementierungen von Protokollen reden, wenn es um die Protokolle als solche geht. Bitte respektiere meine Ablehnung dieser billigen Nebenkriegsschaupl�tze. >> Da sind sie in bester Gesellschaft. Denn Du behautest auch nur die >> (Nicht)Relevanz von Szenarien. > > Welchen Sinn macht der Einschub "(Nicht)"? Wer ein Scenario vertritt, der > muss es begr�nden k�nnen. Der anderen Seite reicht es, nach einer > Begr�ndung zu fragen. Und wenn keine Begr�ndung kommt, so kann man das > Scenario doch wohl ignorieren? Dann werde ich Deine Scenarien in Zukunft schlicht ignorieren. Danke. >> 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. > > Nun, rechner wissen nichts �ber b�se Buben, soweit sind wir > uns wohl einig. Die RIAA kann jene P2P anwendung laufen lassen > und auf netzwerk ebene sehen, mit welchen IP kommuniziert wird. Damit ist die Begr�ndung, warum TCPA den P2P Tauschb�rsen helfen sollte, von der Rechteindustrie nicht l�nger verfolgt werden zu k�nnen, als unsinnig entlarvt. Das war Dein Szenario f�r TCPA, es ist hiermit widerlegt. > �berall wo eine indirekte Kommunikation benutzt wird, ist nur > der erste Hop ersichtlich. Tritt der Rechner der RIAA selbst > als vermittler auf, so kann die RIAA nur die Kommunikationspartner > sehen, nicht aber den Datenstrom. Was hat das damit zu tun? Wir reden �ber P2P, nicht �ber Mixnetze. Bitte versuche nicht Dein Szenario zu einem moving Target zu machen. Damit handeltst Du Dir nur Plonks ein. > [tcpa f�r sichere private kommunikation] >> 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. > > Frage und ich antworte. Zum Beispiel ein p2p netz oder ein System > zur verschl�sselten Kommunikation. Dieses Szenario ist soeben von Dir als zerlegt best�tigt worden. Es gibt nichts weiter zu diskutieren. > Der Vorteil gegen�ber PGP und SMTP(-TLS) ist, das man vor �bermitteln > sicherstellen kann, das der Zielrechner keine unsichere Software oder > Hardware enth�lt, etwa Software die nach entschl�sseln der Nachricht > diese dritten quellen zug�nglich macht. Ja, und? Das h�lt die Rechteindustrie nicht davon ab, teilzunehmen. Also taugt TCPA nicht zum Schutz von P2P. Im Gegenteil, es st�rkt die Rechteindustrie zu Lasten der normalen Benutzer. Dieses wird hier kritisiert. Zu Recht. > TCPA f�r sichere private Kommunikation ist aber nur sinnvoll, > wenn TCPA auf Rechnern f�r Privatpersonen verbreitet ist. Daran > glaube ich nicht, und gebe das als Schw�che gerne zu. Mir ist der Hintergrund dieses neuen Szenarios unklar. Aber la� mal, ich kann mir vorstellen, was da jetzt kommt und habe keinen Bock darauf, Dir nochmals zu erkl�ren, was der Unterschied zwischen TCPA und GPG ist. >> 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. > > Nun, einen Rechner auszuliefern auf dem die Software nicht ver�ndert > werden kann, das ist auch heute schon m�glich. Wird das heute schon > gemacht, und warum wird gewartet, bis TCPA verf�gbar ist? Ist > der vorteil von TCPA in punkto Sicherheit notwendig? Out of Context Error: Paragraph ignored. > Zudem schreibst du: kann. Muss also nicht? Wenn die Rechner also > mit beliebiger Software laufen, w�re dann nicht TCPA ein Vorteil? > > Werden die Rechner der Masse der Benutzer auf eine Software > fest eingestellt, und warum? Context: Chinesische Dissidenten. Du hattest behauptet, die h�tten einen Vorteil von TCPA. Das war unsunstanziert. Ich hatte ausgef�hrt, warum TCPA f�r einen Dissidenten nachteilig ist. Entweder Du begr�ndest endlich mal eins Deiner Szenarien sinnvoll, oder ich breche die Diskussion ab, weil Du trollst. >> Der Internetzugang kann mit TCPA so gebaut werden, da� er nur noch >> bei unmodifiziertem Rechner funktioniert. > > Ja. Netzwerkzugriff auf einen Proxy beschr�nken, und der will eine > TCPA authentifikation. Vergleichen wir das mit der Situation ohne > TCPA: Netzwerkzugriff auf einem Proxy beschr�nken. Context: Chinesische Dissidenten. Mit TCPA kann China nun sicherstellen, da� w�hrend der Internetverbindung auf dem Dissidentensystem nichts l�uft, was zur Verschleierung der Kommunikation oder zur Verschl�sselung dient, so da� der chinesische Staat keinen Zugriff mehr h�tte. Wo siehst Du da einen Vorteil f�r den Dissidenten? > Wo ist also der genaue Vorteil? Es ist *Dein* Szenario, warum TCPA so gut ist. Ich betrachte diese Frage als Bankrotterkl�rung Deiner Argumentationskette. > HTTPtunnel kann gestoppt werden, da die Client Software bekannt > ist. Wenn der Proxy aber eh sehr restriktiv den Zugriff auf > wohl ausgesuchte Webseiten erlaubt, dann da nicht viel gewonnen. Die Wei�liste von f�r gut befundenen Systemen mu� gepfegt werden. Mit TCPA wei� man, da� auch bei Kontakten zu 'b�sen' Gegenstellen, die �berwachung nicht eingeschr�nkt wird. Wo siehst Du da einen Vorteil f�r den Dissidenten? > [tcpa: eine zentrale hardware/software liste] >> Die Lobbyarbeit von MPAA und Co. wird diese L�sung vorziehen. > > Das w�re fein, damit bleibt meiner Ansicht nach aus geschilderten > Probleme die Industrie um Computerspiele aussen vor. Damit wird > nicht TCPA taugliche hardware weiterhin weit und breit erh�ltlich > sein und viele Leute werden keine TCPA taugliche hardware haben. Dein Optimismus ist mit unverst�ndlich. V�llig. Ich sehe keinen Grund, warum Computerspiele nicht auf TCPA System laufen sollten. Wegen modernere Hardware? Treiber f�r TCPA System zertifizieren zu lassen ist einfach und schnell m�glich. Soviele Hersteller gibt es nicht. > Oder nat�rlich ein Zwang von MPAA und Co zu TCPA, der die > Spieleindustrie stark beeinflusst. Ich weis das MPAA eine > viel bessere Lobby hat, aber ist die Spieleindustrie > nicht inzwischen gr��er im Umsatz als die MPAA? Man sagt der Spieleindustrie, da� mit TCPA Raubkopien der Spiele verhindert oder beschr�nkt werden k�nnen. Mit einigen gezielten Werbestrategien ist der Umschwung da. Dann verdient die Spieleindustrie noch mehr und wird sich nicht str�uben. > [tcpa liste selbst f�hren] >> Es skaliert nicht (einfache �berlegung) und ist nicht sicher >> (Gegenbeispiele sind �ber Installation fremder CryptoProvider durch >> Fehler in den NSA Keys bekannt). > > Nun, es mag f�r den allgemeinen Fall nicht skalieren etc. Was diskutierst Du dann noch? > Aber f�r geschlossene Systeme (mir f�llt auch hier nur wieder > der olle Geldautomat ein), da ist Skalierung kein Problem und > durch die eigene Liste wird die Sicherheit erheblich erh�ht, > da klar abgegrenzt wird was erlaubt ist. Das Szenario Geldautomat wurde bereits mehrfach zerlegt. Bitte la� es endlich fallen. Es zieht nicht. > Umgekehrt ist sogar der Einsatz einer allgemeinen Liste f�r solche > geschlossene Systeme kaum rechtzufertigen, hat eine Bank doch erheblich > mehr durch ein virtualisiertes System zu verlieren, als etwa eine Online > Videothek. Richtig. Also? > [pay per view / filmindustrie] >> 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. > > Die Reichweite einer Kopie ist wichtig: wieviele Leute k�nnen > in einem Vorgegebenen Zeitraum eine Kopie guter Qualit�t erhalten. Ich m�chte meine Meinung zur Privatkopie nicht weiter diskutieren. Es geh�rt nicht in diese Mailingliste. > Mit analogen Systemen und dem Tausch im Kreis der Freunde > und bekannten ist die Reichweite sehr gering. Analog, aber > industrielle Anlagen f�r Raubkopien und ein passendes > Distributionsnetz f�hren zu einer wesentlich h�heren Reichweite. Also gab es nie Musikkopien auf Kassette und auch nie Filmkopien auf VHS? Interessant. Nungut, ich habe eine andere Welt kennengelernt. BTW: Dein Rechteindustrie-Vokabular nervt. > Der Kritik am Mainstream m�chte ich mich gerne anschliessen, > aber dich nicht ganz davonkommen lassen: > Wer nicht sucht, der gibt sich mit dem zufrieden, was an > Ihn herangetragen wird. Ein Gejammer, das nur Schrott an > dich herangetragen wird, daf�r habe ich kein Verst�ndnis. Ich habe nicht gejammert, sondern das Gejammer der Rechteindustrie kommentiert. Au�erdem habe ich angegeben, wo ich gute Unterhaltung herbekomme. Deine durchsichtige pers�nliche Kritik verf�ngt also nicht. >> Bitte h�re auf, f�r die MPAA Gedankenketten zu entwickeln, die der >> Realit�t nicht entsprechen. > > "f�r" ist deine Interpretation. Dann hast Du Deine Position selten d�mlich vertreten. >> TCPA ist KEIN Verschl�sselungssystem. Es ist ein >> Authentifizierungssystem f�r Datenumgebungen. > > Soweit ich informiert bin eher klassifizierung, Sinnleere Wortklauberei. >> 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. > > s/TCPA gestattet mir,/TCPA gestattet mir, Anwendungen zu schreiben, die/ Nein. >> Der Umkehreffekt von TPCA, n�mlich der, da� umgekehrt Dokumente, die >> nicht von mir stammen, bei mir Restriktionen unterliegen, macht mir >> Bauchschmerzen. > > Wenn du das Dokument und damit die Notwendigkeit einen Rechner mit > TCPA und jener Anwendung zu nutzen akzeptierst, dann ja. Wer > zwingt dich dazu? Alle Leute, die mir heute wider besseres Wissen propriet�re Datenformate zusenden, obwohl sie wissen, da� ich die betreffende Software weder habe noch laufen lassen kann. Das geht hoch bis zu EU-abgesegneten Zertifizierungen in der Branche. Kurz die Gedankenlosigkeit der Nutzer, die ihre lokale Umgebung in alle Welt projezieren. >> Deine Vorstellung von TCPA deckt sich mit den Informationen, die ich >> �ber TCPA habe, in keiner Weise. TCPA ist keine portable >> Verschl�sselung. > > Widersprichst du der Darstellung von TCPA wie von Argh Annonymous > aufgestellt oder mit meinem Verst�ndnis dieser? Ich widerspreche deinem Verst�ndnis. > Bisher habe ich keinen Grund zu glauben, das du richtig �ber > TCPA informiert bis und ich nicht. Es herrscht Religionsfreiheit. Also darfst Du glauben, was Du willst.
