* 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.