Die Frage ist, was außer IP und Standort da großartig übertragen werden soll. TLS ist Layer 5. Davon sieht der Chip nichts, weil er maximal Layer 4 macht. Und wer HTTPS nicht nutzt, wo es relevant ist (insofern die Gegenstelle das überhaupt noch unterstützt), dem ist nur wenig zu helfen.
Qualcomm-Chip senden heimlich private Informationen.
- Ersteller mcb
- Erstellt am
Ich konnte bisher den Artikel noch nicht lesen - wurde dann überhaupt ausgehender Traffic analysiert?
Zu A-GPS/SUPL gibt es zumindest hier ein wenige Lesestoff:
Aber dies spielt sich ja auf OS-Ebene ab...
Eine Frage wäre auch, ob der Chip ohne die entsprechende App im OS(von Qualcomm gibt es da auf manchem Androiden Systemapps) was funkt, dann müsste dies ja hardcoded hinterlegt sein und man könnte es ausgehend blockieren
Zu A-GPS/SUPL gibt es zumindest hier ein wenige Lesestoff:
Android: Bei jeder Standortermittlung erfährt Google eure Position inkl. IMSI-Nummer
Viele Android-Apps nutzen die Standortermittlung, um den genauen oder ungefähren Standort des Benutzers zu bestimmen.
www.kuketz-blog.de
Aber dies spielt sich ja auf OS-Ebene ab...
Eine Frage wäre auch, ob der Chip ohne die entsprechende App im OS(von Qualcomm gibt es da auf manchem Androiden Systemapps) was funkt, dann müsste dies ja hardcoded hinterlegt sein und man könnte es ausgehend blockieren
Noch was völlig bananiges: Warum sollte man sich den Aufwand machen einen DNS-Client in der Firmware zu implementieren? Sinnvoller wäre es wenigstens die IP direkt anzufunken.
Aber im Endeffekt könnte sl500 auf dem richtigen Pfad sein, dass das im Treiber/Kernel Modul geschieht. Keine Ahnung, ob der FLOSS ist, dann könnte man nachsehen. Und ohne ist nichts mit Netzwerk am Gerät.
Aber im Endeffekt könnte sl500 auf dem richtigen Pfad sein, dass das im Treiber/Kernel Modul geschieht. Keine Ahnung, ob der FLOSS ist, dann könnte man nachsehen. Und ohne ist nichts mit Netzwerk am Gerät.
ebastler
Rather active member
- Registriert
- 29 Dez. 2018
- Beiträge
- 1.289
Android hat haufenweise closed source blobs in den Kerneln. Und dazu kommt eben noch die Firmware, die nochmal als unabhängiges OS unter dem Linux Kernel läuft und Dinge treibt. Vergleichbar mit Intel ME und AMDs Pendant dessen Namen ich nicht kenne, glaub ich. ME hat übrigens auch vollen Zugriff auf Prozessor-Register und Caches, RAM, und NIC und könnte theoretisch alles aus dem RAM an Intel funken wenn Intel möchte.
Unerheblich wo würde man sowas immer möglichst klein und performant implementieren, solange es nicht da ist, wo man Ressourcen im Überfluss (ergo auf dem Massenspeicher und im Betriebssystem) ist. Und da passt sowas unnützen wie ein DNS-Client nicht zu. Ich gehe weiterhin davon aus, dass es nicht auf irgendwelchen Flash-Chips liegt.
- Registriert
- 22 Mai 2007
- Beiträge
- 10.526
Weil IP-Adressen von Servern nicht zwingend über Jahre konstant sind. Weil man bei entsprechend vielen Verbindungen (Hunderte Millionen von Android-Smartphones mit Qualcomm-Chipsatz) Lastverteilung oder regional verteilte Serverfarmen braucht. Weil...
Direkt fest-verdrahtete IP-Adressen anzusprechen skaliert einfach nicht.
Erm...
Ein DN wird auf einem DNS aufgelöst und leitet das Stück Software an eine IP-Adresse weiter. Lastverteilung macht man nicht am DNS. Oder wie stellst du dir das vor? Oh, unser Server ist stark belastet, lass uns schnell den AAA-Record ändern, dann geht schon in ... ca... 1-24 Stunden die Last runter!
Und IP-Adressen sind bei Unternehmen sogar oft konstanter als Domains.
Ein DN wird auf einem DNS aufgelöst und leitet das Stück Software an eine IP-Adresse weiter. Lastverteilung macht man nicht am DNS. Oder wie stellst du dir das vor? Oh, unser Server ist stark belastet, lass uns schnell den AAA-Record ändern, dann geht schon in ... ca... 1-24 Stunden die Last runter!
Und IP-Adressen sind bei Unternehmen sogar oft konstanter als Domains.
Klar geht das auch per DNS: https://de.wikipedia.org/wiki/Lastverteilung_per_DNS Dafür werden mehrere A-Records in wechselnder Reihenfolge ausgeliefert.
P.S.: Was sind AAA-Records?
Such' es dir aus. Ein prellendes oder ein vergessenes A.
Klar geht das auch per DNS: https://de.wikipedia.org/wiki/Lastverteilung_per_DNS Dafür werden mehrere A-Records in wechselnder Reihenfolge ausgeliefert.
P.S.: Was sind AAA-Records?
Lastverteilung per DNS ist keine (sinnvolle/echte/reale) Lastverteilung. Dass das nicht funktioniert sieht man tagtäglich an der Supermarktkasse (wobei hier noch dazu kommt, dass der Kunde sich nicht kurzfristig umsortieren kann, sondern auf die ein Mal gewählte Kasse festgelegt ist). Bei DNS ist noch vorhersehbar: die meisten Kunden nehmen Kasse 1.
Klar nehmen die meisten (alle) Kunden in diesem Fall Kasse 1. Deswegen variiert der DNS ja die Reihenfolge und für den Kunden sieht es so aus, als wenn immer eine andere Kasse die Nummer 1 hat, die er/sie dann nimmt. Und das funktioniert sehr wohl...
Real ist das DNS-Loadbalancing wohl auch. Wenn die Quellen stimmen, nutzen z.B. Amazon, eBay oder Yahoo es. Aber es stimmt natürlich, dass es noch sinnvollere Varianten auf höheren Ebenen gibt. Hängt aber eben auch vom Einsatzzweck ab...
Real ist das DNS-Loadbalancing wohl auch. Wenn die Quellen stimmen, nutzen z.B. Amazon, eBay oder Yahoo es. Aber es stimmt natürlich, dass es noch sinnvollere Varianten auf höheren Ebenen gibt. Hängt aber eben auch vom Einsatzzweck ab...
Es ist halt wie die Gewinnklassen beim Lotto. Der DNS hat keine Ahnung über die Last am Server. Das mag gut gehen, geht aber mit hoher Wahrscheinlichkeit nicht gut, wenn nicht eine weitere Lastverteilung oder überdimensionierte Ressourcen dahinter stehen.
Aber ist ok. Ich bin kein Fan davon und der Meinung, dass man das so nicht in den Flash programmieren würde.
Aber ist ok. Ich bin kein Fan davon und der Meinung, dass man das so nicht in den Flash programmieren würde.
"lbnamed, a load balancing name server" -> es gibt DNS-Server, die genau diese kennen und genau so die Last verteilen. Aber sonst wäre es auch immer noch "Load distribution" statt "Load balancing", was vermutlich immer noch besser wäre als alles auf einen Server zu schicken.
Das ist wohl logisch, dass ich hinter die Lastverteilung keine weitere Lastverteilung für die gleiche Ebene stecke. Das geht dann ziemlich sicher schief, wenn man es nicht genau darauf ausgelegt hat. Macht aber ja auch keinen Sinn. Wenn ich die Last schon verteilt habe, brauche ich keine weitere Lastverteilung.
Dann habe ich sowieso kein wirkliches Problem mehr.
Aber sl500 hat Recht
Daher zurück zum Thema des Threads.
Graphenos ist jetzt zumindest tätig geworden:
"
Latest release addresses the privacy issue brought to our attention by NitroKey with Qualcomm SoC devices by stopping xtra-daemon from sending the SoC serial number in the HTTPS User-Agent header:
"
Ob das ganze in der Firmware sitzt darüber streiten sich die Beteiligten noch ...
"
Latest release addresses the privacy issue brought to our attention by NitroKey with Qualcomm SoC devices by stopping xtra-daemon from sending the SoC serial number in the HTTPS User-Agent header:
"
Ob das ganze in der Firmware sitzt darüber streiten sich die Beteiligten noch ...
