Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[TLS] Staatliche Root-Zertifikate, MITM?
14 views
Skip to first unread message
Marcel Logen
Nov 11, 2023, 10:45:35 AM11/11/23
to
"Hunderte Experten warnen vor staatlichen Root-Zertifikaten"
<https://heise.de/-9355165> (Update 07.11.2023)
| Die verpflichtende Einführung staatlich kontrollierter
| qualifizierter Website-Zertifikate ist Experten ein Dorn
| im Auge. Denn sie ermöglichen staatlichen Diensten das
| Abhören verschlüsselter Kommunikation durch sogenannte
| Man-in-The-Middle Attacken.
[...]
| Besonders in der Kritik stehen die Artikel 45 und 45a
| der geplanten Verordnung. Sie legen fest, dass Browser
| zukünftig sogenannte QWACs, qualifizierte Website-Authen-
| tifizierungs-Zertifikate, als vertrauenswürdig akzeptie-
| ren müssen. [...] Diesen Zertifikaten müsste jeder Bürger
| vertrauen, eine Abmeldung ist nicht vorgesehen. Darüber
| hinaus sieht der Vorschlag vor, dass Zertifikate nicht
| ohne Zustimmung der jeweiligen Regierung entfernt werden
| dürfen, um etwa einen Sicherheitsvorfall bei einer CA
| einzudämmen.
|
| Dieses Vorhaben stößt auf heftigen Widerstand der Unter-
| zeichner. Ihrer Ansicht nach sei es gefährlich, den Re-
| gierungen aller EU-Länder die Kontrolle über die krypto-
| grafischen Schlüssel für TLS (Transport Layer Security)
| zu geben. Wer diese Schlüssel kontrolliert, kann ver-
| schlüsselte Kommunikation abhören und somit das Ver-
| trauen in TLS untergraben.
[...]
| Das Pflicht-Vertrauen in staatliche Stellen ist nicht
| immer gerechtfertigt. So hat die Regierung Kasachstans
| ihren Bürgern im Jahr 2020 ein eigenes Wurzelzertifikat
| aufgedrängt, um deren verschlüsselten Datenverkehr mit-
| lesen zu können. Die Browser-Hersteller reagierten
| schnell und blockierten die unsicheren staatlichen Root-
| Zertifikate.
[...]
Hm. Ich verstehe das leider nicht ganz.
Soll das heißen, daß generell alle Aussteller von Root-
Zertifikaten jeweils 'alles' mitlesen könnten?
Das kann ich mir nicht so recht vorstellen, denn die CA
kennt ja nicht den Schlüssel für die TLS-Verbindung des
Endnutzers.
Wie soll denn so ein MITM-Angriff aussehen?
Was ist z. B. mit dem Zertifikat vom "Staat der Neder-
landen", welches bei mir im Firefox mit eingebaut ist?
Das sieht mir auch "staatlich" aus, ist aber offenbar
nicht "verpflichtend", und ich kann es vermutlich ein-
fach löschen oder deaktivieren.
Marcel
--
╭───╮ ╭────╮ ╭──╮ ╭─╮ ╭────╮ ╭──╮ ╭──╮ ..61..╭─╮
│ ╰───╯ ╭─╯ ╭─╯ ╰──╯ ╰───╮ ╰─╮ ╰──╮ │ ╰─╯ ╰──╮ ╭─╮ │ │
╭─╯ ...7..╭─╯ ╭──╯ ╭──────────╯ ╭─╯ │ ╰─╮ ╭─────╯ ╭─╯ ╰─╯ ╰──╮
─╯ ╰───╯ ╰─────────────╯ ╰────╯ ╰───────╯ ..66..│
<https://heise.de/-9355165> (Update 07.11.2023)
| Die verpflichtende Einführung staatlich kontrollierter
| qualifizierter Website-Zertifikate ist Experten ein Dorn
| im Auge. Denn sie ermöglichen staatlichen Diensten das
| Abhören verschlüsselter Kommunikation durch sogenannte
| Man-in-The-Middle Attacken.
[...]
| Besonders in der Kritik stehen die Artikel 45 und 45a
| der geplanten Verordnung. Sie legen fest, dass Browser
| zukünftig sogenannte QWACs, qualifizierte Website-Authen-
| tifizierungs-Zertifikate, als vertrauenswürdig akzeptie-
| ren müssen. [...] Diesen Zertifikaten müsste jeder Bürger
| vertrauen, eine Abmeldung ist nicht vorgesehen. Darüber
| hinaus sieht der Vorschlag vor, dass Zertifikate nicht
| ohne Zustimmung der jeweiligen Regierung entfernt werden
| dürfen, um etwa einen Sicherheitsvorfall bei einer CA
| einzudämmen.
|
| Dieses Vorhaben stößt auf heftigen Widerstand der Unter-
| zeichner. Ihrer Ansicht nach sei es gefährlich, den Re-
| gierungen aller EU-Länder die Kontrolle über die krypto-
| grafischen Schlüssel für TLS (Transport Layer Security)
| zu geben. Wer diese Schlüssel kontrolliert, kann ver-
| schlüsselte Kommunikation abhören und somit das Ver-
| trauen in TLS untergraben.
[...]
| Das Pflicht-Vertrauen in staatliche Stellen ist nicht
| immer gerechtfertigt. So hat die Regierung Kasachstans
| ihren Bürgern im Jahr 2020 ein eigenes Wurzelzertifikat
| aufgedrängt, um deren verschlüsselten Datenverkehr mit-
| lesen zu können. Die Browser-Hersteller reagierten
| schnell und blockierten die unsicheren staatlichen Root-
| Zertifikate.
[...]
Hm. Ich verstehe das leider nicht ganz.
Soll das heißen, daß generell alle Aussteller von Root-
Zertifikaten jeweils 'alles' mitlesen könnten?
Das kann ich mir nicht so recht vorstellen, denn die CA
kennt ja nicht den Schlüssel für die TLS-Verbindung des
Endnutzers.
Wie soll denn so ein MITM-Angriff aussehen?
Was ist z. B. mit dem Zertifikat vom "Staat der Neder-
landen", welches bei mir im Firefox mit eingebaut ist?
Das sieht mir auch "staatlich" aus, ist aber offenbar
nicht "verpflichtend", und ich kann es vermutlich ein-
fach löschen oder deaktivieren.
Marcel
--
╭───╮ ╭────╮ ╭──╮ ╭─╮ ╭────╮ ╭──╮ ╭──╮ ..61..╭─╮
│ ╰───╯ ╭─╯ ╭─╯ ╰──╯ ╰───╮ ╰─╮ ╰──╮ │ ╰─╯ ╰──╮ ╭─╮ │ │
╭─╯ ...7..╭─╯ ╭──╯ ╭──────────╯ ╭─╯ │ ╰─╮ ╭─────╯ ╭─╯ ╰─╯ ╰──╮
─╯ ╰───╯ ╰─────────────╯ ╰────╯ ╰───────╯ ..66..│
Peter J. Holzer
Nov 11, 2023, 2:19:30 PM11/11/23
to
On 2023-11-11 15:45, Marcel Logen <33320000...@ybtra.de> wrote:
> "Hunderte Experten warnen vor staatlichen Root-Zertifikaten"
><https://heise.de/-9355165> (Update 07.11.2023)
>
>| Die verpflichtende Einführung staatlich kontrollierter
>| qualifizierter Website-Zertifikate ist Experten ein Dorn
>| im Auge. Denn sie ermöglichen staatlichen Diensten das
>| Abhören verschlüsselter Kommunikation durch sogenannte
>| Man-in-The-Middle Attacken.
[...]
> "Hunderte Experten warnen vor staatlichen Root-Zertifikaten"
><https://heise.de/-9355165> (Update 07.11.2023)
>
>| Die verpflichtende Einführung staatlich kontrollierter
>| qualifizierter Website-Zertifikate ist Experten ein Dorn
>| im Auge. Denn sie ermöglichen staatlichen Diensten das
>| Abhören verschlüsselter Kommunikation durch sogenannte
>| Man-in-The-Middle Attacken.
[...]
>| Das Pflicht-Vertrauen in staatliche Stellen ist nicht
>| immer gerechtfertigt. So hat die Regierung Kasachstans
>| ihren Bürgern im Jahr 2020 ein eigenes Wurzelzertifikat
>| aufgedrängt, um deren verschlüsselten Datenverkehr mit-
>| lesen zu können. Die Browser-Hersteller reagierten
>| schnell und blockierten die unsicheren staatlichen Root-
>| Zertifikate.
> [...]
>
> Hm. Ich verstehe das leider nicht ganz.
>
> Soll das heißen, daß generell alle Aussteller von Root-
> Zertifikaten jeweils 'alles' mitlesen könnten?
Jein.
>| immer gerechtfertigt. So hat die Regierung Kasachstans
>| ihren Bürgern im Jahr 2020 ein eigenes Wurzelzertifikat
>| aufgedrängt, um deren verschlüsselten Datenverkehr mit-
>| lesen zu können. Die Browser-Hersteller reagierten
>| schnell und blockierten die unsicheren staatlichen Root-
>| Zertifikate.
> [...]
>
> Hm. Ich verstehe das leider nicht ganz.
>
> Soll das heißen, daß generell alle Aussteller von Root-
> Zertifikaten jeweils 'alles' mitlesen könnten?
> Das kann ich mir nicht so recht vorstellen, denn die CA
> kennt ja nicht den Schlüssel für die TLS-Verbindung des
> Endnutzers.
>
> Wie soll denn so ein MITM-Angriff aussehen?
ausstellen. Der Browser vertraut der CA, somit auch dem Zertifikat und
schlägt keinen Alarm, obwohl der Key nicht dem rechtmäßigen Eigentümer
der Website gehört (was der Browser aber nicht wissen kann).
Es gab mal eine Extension für Firefox, die gewarnt hat, wenn sich der
Public Key einer Website seit dem letzten Aufruf geändert hat. Das war
aber schon damals nicht wirklich praktikabel (etliche große Websites
hatten mehrere Keys und sogar mehrere CAs) heute ist es das noch viel
weniger.
Da der Browser außerdem allen hinterlegten CAs gleichermaßen vertraut,
kann jede CA auf Zertifikate für die Kunden anderer CAs ausstellen.
Die großen CAs publizieren ihre Zertifikate, das fällt im Normalfall
also auf. Aber wenn eine CA Zertifikate ausstellt, die sie nicht
publiziert ...
Übrigens wird diese Methode bei Proxys eingesetzt, um den Traffic
kontrollieren zu können. Das entsprechend Root-Zertifikat muss dann aber
bei allen Clients hinterlegt werden.
> Was ist z. B. mit dem Zertifikat vom "Staat der Neder-
> landen", welches bei mir im Firefox mit eingebaut ist?
>
> Das sieht mir auch "staatlich" aus,
Das ist nichts Schlechtes.
> ist aber offenbar nicht "verpflichtend", und ich kann es vermutlich
> ein- fach löschen oder deaktivieren.
Master-Zertifikat hardcoded eingebaut hat, kannst Du nicht mehr. Und
wenn das vorgeschrieben ist, werden sich die Hersteller daran halten
müssen. Das aus dem Source-Code auszubauen und den Browser danach selbst
zu kompilieren ist für die meisten User keine Option.
hp
Marco Moock
Nov 11, 2023, 2:49:49 PM11/11/23
to
Am 11.11.2023 um 16:45:32 Uhr schrieb Marcel Logen:
> Soll das heißen, daß generell alle Aussteller von Root-
> Zertifikaten jeweils 'alles' mitlesen könnten?
Nein, die können einfach nur Zertifikate ausstellen. Reicht aber für
> Soll das heißen, daß generell alle Aussteller von Root-
> Zertifikaten jeweils 'alles' mitlesen könnten?
MITM bevor die Verbindung aufgebaut wurde.
> Das kann ich mir nicht so recht vorstellen, denn die CA
> kennt ja nicht den Schlüssel für die TLS-Verbindung des
> Endnutzers.
> Wie soll denn so ein MITM-Angriff aussehen?
Zertifikat der neuen root-CA unter. Da der Browser der vertraut, fällt
es nicht auf. Über den MITM-Proxy geht es dann ganz normal zum
eigentlichen Server.
Sowas gibt es schon in einigen Firewalls um TLS mitzulesen, z.B. in der
OctoGate Schulfirewall.
Thomas Einzel
Nov 11, 2023, 6:08:36 PM11/11/23
to
Am 11.11.2023 um 20:19 schrieb Peter J. Holzer:
> On 2023-11-11 15:45, Marcel Logen <33320000...@ybtra.de> wrote:
...
> On 2023-11-11 15:45, Marcel Logen <33320000...@ybtra.de> wrote:
>> Soll das heißen, daß generell alle Aussteller von Root-
>> Zertifikaten jeweils 'alles' mitlesen könnten?
>
> Jein.
>
>
>> Das kann ich mir nicht so recht vorstellen, denn die CA
>> kennt ja nicht den Schlüssel für die TLS-Verbindung des
>> Endnutzers.
>>
>> Wie soll denn so ein MITM-Angriff aussehen?
>
> Die CA kann ein ein neues Keypaar erstellen und dafür ein Zertifikat
> ausstellen. Der Browser vertraut der CA, somit auch dem Zertifikat und
> schlägt keinen Alarm, obwohl der Key nicht dem rechtmäßigen Eigentümer
> der Website gehört (was der Browser aber nicht wissen kann).
Ich hatte mit unseren Firewall/Netzwerkadmins die u.a. auch genau so
>> Zertifikaten jeweils 'alles' mitlesen könnten?
>
> Jein.
>
>
>> Das kann ich mir nicht so recht vorstellen, denn die CA
>> kennt ja nicht den Schlüssel für die TLS-Verbindung des
>> Endnutzers.
>>
>> Wie soll denn so ein MITM-Angriff aussehen?
>
> Die CA kann ein ein neues Keypaar erstellen und dafür ein Zertifikat
> ausstellen. Der Browser vertraut der CA, somit auch dem Zertifikat und
> schlägt keinen Alarm, obwohl der Key nicht dem rechtmäßigen Eigentümer
> der Website gehört (was der Browser aber nicht wissen kann).
etwas mit eigener/n CA/s auf der ext. Firewall/WAF im Betrieb machen
sollen/müssen ein Gespräch.
Ja ist so wie du sagst, aber - nach dem was mir meine Kollegen gesagt
haben hat der Betreiber der originären Website die Möglichkeit
abzufragen bzw. zu prüfen, ob der Client mit seinem, dem korrekten
Zertifikat, verbunden ist (oder verschlüsselt, das weiß ich nicht mehr
so genau) oder nicht - und wenn nicht die Verbindung abzulehnen. Gerade
im Kontext "Home"Banking finde ich das nicht unwichtig.
--
Thomas
Stephan Seitz
Nov 11, 2023, 6:39:33 PM11/11/23
to
Thomas Einzel <usene...@einzel.de> wrote:
> Ja ist so wie du sagst, aber - nach dem was mir meine Kollegen gesagt
> haben hat der Betreiber der originären Website die Möglichkeit
> abzufragen bzw. zu prüfen, ob der Client mit seinem, dem korrekten
> Zertifikat, verbunden ist (oder verschlüsselt, das weiß ich nicht mehr
In diesem Fall ist der Client der Proxy, der den SSL-Verkehr
> Ja ist so wie du sagst, aber - nach dem was mir meine Kollegen gesagt
> haben hat der Betreiber der originären Website die Möglichkeit
> abzufragen bzw. zu prüfen, ob der Client mit seinem, dem korrekten
> Zertifikat, verbunden ist (oder verschlüsselt, das weiß ich nicht mehr
aufgebrochen hat. Ich wüßte jetzt nicht, wie das eine Webseite
überprüfen will.
> so genau) oder nicht - und wenn nicht die Verbindung abzulehnen. Gerade
> im Kontext "Home"Banking finde ich das nicht unwichtig.
mit dem richtigen Zertifikat des Servers arbeiten. Die Software hat
dafür die Daten des Serverzertifikats.
Stephan
--
| Stephan Seitz E-Mail: stse+...@rootsland.net |
| If your life was a horse, you'd have to shoot it. |
Peter J. Holzer
Nov 12, 2023, 5:19:47 AM11/12/23
to
Websites mit sehr spezifischen Anforderungen (wohl eher im B2B-Bereich)
das fordern, aber für die große Masse ist das irrelevant. (Bei Software,
die lokal installiert wird, ist das vermutlich verbreiteter.)
Das Server-Zertifikat muss auf Client-Seite überprüft werden. Ich
dachte, dass das möglicherweise mit JavaScript gehen könnte, aber das
scheint nicht der Fall zu sein. Es gibt offenbar weder eine Möglichkeit,
auf das Zertifikat der Verbindung, über die das Script bzw. die Seite
selbst geladen wurde, zuzugreifen, noch auf das Zertifikat von
Verbindungen, die man mit fetch o.ä. aufmacht. (Der Nutzen wäre ohnehin
fraglich - ein MITM könnte das Script ändern.)
hp
Marcel Mueller
Nov 12, 2023, 5:35:57 AM11/12/23
to
Am 11.11.23 um 16:45 schrieb Marcel Logen:
D.h. man braucht zusätzlich die Kontrolle über die
Netzwerk-Infrastruktur, und wenn man es ganzheitlich aufziehen will wie
in China, ordentlich Rechenleistung.
> Das kann ich mir nicht so recht vorstellen, denn die CA
> kennt ja nicht den Schlüssel für die TLS-Verbindung des
> Endnutzers.
Doch, wenn sie ihn selbst ausgestellt hat schon.
> Wie soll denn so ein MITM-Angriff aussehen?
Kompletten Netzwerkverkehr umleiten. Bei TLS Anfragen die eigene
Zertifikaten ausliefen, und danach den gesamten Verkehr von eigenen
Zertifikat auf das des Originalservers umschlüsseln. Ein wenig Heckmeck
kann es noch mit Certificate Pinning oder Transparency geben. Das kann
zwar die Attacke nicht wirklich verhindern aber möglicherweise entlarven.
> Was ist z. B. mit dem Zertifikat vom "Staat der Neder-
> landen", welches bei mir im Firefox mit eingebaut ist?
Es ist ein Zertifikat wie viele andere auch.
> Das sieht mir auch "staatlich" aus, ist aber offenbar
> nicht "verpflichtend", und ich kann es vermutlich ein-
> fach löschen oder deaktivieren.
Dann funktionieren alle Seiten, die damit signiert sind, nicht mehr.
Marcel
> Soll das heißen, daß generell alle Aussteller von Root-
> Zertifikaten jeweils 'alles' mitlesen könnten?
Nein, sie müssen auch schon noch sämtlichen Verkehr über sich umleiten.
> Zertifikaten jeweils 'alles' mitlesen könnten?
D.h. man braucht zusätzlich die Kontrolle über die
Netzwerk-Infrastruktur, und wenn man es ganzheitlich aufziehen will wie
in China, ordentlich Rechenleistung.
> Das kann ich mir nicht so recht vorstellen, denn die CA
> kennt ja nicht den Schlüssel für die TLS-Verbindung des
> Endnutzers.
> Wie soll denn so ein MITM-Angriff aussehen?
Zertifikaten ausliefen, und danach den gesamten Verkehr von eigenen
Zertifikat auf das des Originalservers umschlüsseln. Ein wenig Heckmeck
kann es noch mit Certificate Pinning oder Transparency geben. Das kann
zwar die Attacke nicht wirklich verhindern aber möglicherweise entlarven.
> Was ist z. B. mit dem Zertifikat vom "Staat der Neder-
> landen", welches bei mir im Firefox mit eingebaut ist?
> Das sieht mir auch "staatlich" aus, ist aber offenbar
> nicht "verpflichtend", und ich kann es vermutlich ein-
> fach löschen oder deaktivieren.
Marcel
Christian Weisgerber
Nov 12, 2023, 10:30:07 AM11/12/23
to
On 2023-11-11, Stephan Seitz <stse+...@rootsland.net> wrote:
> Bankensoftware (und auch andere) überprüfen auf Client-Seite, ob sie
> mit dem richtigen Zertifikat des Servers arbeiten. Die Software hat
> dafür die Daten des Serverzertifikats.
Das Stichwort dafür ist "Certificate Pinning".
> Bankensoftware (und auch andere) überprüfen auf Client-Seite, ob sie
> mit dem richtigen Zertifikat des Servers arbeiten. Die Software hat
> dafür die Daten des Serverzertifikats.
Ich habe z.B. in diversen *.git/config hier diesen Abschnitt:
[http "https://github.com/"]
pinnedpubkey = sha256//YH8+l6PDvIo1Q5o6varvw2edPgfyJFY5fHuSlsVdvdc=
Und ja, einmal im Jahr muss man das dann händisch aktualisieren.
fetchmail(1) z.B. unterstützt sowas mit der Option sslfingerprint.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Marcel Logen
Nov 12, 2023, 11:12:11 AM11/12/23
to
Christian Weisgerber in de.comp.security.misc:
>Ich habe z.B. in diversen *.git/config hier diesen Abschnitt:
>
>[http "https://github.com/"]
> pinnedpubkey = sha256//YH8+l6PDvIo1Q5o6varvw2edPgfyJFY5fHuSlsVdvdc=
Das muß ich jetzt mal nachrechnen (aus Neugier ;-):
| user15@o15:/tmp$ openssl x509 -pubkey -in github-com.pem -noout -out pubkey-github.pem
| user15@o15:/tmp$ sed -e '/^-/d' pubkey-github.pem > pubkey-github.b64
| user15@o15:/tmp$ openssl enc -base64 -d -in pubkey-github.b64 -out pubkey-github.bin
| user15@o15:/tmp$ openssl dgst -sha256 -binary pubkey-github.bin | openssl enc -base64 -e
| YH8+l6PDvIo1Q5o6varvw2edPgfyJFY5fHuSlsVdvdc=
| user15@o15:/tmp$
Dann dienen die beiden "/" nach dem "sha256" also der Trennung.
(Ich hätte da jetzt eher einen Doppelpunkt erwartet.)
Marcel
--
╰─╮ ╭─╮ ╭───╮ ╭─────────╮ ╭───╮ ╭─────────╮ ..67..
╰─╯ ╰───╮ ╭─╯ │ ╰──────╮ ╰───╮ │ ╰──╯ ╰─╮..67..
╰───╯ ╭──╯ ╭─╮ ╭──╮ ╭─╯ ╭───╯ │ ╭───────────────╯..67..
..12..╰─────╯ ╰──╯ ╰─╯ ╰───────╯ ╰──────────────────────
>Ich habe z.B. in diversen *.git/config hier diesen Abschnitt:
>
>[http "https://github.com/"]
> pinnedpubkey = sha256//YH8+l6PDvIo1Q5o6varvw2edPgfyJFY5fHuSlsVdvdc=
| user15@o15:/tmp$ openssl x509 -pubkey -in github-com.pem -noout -out pubkey-github.pem
| user15@o15:/tmp$ sed -e '/^-/d' pubkey-github.pem > pubkey-github.b64
| user15@o15:/tmp$ openssl enc -base64 -d -in pubkey-github.b64 -out pubkey-github.bin
| user15@o15:/tmp$ openssl dgst -sha256 -binary pubkey-github.bin | openssl enc -base64 -e
| YH8+l6PDvIo1Q5o6varvw2edPgfyJFY5fHuSlsVdvdc=
| user15@o15:/tmp$
Dann dienen die beiden "/" nach dem "sha256" also der Trennung.
(Ich hätte da jetzt eher einen Doppelpunkt erwartet.)
Marcel
--
╰─╮ ╭─╮ ╭───╮ ╭─────────╮ ╭───╮ ╭─────────╮ ..67..
╰─╯ ╰───╮ ╭─╯ │ ╰──────╮ ╰───╮ │ ╰──╯ ╰─╮..67..
╰───╯ ╭──╯ ╭─╮ ╭──╮ ╭─╯ ╭───╯ │ ╭───────────────╯..67..
..12..╰─────╯ ╰──╯ ╰─╯ ╰───────╯ ╰──────────────────────
Stephan Seitz
Nov 12, 2023, 5:03:50 PM11/12/23
to
Ja, dafür gab es in der guten alten Zeit für Firefox ein Addon. Es gab
sogar ein Addon, das DNSSEC und DANE für eine Seite überprüft hat.
Leider mit der neuen beschissenen API alles weg.
> Ich habe z.B. in diversen *.git/config hier diesen Abschnitt:
Fein, und wie machst du das im Browser?
> Und ja, einmal im Jahr muss man das dann händisch aktualisieren.
Dann ist das schon ein langes Zertifikat. Bei Letsencrypt kannst du
das nach 60 Tagen anpassen.
> fetchmail(1) z.B. unterstützt sowas mit der Option sslfingerprint.
Was einer der Gründe ist, warum ich das nicht mehr drin habe.
sogar ein Addon, das DNSSEC und DANE für eine Seite überprüft hat.
Leider mit der neuen beschissenen API alles weg.
> Ich habe z.B. in diversen *.git/config hier diesen Abschnitt:
> Und ja, einmal im Jahr muss man das dann händisch aktualisieren.
das nach 60 Tagen anpassen.
> fetchmail(1) z.B. unterstützt sowas mit der Option sslfingerprint.
Arno Welzel
Nov 18, 2023, 4:04:12 PM11/18/23
to
Marcel Logen, 2023-11-11 16:45:
> "Hunderte Experten warnen vor staatlichen Root-Zertifikaten"
> <https://heise.de/-9355165> (Update 07.11.2023)
Ein Root-Zertifikat wird bei TLS erstmal nur dafür benutzt, andere
Zertifikate zu *signieren*.
> Das kann ich mir nicht so recht vorstellen, denn die CA
> kennt ja nicht den Schlüssel für die TLS-Verbindung des
> Endnutzers.
Korrekt.
Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
dass staatliche Stellen einfach anordnen könnte, im Rahmen von
Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
lassen und gleichzeitig selber Proxy betreiben, der ein dafür
ausgestelltes TLS-Zertifikat hat, was nicht vom eigentlichen Anbieter
stammt, aber mit dem staatlichen Root-Zertifikat signiert ist.
Also das, was in manchen Firmen durch "Sicherheitslösungen" auch gemacht
wird und nur deshalb funktioniert, weil auf allen Arbeitsplätzen das
Root-Zertifikat der "Sicherheitslösung" per Gruppenrichtlinie o.Ä.
eingerichtet ist.
--
Arno Welzel
https://arnowelzel.de
> "Hunderte Experten warnen vor staatlichen Root-Zertifikaten"
> <https://heise.de/-9355165> (Update 07.11.2023)
[...]
> Hm. Ich verstehe das leider nicht ganz.
>
> Soll das heißen, daß generell alle Aussteller von Root-
> Zertifikaten jeweils 'alles' mitlesen könnten?
Nein.
> Hm. Ich verstehe das leider nicht ganz.
>
> Soll das heißen, daß generell alle Aussteller von Root-
> Zertifikaten jeweils 'alles' mitlesen könnten?
Ein Root-Zertifikat wird bei TLS erstmal nur dafür benutzt, andere
Zertifikate zu *signieren*.
> Das kann ich mir nicht so recht vorstellen, denn die CA
> kennt ja nicht den Schlüssel für die TLS-Verbindung des
> Endnutzers.
Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
dass staatliche Stellen einfach anordnen könnte, im Rahmen von
Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
lassen und gleichzeitig selber Proxy betreiben, der ein dafür
ausgestelltes TLS-Zertifikat hat, was nicht vom eigentlichen Anbieter
stammt, aber mit dem staatlichen Root-Zertifikat signiert ist.
Also das, was in manchen Firmen durch "Sicherheitslösungen" auch gemacht
wird und nur deshalb funktioniert, weil auf allen Arbeitsplätzen das
Root-Zertifikat der "Sicherheitslösung" per Gruppenrichtlinie o.Ä.
eingerichtet ist.
--
Arno Welzel
https://arnowelzel.de
Wendelin Uez
Nov 19, 2023, 7:16:10 AM11/19/23
to
> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
> lassen
Das wäre aber doch für den Domaininhaber leicht erkenn- und nachweisbar?
> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
> lassen
Und dessen Klientel müsste sich die IP-Adresse ja auch nicht unbedingt per
DNS besorgen, sondern könnte die richtige selbst einsetzen?
Peter J. Holzer
Nov 19, 2023, 7:47:51 AM11/19/23
to
On 2023-11-19 11:59, Wendelin Uez <wu...@online.de> wrote:
>> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
>> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
>> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
>> lassen
>
> Das wäre aber doch für den Domaininhaber leicht erkenn- und nachweisbar?
Das kommt darauf an, wer überwacht werden soll.
>> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
>> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
>> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
>> lassen
>
> Das wäre aber doch für den Domaininhaber leicht erkenn- und nachweisbar?
Wenn der der gesamte Traffic einer Website überwacht werden soll:
Ja, das wäre sehr auffällig. Nicht nur würde sich die IP-Adresse des
Servers ändern, sondern auch die IP-Adressen (und damit zusammenhängend
die Geo-Daten) der Clients. Das sollte mit entsprechenden
Monitoring-Maßnahmen leicht erkennbar sein.
Aber wenn nur ein einzelner User (oder eine kleine Gruppe) überwacht
werden soll, dann bekommt nur dieser eine User die IP-Adresse des
MITM-Servers (samt Zertifikat), der Rest des Internets (inkl. Betreiber)
ist nicht betroffen.
> Und dessen Klientel müsste sich die IP-Adresse ja auch nicht unbedingt per
> DNS besorgen, sondern könnte die richtige selbst einsetzen?
Allgemeinen aber nicht.
hp
Marco Moock
Nov 19, 2023, 11:14:43 AM11/19/23
to
Am 18.11.2023 um 22:04:08 Uhr schrieb Arno Welzel:
> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
> lassen
Die besteht nicht nur, das ist längst Standard - teste es mal mit
> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
> lassen
de.rt.com bei den Resolvern von Telekom & Co. Die werden per
EU-Verordnung dazu gezwungen.
Marco Moock
Nov 19, 2023, 11:15:46 AM11/19/23
to
Am 19.11.2023 um 12:59:14 Uhr schrieb Wendelin Uez:
> > Bei den geplanten "Staats-Zertifikaten" besteht aber die
> > Befürchtung, dass staatliche Stellen einfach anordnen könnte, im
> > Rahmen von Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS
> > ändern zu lassen
>
> Das wäre aber doch für den Domaininhaber leicht erkenn- und
> nachweisbar?
Erkennbar nur dann, wenn das aufm autoritativen eigenen DNS passiert.
> > Bei den geplanten "Staats-Zertifikaten" besteht aber die
> > Befürchtung, dass staatliche Stellen einfach anordnen könnte, im
> > Rahmen von Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS
> > ändern zu lassen
>
> Das wäre aber doch für den Domaininhaber leicht erkenn- und
> nachweisbar?
Die aktuelle EU-DNS-Spoofingaktion macht das aber beim Resolver des
Providers. Das ist nur dann erkennbar, wenn man den abfragt.
> Und dessen Klientel müsste sich die IP-Adresse ja auch nicht
> unbedingt per DNS besorgen, sondern könnte die richtige selbst
> einsetzen?
Jörg Lorenz
Nov 19, 2023, 11:57:51 AM11/19/23
to
IP-Adresse über einen Proxy von Apple.
Funktioniert auch auf meinem Firefox mit DNS over https mit folgendem
(EU) DNS-Server: "https://unicast.uncensoreddns.org/dns-query"
anstandslos. DNS-Blocking ist Kinderkram.
Aber sind wir mal ehrlich: So einen Putin-Propagandascheiss will eh
keiner sehen. Ist ja *zum Kotzen*!
--
"Alea iacta est." (Julius Caesar 10. Januar 49 v. Chr.)
Marco Moock
Nov 19, 2023, 12:23:53 PM11/19/23
to
Am 19.11.2023 um 17:57:48 Uhr schrieb Jörg Lorenz:
> Geht hier einwandfrei.
Ist ja auch nicht EU. Aber auch in der EU macht nicht jeder Provider
bei dem Mist mit.
> DNS-Blocking ist Kinderkram.
Für dich ja.
Für den ONU nicht.
Ich habe den Falls aber hier nur genannt, um darauf aufmerksam zu
machen, dass sowas hier schon passiert.
Mit passenden CAs kann man da noch viel mehr staatlichen Unfug
anstellen.
> Aber sind wir mal ehrlich: So einen Putin-Propagandascheiss will eh
> keiner sehen. Ist ja *zum Kotzen*!
Ist aber meines Erachtens Sache des Nutzers und nicht des Staates und
erinnert mich halt an die Zeit "Feindsender hören verboten", die ich
erfreulicherweise noch nicht erleben musste und auf die ich gerne
verzichten kann.
Ebenso auf staatliche Zwangs-root-CAs für MITM-Attacken.
> Geht hier einwandfrei.
Ist ja auch nicht EU. Aber auch in der EU macht nicht jeder Provider
bei dem Mist mit.
> DNS-Blocking ist Kinderkram.
Für dich ja.
Für den ONU nicht.
Ich habe den Falls aber hier nur genannt, um darauf aufmerksam zu
machen, dass sowas hier schon passiert.
Mit passenden CAs kann man da noch viel mehr staatlichen Unfug
anstellen.
> Aber sind wir mal ehrlich: So einen Putin-Propagandascheiss will eh
> keiner sehen. Ist ja *zum Kotzen*!
erinnert mich halt an die Zeit "Feindsender hören verboten", die ich
erfreulicherweise noch nicht erleben musste und auf die ich gerne
verzichten kann.
Ebenso auf staatliche Zwangs-root-CAs für MITM-Attacken.
Paul Muster
Nov 19, 2023, 12:42:04 PM11/19/23
to
On 19.11.23 17:57, Jörg Lorenz wrote:
> On 19.11.23 17:14, Marco Moock wrote:
>> Am 18.11.2023 um 22:04:08 Uhr schrieb Arno Welzel:
>>> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
>>> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
>>> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
>>> lassen
>>
>> Die besteht nicht nur, das ist längst Standard - teste es mal mit
>> de.rt.com bei den Resolvern von Telekom & Co. Die werden per
>> EU-Verordnung dazu gezwungen.
>
> Geht hier einwandfrei.
Du bist in der Schweiz, richtig? Oh, Wunder, dass dort EU-Regeln nicht
> On 19.11.23 17:14, Marco Moock wrote:
>> Am 18.11.2023 um 22:04:08 Uhr schrieb Arno Welzel:
>>> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
>>> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
>>> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
>>> lassen
>>
>> Die besteht nicht nur, das ist längst Standard - teste es mal mit
>> de.rt.com bei den Resolvern von Telekom & Co. Die werden per
>> EU-Verordnung dazu gezwungen.
>
> Geht hier einwandfrei.
greifen.
mfG Paul
Jörg Lorenz
Nov 19, 2023, 2:52:50 PM11/19/23
to
Am 19.11.23 um 18:23 schrieb Paul Muster:
Du hast wahnsinnig viel Ahnung.
Bei uns werden Glückspielseiten auf diese Weise versucht, durch den
Staat zu blockieren: Kinderkram.
Meine skizzierte Übungsanlage überwindet die genau gleich.
DNS-Manipulationen kann man ganz leicht umgehen und sonst gäbe es ja
noch TOR.
--
"Roma locuta, causa finita" (Augustinus)
Bei uns werden Glückspielseiten auf diese Weise versucht, durch den
Staat zu blockieren: Kinderkram.
Meine skizzierte Übungsanlage überwindet die genau gleich.
DNS-Manipulationen kann man ganz leicht umgehen und sonst gäbe es ja
noch TOR.
--
"Roma locuta, causa finita" (Augustinus)
Jörg Lorenz
Nov 19, 2023, 2:55:22 PM11/19/23
to
Am 19.11.23 um 18:23 schrieb Marco Moock:
übrigens überhaupt nichts mit der Schweiz zu tun.
> Ich habe den Falls aber hier nur genannt, um darauf aufmerksam zu
> machen, dass sowas hier schon passiert.
*Das* ist das eigentlich Diskussionswürdige. Meine Argumente haben
> machen, dass sowas hier schon passiert.
übrigens überhaupt nichts mit der Schweiz zu tun.
Arno Welzel
Nov 22, 2023, 4:14:24 AM11/22/23
to
Wendelin Uez, 2023-11-19 12:59:
> Arno Welzel:
> Und dessen Klientel müsste sich die IP-Adresse ja auch nicht unbedingt per
> DNS besorgen, sondern könnte die richtige selbst einsetzen?
Und woher soll die Klientel das dann wissen, wenn der Anbieter der
Website das nicht selber so mitteilt?
Und eine lokale hosts-Datei für öffentliche Websites ist in der Regel
keine gute Idee. Die Existenz von DNS ist ja durchaus sinnvoll.
Besser wäre die Nutzung von Nameservern, die nicht durch staatliche
Stellen kontrolliert werden, wo entsprechende Zertifikate verlangt werden.
> Arno Welzel:
>
>> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
>> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
>> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
>> lassen
>
> Das wäre aber doch für den Domaininhaber leicht erkenn- und nachweisbar?
Ja - und? Was soll er dann mit der Information anfangen?
>> Bei den geplanten "Staats-Zertifikaten" besteht aber die Befürchtung,
>> dass staatliche Stellen einfach anordnen könnte, im Rahmen von
>> Überwachungsmaßnahmen die IP-Adresse einer Domain im DNS ändern zu
>> lassen
>
> Das wäre aber doch für den Domaininhaber leicht erkenn- und nachweisbar?
> Und dessen Klientel müsste sich die IP-Adresse ja auch nicht unbedingt per
> DNS besorgen, sondern könnte die richtige selbst einsetzen?
Website das nicht selber so mitteilt?
Und eine lokale hosts-Datei für öffentliche Websites ist in der Regel
keine gute Idee. Die Existenz von DNS ist ja durchaus sinnvoll.
Besser wäre die Nutzung von Nameservern, die nicht durch staatliche
Stellen kontrolliert werden, wo entsprechende Zertifikate verlangt werden.
Marco Moock
Nov 22, 2023, 4:21:01 AM11/22/23
to
Am 22.11.2023 um 10:14:21 Uhr schrieb Arno Welzel:
> Besser wäre die Nutzung von Nameservern, die nicht durch staatliche
> Stellen kontrolliert werden, wo entsprechende Zertifikate verlangt
> werden.
Dagegen arbeitet die EU ja auch schon:
> Besser wäre die Nutzung von Nameservern, die nicht durch staatliche
> Stellen kontrolliert werden, wo entsprechende Zertifikate verlangt
> werden.
https://netzpolitik.org/2022/dns4eu-eu-will-eigenen-dns-server-mit-filterlisten-und-netzsperren/
Arno Welzel
Nov 22, 2023, 4:25:33 AM11/22/23
to
Marco Moock, 2023-11-19 17:14:
Du musst schon *vollständig* lesen und zitieren. Staatliche Zensur
verbotener Medien "DNS-Sperren" bei Providern sind hinlänglich bekannt.
Hier geht es aber nicht um *sperren* sondern *überwachen*.
Deswegen empfehle ich generell für DNS die Nutzung von Diensten wie
<https://blog.uncensoreddns.org/> und nicht die Resolver des jeweiligen
ISPs.
verbotener Medien "DNS-Sperren" bei Providern sind hinlänglich bekannt.
Hier geht es aber nicht um *sperren* sondern *überwachen*.
Deswegen empfehle ich generell für DNS die Nutzung von Diensten wie
<https://blog.uncensoreddns.org/> und nicht die Resolver des jeweiligen
ISPs.
Arno Welzel
Nov 22, 2023, 4:27:35 AM11/22/23
to
Marco Moock, 2023-11-19 18:23:
> Am 19.11.2023 um 17:57:48 Uhr schrieb Jörg Lorenz:
>
>> Geht hier einwandfrei.
>
> Ist ja auch nicht EU. Aber auch in der EU macht nicht jeder Provider
> bei dem Mist mit.
>
>> DNS-Blocking ist Kinderkram.
>
> Für dich ja.
> Für den ONU nicht.
Auch ONU kann im Router einen anderen DNS eintragen:
<https://www.computerbild.de/artikel/cb-Tipps-DSL-WLAN-DNS-Server-in-der-FritzBox-aendern-31507427.html>
Und wenn ONU noch nach "zensurfreie DNS" sucht, findet er auch passende
Angebote dazu.
> Am 19.11.2023 um 17:57:48 Uhr schrieb Jörg Lorenz:
>
>> Geht hier einwandfrei.
>
> Ist ja auch nicht EU. Aber auch in der EU macht nicht jeder Provider
> bei dem Mist mit.
>
>> DNS-Blocking ist Kinderkram.
>
> Für dich ja.
> Für den ONU nicht.
<https://www.computerbild.de/artikel/cb-Tipps-DSL-WLAN-DNS-Server-in-der-FritzBox-aendern-31507427.html>
Und wenn ONU noch nach "zensurfreie DNS" sucht, findet er auch passende
Angebote dazu.
Arno Welzel
Nov 22, 2023, 4:29:59 AM11/22/23
to
Marco Moock, 2023-11-22 10:20:
Wogegen? Dass ich per VPN zu meinem eigenen Server verbinde, der dann
für mich dann als Resolver mit zensurfreiem DNS arbeitet?
Oder sollen VPNs dann auch verboten werden?
für mich dann als Resolver mit zensurfreiem DNS arbeitet?
Oder sollen VPNs dann auch verboten werden?
Jörg Lorenz
Nov 22, 2023, 4:42:01 AM11/22/23
to
hätte das sicher gerne. Und um einen solchen DNS-Resover zu umgehen,
braucht man nicht mal ein VPN.
Jörg Lorenz
Nov 22, 2023, 4:47:35 AM11/22/23
to
https://dns.digitale-gesellschaft.ch/dns-query
DNS over HTTPS ist schon mal eine gute Idee. Oder allenfalls wie Apple
das macht, einen Proxy benutzen.
Marco Moock
Nov 22, 2023, 4:49:57 AM11/22/23
to
Am 22.11.2023 um 10:29:56 Uhr schrieb Arno Welzel:
> Wogegen? Dass ich per VPN zu meinem eigenen Server verbinde, der dann
> für mich dann als Resolver mit zensurfreiem DNS arbeitet?
>
> Oder sollen VPNs dann auch verboten werden?
Das wird möglicherweise kommen, wenn deine obige Idee in der Bevölkerung
> Wogegen? Dass ich per VPN zu meinem eigenen Server verbinde, der dann
> für mich dann als Resolver mit zensurfreiem DNS arbeitet?
>
> Oder sollen VPNs dann auch verboten werden?
weit verbreitet ist.
Arno Welzel
Nov 22, 2023, 9:29:52 AM11/22/23
to
Jörg Lorenz, 2023-11-22 10:41:
Ach so - nur ein weiterer Nameserver. Ich dachte, es geht darum, dass
die Nutzung nicht zensierter Nameserver verhindert werden soll.
die Nutzung nicht zensierter Nameserver verhindert werden soll.
Arno Welzel
Nov 22, 2023, 9:31:41 AM11/22/23
to
Marco Moock, 2023-11-22 10:49:
Vorher ist erstmal weit verbreitet, überhaupt zensurfreie Server zu
nutzen. Um das zu verhindern, müssten die Provider DNS und DoT
blockieren und nur zu ihren eigenen Resolvern erlauben. Aber nachdem man
das schon bisher nicht gemacht hat, um "DNS-Sperren" auch wirksam
durchsetzen zu können, wird das wohl so schnell nicht passieren.
nutzen. Um das zu verhindern, müssten die Provider DNS und DoT
blockieren und nur zu ihren eigenen Resolvern erlauben. Aber nachdem man
das schon bisher nicht gemacht hat, um "DNS-Sperren" auch wirksam
durchsetzen zu können, wird das wohl so schnell nicht passieren.
Christian Weisgerber
Nov 22, 2023, 10:30:05 AM11/22/23
to
On 2023-11-22, Arno Welzel <use...@arnowelzel.de> wrote:
> Deswegen empfehle ich generell für DNS die Nutzung von Diensten wie
><https://blog.uncensoreddns.org/> und nicht die Resolver des jeweiligen
> ISPs.
Sinnvollerweise hat man einfach seinen eigenen Resolver. Unbound
> Deswegen empfehle ich generell für DNS die Nutzung von Diensten wie
><https://blog.uncensoreddns.org/> und nicht die Resolver des jeweiligen
> ISPs.
laufen zu lassen ist auf jeder unixoiden Büchse minimaler Aufwand.
Und bieten die ganzen Fritzboxen u.ä. sowas nicht an?
Marco Moock
Nov 22, 2023, 11:51:46 AM11/22/23
to
Am 22.11.2023 um 15:10:36 Uhr schrieb Christian Weisgerber:
> Sinnvollerweise hat man einfach seinen eigenen Resolver. Unbound
> laufen zu lassen ist auf jeder unixoiden Büchse minimaler Aufwand.
BIND9 auch.
> Sinnvollerweise hat man einfach seinen eigenen Resolver. Unbound
> laufen zu lassen ist auf jeder unixoiden Büchse minimaler Aufwand.
> Und bieten die ganzen Fritzboxen u.ä. sowas nicht an?
könnte man natürlich auch BIND o.ä. laufen lassen.
Jörg Lorenz
Nov 22, 2023, 12:04:34 PM11/22/23
to
Am 22.11.23 um 15:29 schrieb Arno Welzel:
Ich dachte die Funktionsweise von DNS over HTTPS sei bekannt.
Jörg Lorenz
Nov 22, 2023, 12:08:16 PM11/22/23
to
Am 22.11.23 um 10:25 schrieb Arno Welzel:
des ISPs mit Weisungsbefugnis ist. Könnte man für die Telekom wohl auch
anwenden.
> Deswegen empfehle ich generell für DNS die Nutzung von Diensten wie
> <https://blog.uncensoreddns.org/> und nicht die Resolver des jeweiligen
> ISPs.
Vor allem wenn, wie in der Schweiz, der Bund auch noch Mehrheitsaktionär
> <https://blog.uncensoreddns.org/> und nicht die Resolver des jeweiligen
> ISPs.
des ISPs mit Weisungsbefugnis ist. Könnte man für die Telekom wohl auch
anwenden.
Marco Moock
Nov 22, 2023, 3:10:53 PM11/22/23
to
Am 22.11.2023 um 18:04:32 Uhr schrieb Jörg Lorenz:
> Am 22.11.23 um 15:29 schrieb Arno Welzel:
> Am 22.11.23 um 15:29 schrieb Arno Welzel:
> > Ach so - nur ein weiterer Nameserver. Ich dachte, es geht darum,
> > dass die Nutzung nicht zensierter Nameserver verhindert werden
> > soll.
>
> Ich dachte die Funktionsweise von DNS over HTTPS sei bekannt.
Diese Verbindungen können dann ja wunderbar aufgebrochen und
> > dass die Nutzung nicht zensierter Nameserver verhindert werden
> > soll.
>
> Ich dachte die Funktionsweise von DNS over HTTPS sei bekannt.
manipuliert werden, wenn die TLS-Sache eingeführt wird.
Stefan Kanthak
Nov 22, 2023, 6:27:00 PM11/22/23
to
"Marco Moock" <mm+s...@dorfdsl.de> schrieb:
> Am 22.11.2023 um 18:04:32 Uhr schrieb Jörg Lorenz:
>
>> Am 22.11.23 um 15:29 schrieb Arno Welzel:
>>> Ach so - nur ein weiterer Nameserver. Ich dachte, es geht darum,
>>> dass die Nutzung nicht zensierter Nameserver verhindert werden
>>> soll.
>>
>> Ich dachte die Funktionsweise von DNS over HTTPS sei bekannt.
Dein Vorposter demonstriert wie ueblich seine strunzende Dummheit:
auch ueber HTTPS oder TLS angesprochene DNS-Server koennen beliebig
"falsche" Antworten geben, bzw. deren Betreiber (vom Gesetzgeber
oder von Gerichten) dazu gezwungen werden.
> Diese Verbindungen können dann ja wunderbar aufgebrochen und
> manipuliert werden, wenn die TLS-Sache eingeführt wird.
Genau wie bei DNS over TLS.
Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>
> Am 22.11.2023 um 18:04:32 Uhr schrieb Jörg Lorenz:
>
>> Am 22.11.23 um 15:29 schrieb Arno Welzel:
>>> Ach so - nur ein weiterer Nameserver. Ich dachte, es geht darum,
>>> dass die Nutzung nicht zensierter Nameserver verhindert werden
>>> soll.
>>
>> Ich dachte die Funktionsweise von DNS over HTTPS sei bekannt.
auch ueber HTTPS oder TLS angesprochene DNS-Server koennen beliebig
"falsche" Antworten geben, bzw. deren Betreiber (vom Gesetzgeber
oder von Gerichten) dazu gezwungen werden.
> Diese Verbindungen können dann ja wunderbar aufgebrochen und
> manipuliert werden, wenn die TLS-Sache eingeführt wird.
Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>
Marco Moock
Nov 23, 2023, 8:52:56 AM11/23/23
to
Am 23.11.2023 schrieb christian...@soemtron.de (Christian
@Soemtron):
> Also ich habe eine Fritzbox und minimalen Aufwand würde ich auch
> betreiben. Wie sieht dieser genau aus? Ich befürchte ja, daß
> "minimal" in dem Zusammenhang eher nichtssagendes Füllwort ist, da
> ungenannte weitere Vorbedingungen existieren und das Ganze ohne diese
> in stunden-/tagelange Frickelei mündet.
Nach meinem Kenntnisstand hat die FB OOTB keinen rekursiven
DNS-Resolver, sondern nur einen Stub-Resovler, der alles an einen
richtigen Resolver (den man manuell einträgt oder per IPV6-RA, IPCP,
DHJCPv4 oder DHCPv6 vom ISP bekommt) weiterreicht.
Es reicht, wenn du da einen einträgst, der eben keine Falschantworten
(DNS-Sperre) liefert.
Es gibt freie, die jeder verwende kann ohne Anmeldung, z.B. von
digitalcourage oder vom CCC (IIRC ist der aber offline, habe ich lange
nicht geprüft).
Ich betreibe meinen eigenen (ist nicht schwer, man muss es aber grob
verstehen). Wenn den jemand nutzen will, kann ich da die Adressbereiche
freigeben (es ist kein offener Resolver und soll keiner werden).
@Soemtron):
> Also ich habe eine Fritzbox und minimalen Aufwand würde ich auch
> betreiben. Wie sieht dieser genau aus? Ich befürchte ja, daß
> "minimal" in dem Zusammenhang eher nichtssagendes Füllwort ist, da
> ungenannte weitere Vorbedingungen existieren und das Ganze ohne diese
> in stunden-/tagelange Frickelei mündet.
Nach meinem Kenntnisstand hat die FB OOTB keinen rekursiven
DNS-Resolver, sondern nur einen Stub-Resovler, der alles an einen
richtigen Resolver (den man manuell einträgt oder per IPV6-RA, IPCP,
DHJCPv4 oder DHCPv6 vom ISP bekommt) weiterreicht.
Es reicht, wenn du da einen einträgst, der eben keine Falschantworten
(DNS-Sperre) liefert.
Es gibt freie, die jeder verwende kann ohne Anmeldung, z.B. von
digitalcourage oder vom CCC (IIRC ist der aber offline, habe ich lange
nicht geprüft).
Ich betreibe meinen eigenen (ist nicht schwer, man muss es aber grob
verstehen). Wenn den jemand nutzen will, kann ich da die Adressbereiche
freigeben (es ist kein offener Resolver und soll keiner werden).
Andreas M. Kirchwitz
Nov 23, 2023, 8:09:02 PM11/23/23
to
Marco Moock <mm+u...@dorfdsl.de> wrote:
> [DNS-Server mit/ohne Sperren]
das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
Auf Clients habe ich teilweise wenig Einfluss, was die im Detail
für Protokolle verwenden. Dort trägt man eine oder zwei blanke
IP-Adressen ein, und dann muss die Sache einfach laufen.
Seinen eigenen Resolver zu betreiben, klingt so leicht, doch der
ist oft nicht ohne weiteres nutzbar.
Am Ende ist man doch meist auf fremde Betreiber angewiesen, die
ihren Resolver für alle Welt geöffnet haben und tapfer mit den
Abmahnungen, Klagen usw. leben, die sie ständig bekommen.
Oder habe ich was übersehen? ... Andreas
> [DNS-Server mit/ohne Sperren]
> Ich betreibe meinen eigenen (ist nicht schwer, man muss es aber grob
> verstehen). Wenn den jemand nutzen will, kann ich da die Adressbereiche
> freigeben (es ist kein offener Resolver und soll keiner werden).
Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
> verstehen). Wenn den jemand nutzen will, kann ich da die Adressbereiche
> freigeben (es ist kein offener Resolver und soll keiner werden).
das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
Auf Clients habe ich teilweise wenig Einfluss, was die im Detail
für Protokolle verwenden. Dort trägt man eine oder zwei blanke
IP-Adressen ein, und dann muss die Sache einfach laufen.
Seinen eigenen Resolver zu betreiben, klingt so leicht, doch der
ist oft nicht ohne weiteres nutzbar.
Am Ende ist man doch meist auf fremde Betreiber angewiesen, die
ihren Resolver für alle Welt geöffnet haben und tapfer mit den
Abmahnungen, Klagen usw. leben, die sie ständig bekommen.
Oder habe ich was übersehen? ... Andreas
Marco Moock
Nov 24, 2023, 3:09:10 AM11/24/23
to
Am 24.11.2023 um 01:08:59 Uhr schrieb Andreas M. Kirchwitz:
> Marco Moock <mm+u...@dorfdsl.de> wrote:
>
> > [DNS-Server mit/ohne Sperren]
> > Ich betreibe meinen eigenen (ist nicht schwer, man muss es aber grob
> > verstehen). Wenn den jemand nutzen will, kann ich da die
> > Adressbereiche freigeben (es ist kein offener Resolver und soll
> > keiner werden).
>
> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
> Auf Clients habe ich teilweise wenig Einfluss, was die im Detail
> für Protokolle verwenden. Dort trägt man eine oder zwei blanke
> IP-Adressen ein, und dann muss die Sache einfach laufen.
Bei DNS over TLS (oder HTTPS) sollte es ja eigentlich möglich sein, ein
> Marco Moock <mm+u...@dorfdsl.de> wrote:
>
> > [DNS-Server mit/ohne Sperren]
> > Ich betreibe meinen eigenen (ist nicht schwer, man muss es aber grob
> > verstehen). Wenn den jemand nutzen will, kann ich da die
> > Adressbereiche freigeben (es ist kein offener Resolver und soll
> > keiner werden).
>
> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
> Auf Clients habe ich teilweise wenig Einfluss, was die im Detail
> für Protokolle verwenden. Dort trägt man eine oder zwei blanke
> IP-Adressen ein, und dann muss die Sache einfach laufen.
Zertifikat zur Authentifizierung zu nutzen, sodass die IP egal ist. Ob
Clients und Server das können weiß ich nicht.
> Seinen eigenen Resolver zu betreiben, klingt so leicht, doch der
> ist oft nicht ohne weiteres nutzbar.
der kann aber für Reflection-Attacken genutzt werden.
Eine Möglichkeit: Auf eine IPv6 mittendrin legen, die wird nur schwer
gefunden.
> Am Ende ist man doch meist auf fremde Betreiber angewiesen, die
> ihren Resolver für alle Welt geöffnet haben und tapfer mit den
> Abmahnungen, Klagen usw. leben, die sie ständig bekommen.
Ausland, sodass sich hier keiner drum kümmert, wenn viele Leute den
nutzen, um irgendwelche Sperren zu umgehen.
Christian Weisgerber
Nov 24, 2023, 2:30:06 PM11/24/23
to
On 2023-11-24, Andreas M. Kirchwitz <a...@spamfence.net> wrote:
> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
Was du schreibst ergibt wenig Sinn. Offenbar machst du seltsame
> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
Annahmen.
Prinzipiell kann man auf jedem Rechner einen eigener Resolver
betreiben, der Namen ab der Root-Zone auflöst und auch DNSSEC prüft.
Um mehr Anfragen zu cachen, ist es aber sinnvoll, dass mehrere
Rechner auf einen Resolver zugreifen. Im Heimnetz lässt man einen
solchen Resolver geschickterweise auf dem Host laufen, der auch
sonstige Infrastrukturdienste (DHCP, SLAAC, NTP, usw.) anbietet.
Wenn das nicht geht, weil es ein vom Provider gestelltes Gerät o.ä.
ist, dann stellen manche Leute halt einfach einen Raspberry Pi oder
so daneben. Der Resolver ist ein _interner_ Dienst.
Unterwegs kann man prinzipiell auf dem Laptop auch einen eigenen
Resolver laufen lassen. Allerdings stößt man dort ja laufend auf
Captive Portals, die auf manipulierte DNS-Antworten angewiesen sind
und/oder abgehende DNS-Abfragen blockieren. Natürlich blockieren
diese feindseligen Netze auch gerne beliebige andere Dinge wie
Tunnel, so das es keine allgemeine Lösung gibt. OpenBSD bringt
dafür unwind(8) mit:
unwind sends DNS queries to nameservers to answer queries.
If it detects that DNS queries are blocked by the local
network, it can switch to resolvers learned through
autoconfiguration. It periodically probes if DNS is no
longer blocked and switches back to querying nameservers
itself.
Sollte ich vielleicht mal verwenden, habe ich aber noch nicht,
sondern nehme bisher unterwegs die Resolver, die mir angeboten
werden, und bin mir bewusst, dass die Anworten nicht zuverlässig
sind.
Andreas M. Kirchwitz
Nov 24, 2023, 3:53:49 PM11/24/23
to
Christian Weisgerber <na...@mips.inka.de> wrote:
>> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
>> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
>> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
>> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
>> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
>
> Was du schreibst ergibt wenig Sinn. Offenbar machst du seltsame
> Annahmen.
Danke, das höre ich zu Hause oft. :-)
>> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
>> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
>> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
>> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
>> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
>
> Was du schreibst ergibt wenig Sinn. Offenbar machst du seltsame
> Annahmen.
> Prinzipiell kann man auf jedem Rechner einen eigener Resolver
> betreiben, der Namen ab der Root-Zone auflöst und auch DNSSEC prüft.
und es wäre schön, wenn ich die nutzen könnte, weil die bereits
das tun, was ich brauche. Nur sieht DNS klassisch nicht vor,
dass ich mich als Client ausweisen kann. Da kann ich mich nicht
mit Username/Passwort anmelden. Ist halt historisch so. Pech.
Deswegen ist es nicht wirklich ein guter Ratschlag für die
breite Masse, man könne ja seinen eigenen Resolver betreiben,
und dann habe man keine DNS-Sperren mehr.
> Um mehr Anfragen zu cachen, ist es aber sinnvoll, dass mehrere
> Rechner auf einen Resolver zugreifen. Im Heimnetz lässt man einen
> solchen Resolver geschickterweise auf dem Host laufen, der auch
> sonstige Infrastrukturdienste (DHCP, SLAAC, NTP, usw.) anbietet.
internen Dienste mehr. Netzgedöns macht die Fritzbox, vieles kommt
aus der Cloud, nur noch der DNS-Resolver erfordert einen extra PC,
und sei es ein Raspi, aber es ist eigentlich schade um den Strom,
vom Zeitaufwand mal abgesehen, man muss sich halt drum kümmern.
> Unterwegs kann man prinzipiell auf dem Laptop auch einen eigenen
> Resolver laufen lassen.
ist das keine Lösung, die allgemein umsetzbar ist. Die haben keine
aufwendigen DNS-Implementierungen. Wenn man froh ist, kann man die
über DHCP bezogenen DNS-Infos manuell überschreiben mit ein oder
zwei Alternativen, aber selbstverständlich ist nicht mal das.
Außerdem hab ich ja einen Haufen Nameserver im Netz stehen, die ich
bereits pflege. Die würde ich gern nutzen. Nur ist eben das Problem,
dass ich unterwegs und sogar zu Hause für die ein beliebiger Nutzer
bin hinter meinem Privat-DSL oder im Mobilfunk. Ich würde die gern
offen betreiben, sollen sich doch andere auch daran erfreuen, doch
einen unzensierten DNS-Resolver offen ins Netz zu stellen, ist in
Deutschland rechtlich nicht möglich.
Selbstverständlich kann man für individuelle Spezial-Setups Tunnel
bauen, VPN verwenden, dann habe ich für einen simplen Anwendungsfall
einen erheblichen Overhead eingeführt, worunter Robustheit und
Performance spürbar leiden. Für viele Geräte ist das aber sowieso
gar nicht möglich. Das ist einfach keine praxistaugliche Lösung.
Ich will ja kein kompliziertes Nerd-Bastelprojekt, sondern ich
will die Komplexität aus der Sache rausnehmen. Das bietet DNS nicht.
Insofern sind DNS-Sperren kein so dummer Schachzug, wie oft
behauptet wird. Man muss eben nur langfristig denken. Man kann
DNS-Sperren gewiss temporär entkommen, das ist easy, dann fühlt
man sich frei, doch die Kompromisse, die man dafür dauerhaft
eingehen muss, sind ein heftiger Klotz am Bein, den man früher
oder später entnervt abschüttelt.
Grüße, Andreas
Marco Moock
Nov 24, 2023, 4:16:52 PM11/24/23
to
Am 24.11.2023 um 20:53:47 Uhr schrieb Andreas M. Kirchwitz:
> Nur sieht DNS klassisch nicht vor, dass ich mich als Client ausweisen
> kann. Da kann ich mich nicht mit Username/Passwort anmelden. Ist halt
> historisch so. Pech.
Normales DNS nicht, aber DNS over TLS oder HTTPS müsste
> Nur sieht DNS klassisch nicht vor, dass ich mich als Client ausweisen
> kann. Da kann ich mich nicht mit Username/Passwort anmelden. Ist halt
> historisch so. Pech.
Zertifikat-Anmeldung unterstützen, wenn Client und Server mitmachen.
Andreas M. Kirchwitz
Nov 24, 2023, 10:17:43 PM11/24/23
to
Marco Moock <mm+s...@dorfdsl.de> wrote:
>> Nur sieht DNS klassisch nicht vor, dass ich mich als Client ausweisen
>> kann. Da kann ich mich nicht mit Username/Passwort anmelden. Ist halt
>> historisch so. Pech.
>
> Normales DNS nicht, aber DNS over TLS oder HTTPS müsste
> Zertifikat-Anmeldung unterstützen, wenn Client und Server mitmachen.
Theoretisch könnte das eine technische Option sein, aber wie viele
>> Nur sieht DNS klassisch nicht vor, dass ich mich als Client ausweisen
>> kann. Da kann ich mich nicht mit Username/Passwort anmelden. Ist halt
>> historisch so. Pech.
>
> Normales DNS nicht, aber DNS over TLS oder HTTPS müsste
> Zertifikat-Anmeldung unterstützen, wenn Client und Server mitmachen.
praktische Implementierungen kennst Du, wo man das steuern kann?
Es klingt so einfach mit dem eigenen DNS-Resolver, als wäre das die
Lösung fürs Volk, um den bösen DNS-Filtern zu entkommen... doch die
Nutzung externer DNS-Server ist schon immer schwierig gewesen, und
da haben neuere Protokolle bislang wenig geändert.
Ich bin ja selbst auf der Suche nach alltagstauglichen Lösungen. :-)
Grüße, Andreas
Marco Moock
Nov 25, 2023, 4:09:18 AM11/25/23
to
Am 25.11.2023 um 03:17:40 Uhr schrieb Andreas M. Kirchwitz:
> Marco Moock <mm+s...@dorfdsl.de> wrote:
>
> >> Nur sieht DNS klassisch nicht vor, dass ich mich als Client
> >> ausweisen kann. Da kann ich mich nicht mit Username/Passwort
> >> anmelden. Ist halt historisch so. Pech.
> >
> > Normales DNS nicht, aber DNS over TLS oder HTTPS müsste
> > Zertifikat-Anmeldung unterstützen, wenn Client und Server
> > mitmachen.
>
> Theoretisch könnte das eine technische Option sein, aber wie viele
> praktische Implementierungen kennst Du, wo man das steuern kann?
Keine. Ich habe aber die Idee gefunden, einfach das Passwort in der URL
> Marco Moock <mm+s...@dorfdsl.de> wrote:
>
> >> Nur sieht DNS klassisch nicht vor, dass ich mich als Client
> >> ausweisen kann. Da kann ich mich nicht mit Username/Passwort
> >> anmelden. Ist halt historisch so. Pech.
> >
> > Normales DNS nicht, aber DNS over TLS oder HTTPS müsste
> > Zertifikat-Anmeldung unterstützen, wenn Client und Server
> > mitmachen.
>
> Theoretisch könnte das eine technische Option sein, aber wie viele
> praktische Implementierungen kennst Du, wo man das steuern kann?
für DoH zu platzieren, sollte ausreichend sein, um Attacken zu
verhindern.
> Es klingt so einfach mit dem eigenen DNS-Resolver, als wäre das die
> Lösung fürs Volk, um den bösen DNS-Filtern zu entkommen... doch die
> Nutzung externer DNS-Server ist schon immer schwierig gewesen, und
> da haben neuere Protokolle bislang wenig geändert.
>
> Ich bin ja selbst auf der Suche nach alltagstauglichen Lösungen. :-)
installieren. Bei Captiv-Portalscheisse muss man den halt DNS kurz
auf den vom Netzbetreiber ändern.
Jörg Lorenz
Nov 25, 2023, 5:51:05 AM11/25/23
to
On 25.11.23 10:09, Marco Moock wrote:
> Bei Captiv-Portalscheisse muss man den halt DNS kurz
> auf den vom Netzbetreiber ändern.
Meistens nicht nötig.
> Bei Captiv-Portalscheisse muss man den halt DNS kurz
> auf den vom Netzbetreiber ändern.
Mein Swisscom-Portal erreiche ich ganz problemlos mit DOH auf einen
ausländischen DNS-Server.
--
Sent with Betterbird by a Penguin.
Simply better. www.betterbird.eu
Wendelin Uez
Nov 26, 2023, 2:14:20 PM11/26/23
to
> bin mir bewusst, dass die Anworten nicht zuverlässig sind.
Was muß man unter "nicht zuverlässig" verstehen? Normalerweise werden die
aufgelösten Adressen ja stimmen, und "zwielichtige" Seiten wird man
unterwegs wohl kaum abrufen, und wenn sie abruft wird man trotzdem sehr
schnell erkennen, ob die Seiten von Amts wegen blockiert sind oder nicht.
Was kann da also sonst noch schief laufen weswegen es sich lohnen könne,
einen anderen DNS-Server zu beaufschlagen?
Jörg Lorenz
Nov 26, 2023, 4:31:59 PM11/26/23
to
Wendelin Uez
Nov 27, 2023, 1:57:56 PM11/27/23
to
>> Was muß man unter "nicht zuverlässig" verstehen? Normalerweise werden die
>> aufgelösten Adressen ja stimmen, und "zwielichtige" Seiten wird man
>> unterwegs wohl kaum abrufen, und wenn sie abruft wird man trotzdem sehr
>> schnell erkennen, ob die Seiten von Amts wegen blockiert sind oder nicht.
>>
>> Was kann da also sonst noch schief laufen weswegen es sich lohnen könne,
>> einen anderen DNS-Server zu beaufschlagen?
>
> Mit wem redest Du, Troll?
Jedenfalls nicht mit Idioten.
>> aufgelösten Adressen ja stimmen, und "zwielichtige" Seiten wird man
>> unterwegs wohl kaum abrufen, und wenn sie abruft wird man trotzdem sehr
>> schnell erkennen, ob die Seiten von Amts wegen blockiert sind oder nicht.
>>
>> Was kann da also sonst noch schief laufen weswegen es sich lohnen könne,
>> einen anderen DNS-Server zu beaufschlagen?
>
> Mit wem redest Du, Troll?
Christian Weisgerber
Nov 29, 2023, 4:30:08 PM11/29/23
to
On 2023-11-26, Wendelin Uez <wu...@online.de> wrote:
>> bin mir bewusst, dass die Anworten nicht zuverlässig sind.
>
> Was muß man unter "nicht zuverlässig" verstehen? Normalerweise werden die
> aufgelösten Adressen ja stimmen,
Das weiß man eben nicht. Vielleicht wird NXDOMAIN auf eine Portalseite
>> bin mir bewusst, dass die Anworten nicht zuverlässig sind.
>
> Was muß man unter "nicht zuverlässig" verstehen? Normalerweise werden die
> aufgelösten Adressen ja stimmen,
umgebogen, wie die Telekom das getan hat (immer noch tut?). Vielleicht
wird Google auf Bing umgebogen, weil man einen Werbevertrag hat.
Vielleicht hat man auch noch Zertifikate erbeutet für einen MitM-Angriff,
siehe den Anfang des Threads.
> und "zwielichtige" Seiten wird man
> unterwegs wohl kaum abrufen, und wenn sie abruft wird man trotzdem sehr
> schnell erkennen, ob die Seiten von Amts wegen blockiert sind oder nicht.
Artikel im Body Modification Ezine lesen. Ach halt, das ist ja von
der Bundesprüfstelle als jugendgefährdend eingestuft und wird (wurde?)
in den Resolvern deutscher ISPs gefiltert.
Marco Moock
Nov 30, 2023, 2:07:30 AM11/30/23
to
Am 29.11.2023 um 20:36:14 Uhr schrieb Christian Weisgerber:
> Das weiß man eben nicht. Vielleicht wird NXDOMAIN auf eine Portalseite
> umgebogen, wie die Telekom das getan hat (immer noch tut?).
Nach meinem Kenntnisstand wurde die T-Online Navigationshilfe
> Das weiß man eben nicht. Vielleicht wird NXDOMAIN auf eine Portalseite
> umgebogen, wie die Telekom das getan hat (immer noch tut?).
abgestellt und nicht wieder angestellt.
https://www.golem.de/news/t-online-navigationshilfe-telekom-beendet-dns-hijacking-nach-strafanzeige-1905-141370.html
Andreas M. Kirchwitz
Nov 30, 2023, 7:43:59 AM11/30/23
to
Marco Moock <mm+s...@dorfdsl.de> wrote:
> Am 29.11.2023 um 20:36:14 Uhr schrieb Christian Weisgerber:
>
>> Das weiß man eben nicht. Vielleicht wird NXDOMAIN auf eine Portalseite
>> umgebogen, wie die Telekom das getan hat (immer noch tut?).
>
> Nach meinem Kenntnisstand wurde die T-Online Navigationshilfe
> abgestellt und nicht wieder angestellt.
Was Christian damit vielleicht zum Ausdruck bringen wollte,
> Am 29.11.2023 um 20:36:14 Uhr schrieb Christian Weisgerber:
>
>> Das weiß man eben nicht. Vielleicht wird NXDOMAIN auf eine Portalseite
>> umgebogen, wie die Telekom das getan hat (immer noch tut?).
>
> Nach meinem Kenntnisstand wurde die T-Online Navigationshilfe
> abgestellt und nicht wieder angestellt.
war meiner Meinung nach vor allem, dass Manipulation am DNS
in Deutschland schon lange vor gesetzlichen DNS-Sperren
existiert hat und in großem Maßstab praktiziert worden ist.
Es ist also kein theoretisches Thema, das einen "aufrichtigen"
Deutschen ja nie betreffen könnte.
Obwohl es grundsätzlich auf vielen Geräten möglich ist,
die DNS-Konfiguration zu verändern, taugt das leider
nicht als universelle Möglichkeit in allen Lebenslagen,
ganz besonders nicht mobil unterwegs, wo sich die
DNS-Situation ständig ändert und teilweise sehr starke
Netzwerk-Filter greifen, die einem das gezielt erschweren
sollen. Die Fummelei ist kaum erträglich in der Praxis,
und mag ergibt sich vor allem mobil zähneknirschend den
staatlichen und anderen DNS-Filtern.
Ich glaube, wir alle haben uns anfangs über DNS-Sperren
lustig gemacht, wie vermeintlich wirkungslos sie wären,
doch im modernen Alltag greifen sie leider ziemlich gut.
Vielleicht mag sich das ändern, wenn Geräte standardmäßig
DoH verwenden statt klassisches DNS oder DoT, aber noch
ist das eher unüblich, obwohl vereinzelt Anwendungen
(z.B. Firefox außerhalb DE) bereits darauf setzen.
Trotz allem kann man froh sein über DNS-Sperren als
"Zensur"-Mittel, denn zumindest punktuell sind sie eben
relativ einfach umgehbar, wenn man es gezielt möchte.
Man könnte mit der Filterung ja auch noch ganz woanders
reinschlagen und dann wird die Umgehung schon aufwendiger.
Grüße, Andreas
Arno Welzel
Dec 11, 2023, 5:54:52 AM12/11/23
to
Jörg Lorenz, 2023-11-22 18:04:
> Am 22.11.23 um 15:29 schrieb Arno Welzel:
[...]
Mir waren nur nicht die vorgesehenen Zensur-Pläne im Detail bekannt.
> Am 22.11.23 um 15:29 schrieb Arno Welzel:
>>> Die gruselige Schwedin https://de.wikipedia.org/wiki/Ylva_Johansson
>>> hätte das sicher gerne. Und um einen solchen DNS-Resover zu umgehen,
>>> braucht man nicht mal ein VPN.
>>
>> Ach so - nur ein weiterer Nameserver. Ich dachte, es geht darum, dass
>> die Nutzung nicht zensierter Nameserver verhindert werden soll.
>
> Ich dachte die Funktionsweise von DNS over HTTPS sei bekannt.
Ist sie auch.
>>> hätte das sicher gerne. Und um einen solchen DNS-Resover zu umgehen,
>>> braucht man nicht mal ein VPN.
>>
>> Ach so - nur ein weiterer Nameserver. Ich dachte, es geht darum, dass
>> die Nutzung nicht zensierter Nameserver verhindert werden soll.
>
> Ich dachte die Funktionsweise von DNS over HTTPS sei bekannt.
Mir waren nur nicht die vorgesehenen Zensur-Pläne im Detail bekannt.
Arno Welzel
Dec 11, 2023, 5:56:54 AM12/11/23
to
Christian @Soemtron, 2023-11-23 14:39:
> Marco Moock <mm+s...@dorfdsl.de> schrieb:
Einfacher: Stelle Dir einen Raspberry Pi hin, der als DNS für dein
Netzwerk arbeitet und trage den als DNS in der Fritz!Box ein.
> Marco Moock <mm+s...@dorfdsl.de> schrieb:
> Also ich habe eine Fritzbox und minimalen Aufwand würde ich auch
> betreiben. Wie sieht dieser genau aus? Ich befürchte ja, daß "minimal" in
> dem Zusammenhang eher nichtssagendes Füllwort ist, da ungenannte weitere
> Vorbedingungen existieren und das Ganze ohne diese in stunden-/tagelange
> Frickelei mündet.
Ja.
> betreiben. Wie sieht dieser genau aus? Ich befürchte ja, daß "minimal" in
> dem Zusammenhang eher nichtssagendes Füllwort ist, da ungenannte weitere
> Vorbedingungen existieren und das Ganze ohne diese in stunden-/tagelange
> Frickelei mündet.
Einfacher: Stelle Dir einen Raspberry Pi hin, der als DNS für dein
Netzwerk arbeitet und trage den als DNS in der Fritz!Box ein.
Arno Welzel
Dec 11, 2023, 5:58:24 AM12/11/23
to
Andreas M. Kirchwitz, 2023-11-24 02:08:
> Marco Moock <mm+u...@dorfdsl.de> wrote:
>
>> [DNS-Server mit/ohne Sperren]
>> Ich betreibe meinen eigenen (ist nicht schwer, man muss es aber grob
>> verstehen). Wenn den jemand nutzen will, kann ich da die Adressbereiche
>> freigeben (es ist kein offener Resolver und soll keiner werden).
>
> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
Wireguard und ggf. DynDNS, wenn der Server hinter eine dynamischen IP steht.
> Auf Clients habe ich teilweise wenig Einfluss, was die im Detail
> für Protokolle verwenden. Dort trägt man eine oder zwei blanke
> IP-Adressen ein, und dann muss die Sache einfach laufen.
>
> Seinen eigenen Resolver zu betreiben, klingt so leicht, doch der
> ist oft nicht ohne weiteres nutzbar.
Wenn Du auf *fremden* Clients arbeitest, ist jede Diskussion über
DNS-Konfiguration hinfällig.
> Marco Moock <mm+u...@dorfdsl.de> wrote:
>
>> [DNS-Server mit/ohne Sperren]
>> Ich betreibe meinen eigenen (ist nicht schwer, man muss es aber grob
>> verstehen). Wenn den jemand nutzen will, kann ich da die Adressbereiche
>> freigeben (es ist kein offener Resolver und soll keiner werden).
>
> Einen eigenen DNS-Server im Netz zu betreiben, ist vielleicht nicht
> das Problem, doch mir ist noch keine schlaue Lösung eingefallen,
> wie ich meinen eigenen DNS-Server auch für mich selbst sinnvoll
> nutzen kann, denn zu Hause oder unterwegs habe ich keine feste
> IP-Adresse, so dass mein DNS-Server mich für einen Fremden hält.
> Auf Clients habe ich teilweise wenig Einfluss, was die im Detail
> für Protokolle verwenden. Dort trägt man eine oder zwei blanke
> IP-Adressen ein, und dann muss die Sache einfach laufen.
>
> Seinen eigenen Resolver zu betreiben, klingt so leicht, doch der
> ist oft nicht ohne weiteres nutzbar.
DNS-Konfiguration hinfällig.
Arno Welzel
Dec 15, 2023, 7:02:46 PM12/15/23
to
Christian @Soemtron, 2023-12-12 20:07:
> Arno Welzel <use...@arnowelzel.de> schrieb:
> das ist relativ, und es ist ein weiteres Gerät, das upgedatet werden muß,
> Geld, Platz, Strom kostet und kaputt gehen kann. Da relativiert sich das
> "einfach".
Immer noch einfacher, als auf die Fritz!Box irgendeine andere Software
installieren zu wollen. Und apt kann durchaus auch so konfiguriert
werden, dass kritische Updates automatisch installiert werden.
Und Strom... na ja, ein paar Watt halt. Billiger als ein Server bei
einem Provider, wo man seinen Nameserver laufen lässt.
> Arno Welzel <use...@arnowelzel.de> schrieb:
>
>> Einfacher: Stelle Dir einen Raspberry Pi hin, der als DNS für dein
>> Netzwerk arbeitet und trage den als DNS in der Fritz!Box ein.
>
> Einfacher... die Installation der nötigen Software vermutlich. Aber auch
>> Einfacher: Stelle Dir einen Raspberry Pi hin, der als DNS für dein
>> Netzwerk arbeitet und trage den als DNS in der Fritz!Box ein.
>
> das ist relativ, und es ist ein weiteres Gerät, das upgedatet werden muß,
> Geld, Platz, Strom kostet und kaputt gehen kann. Da relativiert sich das
> "einfach".
Immer noch einfacher, als auf die Fritz!Box irgendeine andere Software
installieren zu wollen. Und apt kann durchaus auch so konfiguriert
werden, dass kritische Updates automatisch installiert werden.
Und Strom... na ja, ein paar Watt halt. Billiger als ein Server bei
einem Provider, wo man seinen Nameserver laufen lässt.
0 new messages