Kann der Arbeitgeber sehen welche Apps das WLAN gebrauchen?
Hallo, dass der Anbieter vom WLAN die Webseiten sehen kann, steht in den AGBs
Kann er aber auch sehen welche Apps benutzt werden zb. Youtube oder Spiele?
LG
2 Antworten
Die Antwort ist ein klares Jein. Er kann nicht sehen, welche Apps auf Deinem Gerät laufen, aber er kann sehen, mit welchen IP-Adressen Du kommunizierst. Wenn die z.B. zu Youtube gehören, ergibt sich der Rest von alleine.
Wenn Du auch das normale DNS des WLAN nutzt, anstatt eine verschlüsselte DNS-Verbindung zu Cloudflare oder einem anderen passenden Anbieter aufzubauen, dann hat der Arbeitgeber es noch einfacher, weil er dann im Klartext sehen kann, welche Servernamen Du über das WLAN ansprichst.
Ob er das anlasslos so überwachen darf, ist eine andere Frage. Ob er sich darum schert, ob er es darf, eine dritte.
Nicht, wenn Du DNS over HTTPS (DoH) machst. Deshalb habe ich auch Cloudflare erwähnt; die sind ja der bekannteste Anbieter davon. Aber wer macht schon DoH...
SNI im TLS Handshake wird weder von DNS over TLS (DoT) noch von DNS over HTTP (DoH) beeinflusst. Wenn ich eine Verbindung zu Google aufbaue, steht da im Klartext google.com im Client Hello. Da ist es egal, mit welchem Verfahren ich die Adressauflösung gemacht habe.
Aber wer macht schon DoH...
Ich mache DoT zusammen mit DNSSEC.
Im eigenen Heimnetz halte ich das für sinnlos, denn der DNS-Server pflegt dem ISP zu gehören, durch den Dein ganzer Traffic läuft, und was nützt es Dir, wenn er Deine DNS-Anfrage nicht lesen kann, wenn er anschließend sieht, mit welcher IP Du Kontakt aufnimmst.
Da finde ich es problematischer, zusätzlich zu Deinem ISP auch noch einer Datenkrake wie Cloudflare Vollinformation zukommen zu lassen, welche Adressen Du so alles ansprichst.
Im eigenen Heimnetz halte ich das für sinnlos, denn der DNS-Server pflegt dem ISP zu gehören,
Im Heimnetz bestimme ich den DNS-Server. In der Regel ist es der Router, der jedoch nur Forwarder ist. Der fragt den DNS-Server, den ich bestimme. Und das ist ein bei mir im Netz stehender. Es geht also keine unverschlüsselte DNS-Anfrage raus. Durch DNSSEC kann vor allem auch keine Anfrage und keine Antwort verfälscht werden.
Der primäre Zweck des DNS-Servers ist das Blocken von Werbung etc. DNSSEC und DoT habe ich dann noch zusätzlich konfiguriert, "weil es geht" und aus persönlichem Interesse.
Da finde ich es problematischer, zusätzlich zu Deinem ISP auch noch einer Datenkrake wie Cloudflare Vollinformation zukommen zu lassen, welche Adressen Du so alles ansprichst.
Ich nutze nicht Cloudflare. Quad9, Digitale Gesellschaft u. a. sind Alternativen.
Durch DNSSEC kann vor allem auch keine Anfrage und keine Antwort verfälscht werden.
Außer durch den Betreiber des von Dir angesprochenen Upstream-DNS-Servers. Du verschiebst also das Vertrauen vom DNS-Server Deines ISP zu dem dieses von Dir gewählten Servers. MitM-Angriffe sind mehr als unwahrscheinlich, wenn Du aus dem Netz Deines ISP den DNS-Server Deines ISP ansprichst.
Der primäre Zweck des DNS-Servers ist das Blocken von Werbung
Wie soll das denn gehen!? Werbung kannst Du vielleicht mit einem Pi Hole blocken, weil Du dann bestimmte Adressen gar nicht mehr auflösen lässt. Aber innerhalb der Namensauflösung selbst gibt es keinen sinnvollen Ansatz zum Werbeblocken.
DNSSEC und DoT habe ich dann noch zusätzlich konfiguriert, "weil es geht" und aus persönlichem Interesse.
Genau so schätze ich diese Dienste auch ein: nette Spielerei auf akademischem Niveau, aber ohne Praxisrelevanz. Deshalb habe ich ein Pi Hole am Laufen, nutze aber solche Techniken nicht.
Quad9, Digitale Gesellschaft u. a. sind Alternativen.
Da haste vielleicht einen etwas besseren Ruf, am Ende weißt Du aber auch nicht, von wem die unterwandert sind.
Außer durch den Betreiber des von Dir angesprochenen Upstream-DNS-Servers. Du verschiebst also das Vertrauen vom DNS-Server Deines ISP zu dem dieses von Dir gewählten Servers.
Nein. Sie Signatur erfolgt gegen einen Schlüssel der Root-Zone.
Wie soll das denn gehen!? Werbung kannst Du vielleicht mit einem Pi Hole blocken, weil Du dann bestimmte Adressen gar nicht mehr auflösen lässt.
Nach genau diesem Prinzip. Ich habe hier eine Lokale Zone mit Adressen, die mit NXDOMAIN beantwortet werden. Außerdem sind in dieser Zone lokale Adressen enthalten. Alles andere wird aus dem Cache oder durch Nachfrage bei einem Upstream-Server beantwortet. Da Du PiHole kennst: Ja, das Prinzip ist dasselbe, die Umsetzung etwas anders.
Der Pi macht nebenher noch jede Menge anderes.
Nein. Sie Signatur erfolgt gegen einen Schlüssel der Root-Zone.
Hinsichtlich MitM, aber nicht hinsichtlich der Frage, wer Dein Surfverhalten protokolliert.
Der Pi macht nebenher noch jede Menge anderes.
Was macht er denn sonst noch? Ich habe einen. ;-) Außer Filterlisten abarbeiten ist da ja nicht viel. Außer vielleicht, dass man die Filter je nach Clientrechner anpassen kann, so dass ich meiner kleinen Tochter die Pornoseiten abkneifen und meinem Rechner zugestehen kann.
Hinsichtlich MitM, aber nicht hinsichtlich der Frage, wer Dein Surfverhalten protokolliert.
Logisch. Wenn allerdings alle bei Cloudflare anfragen (und das ist bei der DoH-Lösung von Firefox z. B. so), hat Cloudflare einen sehr globalen Überblick. Wenn es möglichst viele derartige Dienste gibt, verteilt sich das mehr. Aber klar ist: Alles was man nicht selbst macht, wird ggf. protokolliert.
Aber wie gesagt: DoH und DoT ist hier nur ein Nebenschauplatz und ich mache es nur, weil ich es kann und aus persönlichem Spieltrieb und Interesse an der Materie.
Was macht er denn sonst noch? Ich habe einen. ;-)
Nextcloud, Firefox-Sync-Server, Thingspeak-Server, Samba-Server, Wireguard-Server, Tor-Proxy, Zertifizierungsstelle, dazu den OCSP-Server. Auch einen Hidden Service im Darknet läuft darauf.
Außer vielleicht, dass man die Filter je nach Clientrechner anpassen kann, so dass ich meiner kleinen Tochter die Pornoseiten abkneifen und meinem Rechner zugestehen kann.
Da wüsste ich jetzt nicht, wie ich das in meiner Implementierung machen sollte.
Nextcloud, Firefox-Sync-Server, Thingspeak-Server, Samba-Server, Wireguard-Server, Tor-Proxy, Zertifizierungsstelle, dazu den OCSP-Server. Auch einen Hidden Service im Darknet läuft darauf.
Das sind alles zusätzliche Dienste, die Du zusätzlich auf Deinem Raspberry einrichten kannst. Bestandteil von Pi Hole sind sie nicht.
Da wüsste ich jetzt nicht, wie ich das in meiner Implementierung machen sollte.
Dann wäre es vielleicht mal Zeit für das Kommando "pihole -up" auf der Kommandozeile. Das entsprechende Feature ist nämlich vor einiger Zeit (gefühlt einem knappen Jahr oder so) eingeführt worden. Seitdem kannst Du Clients in Pihole in Gruppen einsortieren und die Gruppen unterschiedlich auf einzelne Filter berechtigen, so dass bestimmte Seiten beim einen Client ausgefiltert werden und beim anderen nicht. Brauchst dafür freilich feste (lokale) IPs für Deine Clients, damit die Gruppenzuordnung stabil ist.
Das sind alles zusätzliche Dienste, die Du zusätzlich auf Deinem Raspberry einrichten kannst. Bestandteil von Pi Hole sind sie nicht.
Richtig, habe ich auch nie behauptet.
Dann wäre es vielleicht mal Zeit für das Kommando "pihole -up" auf der Kommandozeile.
Wie schon gesagt, Pihole habe ich nicht, sondern eine eigene Lösung mit dem gleichen Ziel und ähnlichem Ansatz. Ich hatte mal über Pihole nachgedacht. Da aber zu diesem Zeitpunkt auf meinem Pi schon Nextcloud, Apache, u. a. liefen, befürchtete ich Nebenwirkungen. Pihole arbeitet ja meines Wissens mit Nginx, das ist neben Apache keine so gute Idee. Das hätte ich alles umbiegen müssen. Als Pihole erschien, lief mein Raspi schon einige Jahre u. a. mit Nextcloud.
Natürlich. Er kann den gesamten Datenverkehr sehen, sofern nicht verschlüsselt wird.
Verschlüsselten Datenverkehr kann er auch sehen, aber nicht uneingeschränkt lesen. Dinge wie DNS werden meist unverschlüsselt übertragen, aber auch der Verbindungsaufbau bei HTTPS enthält den Servernamen im Klartext.
Das kann er auch, indem er die Client Hellos im TLS Handshake anschaut. Auch da steht der Servername im Klartext drin.