Beiträge von Susi to visit

Zitat von tim

Habe daraufhin erst kapiert, dass ich die Kategorien, die ich auf Android als Verteilerlisten angelegt hatte, in Cardbook extra als Listen anlegen kann/muss.

Man muss zwischen Kategorien und Listen unterscheiden. Du hast nicht genau erwähnt, was du mit Android überhaupt meinst. Das ist ja nur das OS. Vermutlich meinst du die mitgelieferte Kalender-App (es gibt auch andere) in Zusammenhang mit dem Kalender bei Google (es gibt auch andere). Mein Stand dazu ist, dass Google die Kategorien im Sinne von CardDAV gar nicht unterstützt. Deshalb kann man in CardBook auf die Listen ausweichen.

Die Kategorien in Cardbook werden mir beim Tippen im Adressfeld nicht angeboten. Ich kann sie aber direkt aus Cardbook per Doppelklick oder Drag&Drop übernehmen. Warum das so ist, weiß ich nicht.

Wenn du Englisch kannst, könntest du dich direkt mit dem Entwickler von Cardbook in Verbindung setzen. Der kennt sich damit bestens aus und antwortet meist sofort.

Naja, der richtige Weg wäre doch eher der, herauszubekommen, weshalb dieses Zertifikat nicht dauerhaft gespeichert wird. Das wird sich ja nicht jedesmal ändern? Ich habe hier jüngst gelesen, dass diese Version in manchen Fällen die Passwörter nicht speichert. An anderer Stelle stand, dass sich das eine oder andere Format geändert hat. Gibt es da vielleicht einen Zusammenhang?

Ich weiß leider keine Details dazu. Ich habe die Entwicklung in den letzten Monaten nicht so verfolgt. Was ich aber gelesen habe, das ist, dass die Version 91 noch gar nicht als Update verteilt wird.

Im Firefox muss man dazu eine pref erstellen: general.useragent.override

Anleitungen dazu findest du im Netz. Ob das auch im Thunderbird funktioniert, weiß ich nicht.

Generell würde ich das nicht empfehlen. Beim Browser kann das unerwünschte Nebenwirkungen haben. Viele Downloads werden z.B. abhängig von diesem Agenten für das jeweilige OS angeboten.

Beim Thunderbird - sofern man ihn nicht zum Browsen hernimmt - sollte das nicht ganz so kritisch werden. Ich wüsste ad hoc nicht, wer diese Information überhaupt auswertet. Aufpassen sollte man trotzdem. Man weiß ja nie.

Die Frage wäre auch, wie denn der korrekte UA exakt aussehen müsste, falls er doch irgendwo eine Rolle spielen sollte? Da könnte vielleicht der Firefox einen Hinweis geben.

Überhaupt stellt sich die Frage nach dem Nutzen. Wenn der User Agent beim Thunderbird keine praktische Auswirkung hat, wozu dann ändern? Auch deine Empfänger werden sich den wohl kaum anschauen. Wenn er eine hat, dann vertraue besser auf die Entwickler.

Mein Rat wäre: Finger weg bis die Entwickler das selbst ändern.

/*

Für diejenigen, die sich für Verschlüsselung interessieren, möchte ich off-topic ergänzen, wie solche Unternehmenslösungen von Totemo, Symantec usw. funktionieren. Ich beschränke mich auf die Gateways.

Ich selbst kenne diese Lösungen nur als Empfängerin. Wir haben Kunden, die solche Lösungen einsetzen, weil diese bestimmte Inhalte nur verschlüsselt übertragen dürfen. In unserem Fall sind das meist technische Daten, aus denen Dritte Rückschlüsse ziehen könnten.

Es gibt Aussagen, wonach mehr als 50% aller Geschäftsmails irgendeine Art schützenswerte Information enthalten.

Nun weiß man, dass Verschlüsselung von E-Mails seine Tücken hat und sehr viele Anwender auch schlicht überfordert. Hier kommen diese Lösungen ins Spiel. Sie vereinfachen das sehr. Im Idealfall muss der einzelne Mitarbeiter sich überhaupt nicht damit befassen.

Angenommen, ein Unternehmen möchte, dass sämtliche E-Mails, egal ob intern oder mit externen Partnern, verschlüsselt werden. Und zwar so, dass die Mitarbeiter sich nicht kümmern müssen und auch nichts falsch machen können.

Die Lösung sieht dann so aus, dass alle E-Mails zunächst über ein Gateway laufen, das vor den Mail- / SMTP-Server geschaltet ist. Dort existiert für jeden Empfänger ein Profil mit dessen öffentlichem Schlüssel. Das Gateway verschlüsselt dann jede Mail passend. Umgekehrt entschlüsselt es jede eingehende E-Mail, überprüft die gemäß der Unternehmensrichtlinien und stellt sie dann dem Mailserver zu.

Ist für einen Empfänger kein Profil vorhanden, geht die E-Mail zunächst nicht raus. Stattdessen bekommt der Empfänger eine Nachricht, in der er gebeten wird, sich ein Profil zu erstellen. Dazu genügt oftmals schon ein digital signiertes Reply. Erst dann und nach den erforderlichen Genehmigungen geht die ursprüngliche E-Mail verschlüsselt raus.

Dass alle E-Mails verschlüsselt werden, ist etwas praxisfremd. Es gibt deshalb auch ein anderes Modell. Hier verschlüsselt der sendende Mitarbeiter selbst. Das Gateway entschlüsselt, prüft die E-Mail und verschlüsselt sie dann erneut. Ebenso in der Gegenrichtung.

Das alles kann auch regelbasiert erfolgen. Ebenso kann festgelegt werden, welche Zertifikate (Herausgeber) akzeptiert werden, welche Gültigkeitsdauer sie haben müssen, ob man PGP überhaupt verwenden darf usw. .

Last but not least gibt es natürlich auch die komplette Ende-zu-Ende-Verschlüsselung. Das möchten Unternehmen verständlicherweise meist nicht, weil sie die Hoheit behalten möchten und gesetzliche Auflagen, z.B. zur Archivierung, erfüllen müssen.

Um das alles zu komplettieren bieten Totemo, Symantec und Co. in diesem Zuge auch Lösungen für Smartphones und den normalen Dateiaustausch via ftps, https, USB-Stick usw. an.

Alles in allem erreicht ein Unternehmen damit, dass E-Mails und alle anderen Dateien nur Ende-zu-Ende-verschlüsselt von A nach B kommen, mit Protokollierung und allem Drum und Dran, ohne dass die Angestellten sich mit den Details herumschlagen müssten.

Informationen, die nur für die Geschäftsführung bestimmt sind (oder die Manager der Abteilung Dieselaggregate ) können auch nur von denen gelesen werden. Selbst im Falle eines Einbruchs.

*/

Zitat von Feuerdrache

Geht es jetzt wieder los?

Nein, zumindest nicht weiter mit mir. Ich lasse mich auf das Spiel nicht weiter ein.

Tatsache ist, dass der von mir verlinkte Artikel den Rückschluss, den du ziehst nicht erlaubt. Weder in die eine noch in die andere Richtung. Du legst die Information darin aus, wie es dir passt.

Du benimmst dich wie unsere Politiker, die gerade im Wahlkampf stecken. Du gehst das Thema voreingenommen an, ignorierst Punkte, die dir nicht ins Bild passen und stellst unbewiesen Behauptungen auf. Beispiel:

Zitat von B. Mueller

Totemo ist sowohl für die Verschlüsselung als auch für den Transport verantwortlich. Sie haben die Mail «verunstaltet»!

Der von dir zitierte Code-Block aus der Mail zeigt, dass Totemo für die Verschlüsselung verantwortlich ist. Genau das ist die Funktion dieser Software. Die Entwickler haben bereits bestätigt, dass die vollkommen korrekt ist.

Dieser Code-Block besagt gar nichts über den Transport, der von den Mailservern und deren MTAs übernommen wird. Spätestens für den MTA/MDA beim Empfänger kann Totemo gar nicht mehr verantwortlich sein. Ob also Totemo die fraglichen Content-Type Header so erstellt hat oder nicht, geht daraus nicht hervor. Ob absichtlich oder aus Unwissenheit. Damit täuschst du die Leser.

Der Autor der IETF schreibt klar, dass typischerweise MTAs so etwas machen. Darauf wollte ich hinweisen. Es ist unsachlich und dreist, das so zu verdrehen.

Ich frage mich auch, welchen Sinn das Getue haben soll. Wem ist damit geholfen? Totemo wird laut eigenen Angaben von mehrere Millionen Personen benutzt. Das Problem haben aber nur die Benutzer von Thunderbird ab Version 78. Selbst wenn die Ursache bei Totemo liegen sollte, PGP mit Thunderbird ab 78 spielt in deren Umfeld keine große Rolle. Deren Kunden kommen aus dem Firmenumfeld und benutzen vorwiegend Outlook mit S/MIME. Selbst in diesem Fall sollte sich m.E. eher Thunderbird bewegen, damit er im Geschäft bleibt. Außerdem konnte der Thunderbird das ja mal, vor der 78, mit Enigmail.

Meine Intention war, hier einen Hinweis zu geben. Ganz neutral. Ich will weder Totemo noch Thunderbird beschuldigen. Ich werde mich deshalb auch ganz bestimmt nicht erneut in eine unsachliche Diskussion mit dir ziehen lassen. Allerdings verwahre ich mich davor, dass du meine Hinweis hier "ideologisch" verdrehst.

Zitat von B. Mueller

Damit hat für mich totemomail den «Schwarzen Peter». Thunderbird hält sich an den Standard und es kann nicht die Aufgabe eines MUA sein, aus «Schrott» etwas Brauchbares zu zaubern.

Nein, das kann und darf man so nicht daraus ableiten. Deshalb hatte ich mich auch nicht dazu geäußert. Du interpretierst etwas hinein, was dort nicht steht.

1. Würde es bedeuten, dass andere Programme einschließlich Thunderbird/Enigmail sich nicht an den Standard halten würden. Siehe auch Punkt 3.
2. Gibt es nicht den Standard. Es gibt eine ganze Reihe weiterer RFCs. Inline/PGP unterscheidet sich zum Beispiel deutlich von PGP/MIME. Ich nehme an, gerade auch, was die Content-Types betrifft. Während PGP/MIME Anhänge direkt in den verschlüsselten Teil integriert, kann INLINE PGP das nicht. Hier bleiben Anhänge als Anhänge erhalten.
   Genauer gesagt, sie können es. Der Standard schreibt nicht vor, wie mit Anhängen zu verfahren ist. Manche Programme bieten an, die Anhänge zuvor separat zu verschlüsseln, andere - wie K-9 - lassen Anhänge bei INLINE erst gar nicht zu.
   Damit kommen wir zum nächsten Punkt.
3. Die RFCs lassen stets einen gewissen Spielraum, wie gerade am Beispiel K-9 gezeigt. Manches muss eingehalten werden, anderes ist optional. Auch Thunderbird/Enigmail hat den Spielraum ganz offensichtlich anders genutzt als die aktuellen Versionen.
4. Laut dem Artikel ist es der MTA, der diese "Umformung" vornimmt, nicht Totemo. Der MTA ist üblicherweise Teil des Mailservers. Davon gibt es normalerweise zwei. Einen beim Sender, einen beim Empfänger.
   Rein theoretisch könnte es also sogar ein Problem auf der Seite des Empfängers sein, wenn dessen MTA diese Änderungen vornimmt, bevor er die E-Mail an den MDA übergibt. Die Kette geht stets so:
   
   Client Sender -> ... -> MTA/MDA Sender -> MTA/MDA Empfänger -> ... -> Client Empfänger
   
   Die mir bekannten ähnlichen Fälle betrafen den MTA des Microsoft Exchange Servers.

Servus,

Interessantes Thema. Mich erinnert es an ein Problem mit MS Exchange, bei dem ebenfalls die Struktur PGP-verschlüsselter E-Mails verändert wurde bzw. wird. Mir hat zwar mal jemand die Mimes und Content-Types in E-Mails erklärt, ich bekomme es aber nicht mehr zusammen. Diese reinen Mail-Interna haben mich, im Gegensatz zur Verschlüsselung an sich, nie wirklich interessiert.

Zum Thema: Siehe Abschnitt 4.1. in diesem Artikel von der IETF: https://tools.ietf.org/id/draft-dkg-o…angling-00.html

Das sieht sehr ähnlich aus. Die Ursache wäre demnach der MTA. Vielleicht bringt es euch weiter.

Pfiats eich.

Susanne

Nur in Kürze, bin gleich wieder weg. Wenn die Version eine Snap oder ähnliches ist, könnte das schon der Grund sein.

Liabe Leit,

die Version 91 steht vor der Tür. Sie scheint mir aber noch ein wenig wacklig auf den Beinen zu sein. Ich habe im Moment weder Lust noch Zeit, mich mit dem Thunderbird zu beschäftigen. Ich mag jetzt auch nicht alle Release Notes und Bugs durchsuchen. Einzig, wenn es denn Neuerungen hinsichtlich PGP geben würde, dann würde ich mir vielleicht doch mal einen Nachmittag gönnen. In den Nachrichten hier im Forum habe ich lediglich 2 Punkte dazu gefunden:

• OpenPGP: Konfigurationsoption hinzugefügt, um die Verschlüsselung gespeicherter Entwürfe zu deaktivieren
• Werden E-Mails an BCC-Empfänger verschlüsselt, wird nun eine Warnung angezeigt, dass die Empfänger in der Schlüsselliste angezeigt werden und somit für jeden Empfänger erkenntlich sind.

Weiß jemand, ob es da noch mehr gibt, vielleicht für die 94?

Zitat von Sehvornix

Aus dem Forum ist mir erst ein Versuch bekannt, wo jemand das einmal ausprobiert hat, die id aus der local.sqlite in die prefs.js einzutragen. Nur um zu sehen, ob es überhaupt geht.

Das triffst sich gut. Fast auf die Minute.

Bin nämlich gerade mal wieder kurz online, nach evtl. zurückgelassenen Baustellen schauen usw. . Die Anleitung dazu gibt es hier: Migration lokaler Kalender in ein neues Profil

Das funktioniert. Wie ich dort schon geschrieben habe, wenn man die Möglichkeit hat, über Ex- und import zu gehen, ist das wesentlich einfacher. Wenn das nicht klappt, dann halt editieren.

Liebe Leute,

was eine Stippvisite sein sollte, hat sich aufgrund der Einschränkungen in unser aller Freizeitaktivitäten viel länger gestaltet als ich es ursprünglich vorhatte. Nun ist es aber an der Zeit, meinen Besuch hier zu beenden oder ihn doch zumindest für eine ausgedehnte Sommerpause zu unterbrechen. Mal schauen, was der Herbst für uns bereithält.

Ich erahne gerade einen Ausdruck der Freude und Erleichterung bei mindestens zwei oder drei Personen: Endlich schleicht sie sich wieder, die Spielverderberin, die streitende Goaß die!

Ja, wer Kanten hat, eckt an. Manchmal auch dort, wo es gar nicht beabsichtigt war. Vorwiegend aber, so hoffe ich, dort, wo ich es wollte: Wo sich falsche Behauptungen und Schmarrn so hoch stapeln, dass ich meine geliebten Berge schon nicht mehr sehen kann.

Wenn ich die letzten Monate im Forum Revue passieren lassen, dann fällt mir zunächst ein fast unglaublicher Zufall ein.

Die Hersteller von AV-Software müssen allesamt zur gleichen Zeit wahrhaft tiefgreifende Änderungen an ihren Produkten vorgenommen haben. Wie sonst sollte man den massiven Rückgang an notwendigen Deinstallationen erklären?

Waren es noch vor einem Jahr 2 bis 3 solcher Fälle pro Woche, so tritt das Problem nun schon seit Monaten quasi gar nicht mehr auf. Das grenzt an ein Wunder. Oder sollte es doch einen anderen Grund geben?

Ich freue mich jedenfalls ehrlich für die statistisch etwa 100 Hilfesuchenden, denen dieses unnötige Theater seitdem erspart blieb und wünsche dem Publikum, dass dieses Stück zumindest auf der Bühne dieses Forums weiterhin ernsthaft und nicht wieder als Kinderprogramm der Augsburger Puppenkiste¹ aufgeführt wird.

Dann waren da noch die hitzigen Debatten mit einem einzelnen Herrn. Oh weh ... .

Offen gesagt, hätte ich mir dazu etwas Unterstützung aus dem Forum gewünscht, nicht nur per PN oder E-Mail. Spätestens, nachdem sich zwei andere aufgrund seiner halbgaren Vorschläge den Thunderbird ziemlich verwurschtelt hatten.

Man muss die technischen Details gar nicht verstehen. Wenn jemand die Sicherheit angeblich so pedantisch ernst nimmt, aber nicht einmal seine Festplatte verschlüsselt und auch noch amateurhafte Hacks empfiehlt, die die Unterschrift einer E-Mail ungültig machen, dann bin ich mir recht sicher: Auch andere haben erkannt, dass da was nicht zusammengeht.

Sei's drum. Ich wünsche euch, dass sich immer jemand mit genug Verstand und Selbstbewusstsein findet, der sich traut, deutlich zu widersprechen, wenn versucht wird, andere zu Unsinn zu verleiten oder technisch nicht haltbare "Verschwörungstheorien" zu verbreiten.

Freuen würde ich mich, wenn jemand die Sammlung zu OpenPGP weiterführen könnte. Die war letztendlich meine Motivation, mich hier wieder anzumelden.

Mein ausdrücklicher Dank geht an Thunder, der bei meinen frecheren Postings bestimmt das eine oder andere Mal ins Holz gebissen hat, und ganz besonders an graba. Der hat's einfach verdient.

Servus derweil

Susanne

1: Nicht, dass jemand denkt, ich möchte mich über das Oehmiche Theater lustig machen. Keinesfalls. Ich schätze es sehr. Meine Kinder haben anstatt der Teletubbies und anderem Käse Jim Knopf, das Urmel und Kalle Wirsch schauen dürfen. Auch wenn das schon ganz alte Kisten waren.

Falls es weitere Änderungen und neue Features zur Implementierung geben sollte, würde ich mich freuen, wenn jemand diese hier an meiner Stelle sammeln könnte. Ich hoffe ja immer noch auf Offline-Keys und die dauerhafte Entschlüsselung.

Nachdem du inzwischen in anderen Themen geschrieben hast, hier aber nicht antwortest, schließe ich, dass du keine Fakten vorbringen kannst, die einen Fehler in meinen Erklärungen zu DNS, DoH und ODoH aufzeigen würden.

Und da selbst die von dir verlinkte Studie zu dem selben Schluss kommt wie ich, reche ich auch nicht damit, dass du noch ein belastbares Argument lieferst.

Somit bleibt es beim gegenwärtigen Stand der Spezifikationen dabei: Im Vergleich zu den bisherigen Methoden bietet ODoH ein Plus an Schutz.

Die Vorwürfe in Richtung Google, Apple und Mozilla sowie all den Leuten, die weltweit an der Spezifikation arbeiten, sind nicht haltbar. Es ist gut, dass diese Leute sich Gedanken machen, wie der Schutz der Privatsphäre verbessert werden kann. Das sollten wir uns durch fadenscheinige Thesen nicht schlechtreden lassen.

"Unbekannte Problem" - diese Fehlermeldung ist tatsächlich alles andere als hilfreich. Ich kann auf den ersten Blick keinen Fehler in deiner Vorgehensweise sehen.

Was mir spontan einfällt: Sind die beiden GMX-Konten eigenständige Konten, oder handelt es sich um Aliase? Tritt das Problem in beiden Richtungen auf oder nur von Konto A nach B aber nicht von B nach A? Steht der Wert der pref security.enterprise_roots.enabled bei beiden Rechner auf false?

Dann rück mal raus mit deinen vorliegenden Fakten. Ich habe die technischen Zusammenhänge erklärt. Sollte daran etwas nicht stimmen, dann höre ich gern zu und lasse mich eines Besseren belehren.
Bitte ohne Nebelkerzen und Ablenkungen auf andere Themen. Welche der angeführten Punkten stimmen nicht?

Jetzt hab' ich zu schnell gespeichert. Ich wollte doch noch schreiben, dass selbst die von dir verlinkte Studie zu dem Schluss kommt:

Zitat

In this paper, we perform the first implementation, deployment, and evaluation of an IETF-proposed practical privacy enhancing technique called ODoH, with the aim to provide both security and privacy guarantees for users’ DNS traffic by encrypting both the message and transport [50].

[...]

We show that the proposed protocol is feasible and a practical replacement for DoH, improving user privacy and achieving minimal performance losses. We conclude with the limitations of our study, possible ethical implications, and sketch an adoption roadmap.

Es scheint fast, als hättest du sie gar nicht gelesen.

Da irrst du dich. Den Smiley habe ich wohl ich wohl gesehen. In dieser Form, also mit Zwinkern, hätte der Satz sogar von mir stammen können. Obwohl ich plattes Windows-Bashing gar nicht mag.

Meine Frage hat aber deinem Satz zu Windows gar nichts zu tun. Wenn du magst, darfst du die Angabe auch gern durch irgendein Linux ersetzen. Mir ging es vielmehr um

Zitat von B. Mueller

Nein im Ernst - deine Sorge ist schon berechtigt. Daten, die garnicht erst vorhanden sind, können auch nicht mißbraucht werden.

Ich wollte darauf hinaus, dass die hier abgefragten Informationen völlig ungefährlich sind. Sie enthalten nichts privates. Andere Leser können damit nichts anfangen, außer dass sie besser bei der Problemlösung helfen können. Die Sorge ist hier nicht berechtigt.

• Thunderbird-Version (konkrete Versionsnummer 78.11.0 64 Bit
• Betriebssystem + Version: WIN10, 20H2
• Kontenart (POP / IMAP): IMAP
• Postfach-Anbieter (z.B. GMX): T-Online, GMX
• Eingesetzte Antiviren-Software: Defender
• Firewall (Betriebssystem-intern/Externe Software): intern
• Router-Modellbezeichnung (bei Sende-Problemen): Fritzbox 7590

@B. Mueller , ich hätte gern gewusst, welchen konkreten Missbrauch dir diese Daten meiner Windows Installation ermöglichen. Ich gebe dir gern auch noch meine gegenwärtige interne IP dazu: 192.168.178.61. (Eine ähnlich Frage dazu ist von dir bisher unbeantwortet.)

Mitleser mögen sich bitte nur nicht bange machen lassen. Schon gar nicht sollte man deshalb glauben, Mozilla würde sich aktiv daran beteiligen, Sicherheit und Privatsphäre auszuhebeln. Das sind, leider nicht zum ersten Mal, unhaltbare, schwere Vorwürfe seitens @B. Mueller.

ODoH hat Chancen, ein offizieller und offener Standard der IETF zu werden. Mit Google, Apple und Cloudflare hat es einige namhafte Unterstützer. ¹

Man kann ein paar Punkte an ODoH kritisieren, z.B. dass es immer noch nicht weit genug geht oder dass es (laut der verlinkten Studie absolut vernachlässigbare) Performance-Verluste mit sich bringt.

Eines ist aber unstrittig: Es erhöht den Schutz der Privatsphäre. Es verschlechtert ihn nicht. Siehe auch den Blog von Bruce Schneier.

Schauen wir mal auf die technischen Fakten dazu.

Normales DNS:

Derjenige, der den Nameserver betreibt, erfährt welcher Benutzer welche Adresse aufgerufen hat. Deshalb ist wichtig, sich genau zu überlegen, welchen ISP oder DNS-Provider man sich aussucht.

Da die Anfragen unverschlüsselt sind, kann hier zusätzlich auch jemand in der Mitte diese Informationen abfangen.

Namensauflösung über unverschlüsseltes DNS trifft bisher noch auf die weitaus meisten der Anwender zu.

DoH:

Die Anfragen an den Nameserver werden hier verschlüsselt. Ein Man-in-the-Middle kann nun nicht mehr so einfach mitlesen.

Nach wie vor hat aber derjenige, der den Nameserver betreibt, immer noch die Information darüber, wer welche Adresse aufgerufen hat.

ODoH:

DNS-Abfragen werden wie bei DoH verschlüsselt an den Nameserver gesendet. Allerdings nicht direkt sondern über einen zwischengeschalteten Proxy.

Der Betreiber des Proxys erfährt die IP des anfragenden Benutzers. Er kennt aber nicht die Adresse, der er aufrufen will. Diese ist mit dem Schlüssel des Nameservers verschlüsselt und kann auf dem Proxy nicht gelesen werden.

Der Betreiber des Nameservers erfährt weiterhin, welche Adresse aufgerufen werden soll. Er weiß aber nicht von wem, denn die Anfrage kommt nicht vom Anwender sondern vom Proxy.

Solange die beiden Betreiber nicht gemeinsame Sache machen, ist der Schutz also spürbar besser als nur mit DoH.

Selbstverständlich kann der Anwender sich sowohl den Proxy als auch den Nameserver frei wählen.

Die Vorwürfe, der Proxy würde einen Man-in-the-Middle-Angriff durchführen und Zensur ermöglichen, sind nicht haltbar. Denn

1. Können Schurkenstaaten und Sicherheitsbehörden das sowieso, weil sie auf jeden Punkt ihrer Infrastruktur zugreifen können. Sie können Verbindungen sogar physikalisch kappen.
   Mitlesen können sie auch, zur Not installieren sie einen Trojaner. Manche Staaten wären in der Lage, die Hintertüren direkt in das Betriebssystem zu integrieren oder sogar auch gleich in die Hardware.
2. Könnten sie über den Proxy keine ausgesuchten Webseiten sperren sondern nur bestimmte Nameserver. Sie würde dann aber nicht erfahren, welche Seite jemand versucht hat aufzurufen.
   Kapern sie wiederum den Nameserver, erfahren Sie, um welche "verbotenen Seiten" es ging, aber nicht, wer sie aufgerufen hat. Sie müssten schon die Kontrolle über beide haben. Also letztendlich über sehr viele oder alle, denn der Anwender hat ja freie Wahl.
3. Sind die bisherigen Verfahren in puncto Schutz der Privatsphäre per se schlechter und viel leichter zu "hacken".

Man darf von ODoH nicht denselben Schutzgrad erwarten, wie ihn das Tor-Netzwerk bietet. Das ist auch nicht die Intention.

Es gibt auch diskutierte und mögliche Angriffsscenarien. Dazu sollte man aber bedenken, dass solche Angriffe ohne den Schutz von DoH/DoT/ODoH noch wesentlicher einfacher zu fahren sind.

Es bleibt: Im Vergleich zu den bisherigen Methoden bietet ODoH ein Plus an Schutz. Es wäre besser als alles, was wir derzeit haben. Ich kann deshalb überhaupt nichts Schlimmes darin sehen, wenn Mozilla sich darauf vorbereitet.

Ganz im Gegenteil. Hier könnten unabhängige Sicherheitsexperten überprüfen, ob die Implementation hält, was sie verspricht. Allein deshalb würde ich die Phantasien von oben ins Reich der Fabeln und Verschwörungstheorien verweisen.

¹: Diesen Anbietern darf am sicherlich zurecht ein Eigeninteresse unterstellen. Sollte es ein Standard werden, wird er offen sein. Und Mozilla wird gewiss niemanden zwingen, einen dieser Provider zu wählen.

Zitat von B. Mueller

Ad-/Trackingblocker z. B. auf der Basis von PI-Hole haben keine Chance mehr, ausgehende Verbindungen zu unerwünschten Servern zu erkennen und zu unterbinden.

Das hat nichts mit dem Protokoll DoH zu tun sondern trifft nur zu wenn es direkt in der Anwendung, wie Firefox oder Thunderbird einstellt.

Zitat von B. Mueller

DOT an zentraler Stelle halte ich für den besseren Ansatz, sofern man dem Anwender die Wahl vertrauenswürdiger DNS-Server läßt.

DoH lässt sich ebenso zentral nutzen wie DoT, z.B. auch und gerade mit dem von dir erwähnten pi-hole. Das kann dann auch weiterhin brav seinen Job verrichten.

Ein Anwender kann derzeit wählen zwischen Verschlüsselung direkt in der Anwendung (beim Thunderbird DoH) oder zentral über den Router. Im Falle der Fritzbox wäre das dann DoT. Es gibt aber auch Router, die machen das über DoH. Es gibt beides.

Und den DNS-Server kannst du, wie oben längst erwähnt, selbstverständlich ebenfalls frei wählen.

Für das Ergebnis bleibt es egal, ob man DoH verwendet oder DoT. Nur die Art, ob zentral oder dezentral macht den Unterschied.

Du siehst, deine Punkte betreffen gar nicht den Unterschied zwischen DoT und DoH. Sie beziehen sich lediglich darauf, ob man das Verfahren zentral anwendet oder in der einzelnen Anwendung. Soweit waren wir schon in Beitrag #14.

Das Thema Tor-Netzwerk ist noch ein ganz anderes. In diese Nebelwand werde ich an dieser Stelle nicht folgen.