Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>BigSur: Nach Hause, telephonieren?

BigSur: Nach Hause, telephonieren?

X-Ray
X-Ray13.11.2017:15
Ich bin ja eigentlich bei Apple bisher eher auf der ruhigen Seite gewesen was meine Bedenken zu Datenschutz und Privatsphäre anbelangt, aber hmmmm:

Jeffrey Paul: Dein Computer gehört dir nicht mehr


Das lässt doch nachdenklich werden wenn solche Türen stillschweigend eingebaut werden.

Dass dort Infos über jeden Programmstart übertragen werden....
Und Tools wie Little Snitch da nicht mehr eingreifen können.

T3N (okok, nicht gerade eine erste Adresse für zuverlässige infos)


Hier sind ja auch einige Netzspezis unterwegs: Was haltet ihr denn davon?
X-ray
„Planung ersetzt den Zufall durch Irrtum ( Einstein )“
+8

Kommentare

Tammi
Tammi13.11.2017:40
Wenn das so ist, dann ist es ziemlich übel! Also am besten die alte Windows-Kiste mit Windows XP wieder aktivieren und nie damit ins Internet!
0
ilig
ilig13.11.2017:47
R-Ray
Bei Deinem Link zu Jeffrey Paul bekam ich sofort dies zu sehen.
Hello, friend.
(I'm quite sorry for the interruption—the non-modal popups didn't fit enough text.)
Would you permit me to send you updates a few times per year?
Please enter your email address below, and I promise you some data of interest and value.

Best,
Jeffrey Paul (sneak)
Das lässt dann mich nachdenklich werden. Und sein Artikel hinterlässt bei mir aucht nicht gerade einen zuverlässigen Eindruck. Mal sehen was die Experten hier dazu schreiben – und natürlich die Frage, ob und wie Apple darauf reagieren wird.
+3
Weia
Weia13.11.2017:52
ilig
Bei Deinem Link zu Jeffrey Paul bekam ich sofort dies zu sehen.
[…]
Das lässt dann mich nachdenklich werden.
Wieso? Die Bitte, eine Mailingliste zu abonnieren, ist doch völlig legitim?

X-Ray Danke für die Links!
„🦖The dinosaurs invented Jesus to test our confidence in science“
+6
Lyrsti Monirsti13.11.2018:40
2 optionen: format c oder kongo
-14
Deichkind13.11.2019:14
Das was er da beschreibt, ist gestern nicht auf macOS 11 sondern auf OS 10.15.7. passiert. Und nachdem was ich über das Thema Prüfen auf zurück gezogenes Zertifikat beim Programmstart in den vergangenen Monaten bei Howard Oakley gelesen habe, hat es mich auch nicht überrascht. Nur dass die Programmierer mit dem Fall "Ausfall des Zertifikatsservers" so wenig elegant umgegangen sind, überrascht mich allerdings schon.
0
winfel13.11.2019:39
@Deichkind: Nicht ganz. Was hier beschrieben ist was neu sei (habs nicht überprüft) ist nicht, dass "nach Hause telefoniert" wird, sondern dass man es nicht mehr ändern kann. Wobei ich hier auch unsicher wäre, denn es wird nur die Möglichkeit mit Tools wie Little Snitch beschrieben wird. Funktioniert die Variante mit der hosts-Datei unter Big Sur nicht mehr?

Insgesamt ist der Artikel von Jeffrey Paul sehr informativ über das, wessen man sich im Klaren sein sollte, wenn man Geräte wie Apple Notebooks verwendet. Man könnte das ein bisschen weniger empört tun, aber nun gut. Es ist allemal besser, als sich dessen gar nicht bewusst zu sein.
+6
Der Mike
Der Mike13.11.2019:54
Tammi
Wenn das so ist, dann ist es ziemlich übel! Also am besten die alte Windows-Kiste mit Windows XP wieder aktivieren und nie damit ins Internet!

ROTFL

Im Ernst?!

*Gerade* XP war wohl das erste „Nachhausetelefonier-OS“ per se! (Aktivierung uswusf.) McFly, jemand zu Hause?

(Finde jetzt mal den Fehler, XP ohne ...)
-2
X-Ray
X-Ray13.11.2021:01
@winfel

Genau das ist der Punkt. Ich hätte es gut gefunden von Apole das sauber zu kommunizieren und nicht einfach stillschweigend zu aktivieren. Die Liste im System gibt es ja wohl schon länger, aber jetzt aktiv.

Den Weg über die hosts scheint es noch zu geben.
„Planung ersetzt den Zufall durch Irrtum ( Einstein )“
+1
oucar13.11.2021:19
winfel
@Deichkind: Nicht ganz. Was hier beschrieben ist was neu sei (habs nicht überprüft) ist nicht, dass "nach Hause telefoniert" wird, sondern dass man es nicht mehr ändern kann. Wobei ich hier auch unsicher wäre, denn es wird nur die Möglichkeit mit Tools wie Little Snitch beschrieben wird. Funktioniert die Variante mit der hosts-Datei unter Big Sur nicht mehr?

Insgesamt ist der Artikel von Jeffrey Paul sehr informativ über das, wessen man sich im Klaren sein sollte, wenn man Geräte wie Apple Notebooks verwendet. Man könnte das ein bisschen weniger empört tun, aber nun gut. Es ist allemal besser, als sich dessen gar nicht bewusst zu sein.

Es ist leider noch mehr, selbst ein VPN kann Dich nicht mehr schützen, da die OS Systemdienste das VPN einfach umgehen und somit Deine Location uvm. preisgegeben wird.

Hinzu kommt noch die Tatsache, dass die iCloud Backups nicht End-to-End verschlüsselt sind, sondern mit den Apple eigenen key und somit alles von authorisierter Stelle eingesehen werden kann,... besser man macht keine Fotos seiner Bitcoin Private Keys mit dem iPhone
+2
caba
caba14.11.2000:29
Dass die iCloud-Backups nicht verschlüsselt sind bzw. Apple den Schlüssel hat, das war ja bekannt und wird auch so von Apple zugegeben. Aber dass die iMessage-Nachrichten trotz ausgeschalteter iCloud trotzdem hochgeladen werden, überrascht dann doch. Oder auch nicht. Leider stehen in dem Artikel von Jeffrey Paul keine Quellen oder Beweise dafür.
Fordert nicht die EU gerade wieder mal eine Backdoor in Messengerdiensten? Da haben sie es ja dann mit Apple leicht, wenn die das schon freiwillig liefern. 😟
Schätze aber, dass das dann bei anderen Messengern auch so ist.
„Meinungen sind keine Ideen, Meinungen sind nicht so wichtig wie Ideen, Meinungen sind nur Meinungen. (J. Ive)“
0
Weia
Weia14.11.2001:18
caba
Aber dass die iMessage-Nachrichten trotz ausgeschalteter iCloud trotzdem hochgeladen werden, überrascht dann doch. Oder auch nicht. Leider stehen in dem Artikel von Jeffrey Paul keine Quellen oder Beweise dafür.
Wieso trotz ausgeschalteter iCloud? Wenn du weder iCloud für Messages noch das iCloud-Back-up für dein iOS Gerät aktiviert hast, dann wird natürlich nichts hochgeladen – das ist seit eh und je so und steht auch so im Artikel. Der merkt nur an, dass dir das alles nichts nützt, wenn dein Kommunikationspartner iCloud für Messages oder iCloud-Back-up aktiviert hat – aber das ist ja trivial und liegt in der Natur der Sache.

Weder ich noch meine Kommunikationspartner kämen auf die Idee, iCloud für Messages oder iCloud-Back-up zu aktivieren; insofern kann das mir oder Leuten, die das so handhaben wie ich, egal sein.
„🦖The dinosaurs invented Jesus to test our confidence in science“
0
caba
caba14.11.2002:16
weia
Stimmt. Ich hatte das that whoever you’re iMessaging with überlesen.
Ich habe iCloud auch aus, aber kann schlecht von allen Gesprächspartnern verlangen, dass sie das auch so tun.
„Meinungen sind keine Ideen, Meinungen sind nicht so wichtig wie Ideen, Meinungen sind nur Meinungen. (J. Ive)“
0
pünktchen
pünktchen14.11.2008:01
It turns out that in the current version of the macOS, the OS sends to Apple a hash (unique identifier) of each and every program you run, when you run it.

Ich hatte (unter Mojave) den Eindruck das passiere nur bei neu installierten oder aktualisierten Programmen und nicht bei jedem Programmstart? Apple Malwarecheck oder so.
0
Peter Eckel14.11.2011:40
Man muß das ganze etwas differenziert betrachten, dann findet man auch das wirkliche Problem mit der Angelegenheit.

trustd ist ein Systemdienst (im Unix-Slang "daemon"), der die Aufgabe hat, Zertifikate zu validieren. Das ist zunächst mal ein vollkommen normaler Vorgang, so macht das z.B. jeder beliebige Browser x-mal am Tag. Für die Verifizierung werden zunächst die sogenannten "Trust Chains" geprüft, also der Weg von einem zu prüfenden Zertifikat zu einer vertrauenswürdigen (das ist aber wieder ein anderes Thema) "Certification Authority" oder CA. Das ganze findet komplett offline statt.

Weiterhin muß man bei der Zertifikatsvalidierung aber noch prüfen, ob ein Zertifikat zurückgerufen (revoked) wurde. Das kann auf zwei Arten und Weisen passieren: Durch Herunterladen einer sogenannten Certificate Revocation List (CRL), essentiell einer langen Liste von zurückgerufenen Zertifikaten, mit der dann ein Abgleich anhand des Namens und der Seriennummer des zu prüfenden Zertifikats erfolgt, oder über das "Online Certificate Status Protocol" (OCSP), mit dem der Status einzelner Zertifikate abgefragt werden kann.

OCSP ist - auch aufgrund des Henne-Ei-Problems - grundsätzlich unverschlüsselt. Dafür kann Apple oder können die Browserhersteller nichts, das ist halt so. Und das sind die Anfragen, die Apple beim Start von Applikationen (die ja per Zertifikat signiert sind, das geprüft werden muß) bekommt. Genauso wie praktisch jede CA, die ein Zertifikat einer verschlüsselten Webseite signiert hat. OCSP ist eine veritable Datenschleuder, wenn man es mal ganz krass formulieren will.

Der im Artikel erwähnte Mechanismus, bei Nichterreichbarkeit eines OCSP-Servers sofort ohne nennenswerte Verzögerung aufzugeben ist auch kein böser Wille von Apple, sondern die übliche Vorgehensweise - ansonsten wäre leicht eine Denial of Service-Attacke gegen die OCSP-Server großer CAs möglich, und die würde wesentich mehr lahmlegen als nur ein paar Macs.

Ergo: Am trustd ist zunächst mal nichts böses, und die Informationen, die beim Aufruf von Programmen übers Netz gehen, nur eine zwingende Folge aus der Zertifikatsvalidierung. Eine mögliche Abhilfe - und aus meiner Sicht wünschenswert - wäre es, die per Gatekeeper-Einstellung abschaltbar zu machen. Fraglich ist nur, ob Apple das macht.

Eine generelle Abschaltung des trustd oder eine Abschottung des Daemons vom Netz ist auch keine Lösung, denn damit verhindert man, daß man vom Rückruf von Zertifikaten Kenntnis erhält und bekommt unterm Strich ein viel größeres und schwerer wiegendes Sicherheitsproblem - wobei ich die signierte Software für den uninteressanteren Aspekt halte als z.B. die Validierung der Zertifikate von Banken und ähnlichen sicherheitskritischen Kommunikationspartnern.

Bleibt die Abschaffung der Kernel Extensions, die z.B. Little Snitch für das Abfangen von Netzwerkpaketen nutzt. Das ist schon ein diffizileres Problem, denn eigentlich halte ich die Abschaffung der Kernel Extensions und die Einführung einer weiter oben angesiedelten Schnittstelle zum Einklinken in den Netzwerkverkehr für eine gute Idee. Die meisten Kernel Panics, die ich erlebt habe, sind auf veraltete, inkompatible oder schlicht schlecht geschriebene Kernel Extensions zurückzuführen, und da Schnittstellen durch weniger "gefährliche" zu ersetzen ist meines Erachtens kein schlechter Plan.

Wenn Apple nicht die - aus meiner Sicht vollkommen idiotische und Vertrauen verspielende - Idee gehabt hätte, da eine Ausschlußliste von Applikationen einzubauen, die eben nicht abgefangen werden können. Das ist zwar möglicherweise gegenüber manchen Leuten damit zu rechtfertigen, daß man so essentielle Systemkomponenten vor Fehlfunktionen schützen will - und im Lichte meiner obigen Ausführungen ist trustd tatsächlich ein guter Kandidat für eine solche Schutzmaßnahme - aber trotzdem bleibt das unangenehme Gefühl, von Apple gegängelt und seiner Souveränität beraubt zu werden. Nutzer z.B. von Little Snitch waren sich (hoffentlich) immer schon darüber klar, daß sie eventuell Systemfunktionen demolieren, und nahmen dies im Sinne der Kontrolle über ihren Netzwerkverkehr bewußt in Kauf. Diese Möglichkeit zu beschneiden ist keine gute Idee von Apple und sollte den Shitstorm bekommen, den sie verdient.

An diesem Aspekt geht der Artikel von Jeffrey Paul leider zu weit vorbei, als daß er - außer als Diskussionsanstoß - nützlich sein könnte.
„Ceterum censeo librum facierum esse delendum.“
+45
Peter Eckel14.11.2011:45
oucar
Es ist leider noch mehr, selbst ein VPN kann Dich nicht mehr schützen, da die OS Systemdienste das VPN einfach umgehen und somit Deine Location uvm. preisgegeben wird.
Es ist eine Binsenweisheit, daß nichts, wirklich nichts, was Du auf dem zu schützenden System machst, wirklich zuverlässig sein kann. Das war schon immer so, und das wird auch immer so sein: Wenn das System an der Schnittstelle, die Du nutzt, vorbeimanövriert, dann hast Du halt verloren. VPN, "Personal Firewall" - das ist alles nicht nutzlos, aber auch nie vollkommen zuverlässig.

Es gibt schon Gründe, warum im professionellen Einsatz eine Firewall eine Kiste aus Blech ist. Und in kritischen Umgebungen zwei, mit unterschiedlicher Hard- und Software. Das reduziert die Trefferfläche ganz erheblich (und nein, auch das ist nicht sicher, aber Größenordnungen sicherer als alles, was Du auf Deinem Rechner lokal installieren kannst).
„Ceterum censeo librum facierum esse delendum.“
+8
caba
caba14.11.2011:59
Danke, Peter, für deine ausführliche Erklärung.
„Meinungen sind keine Ideen, Meinungen sind nicht so wichtig wie Ideen, Meinungen sind nur Meinungen. (J. Ive)“
+3
pünktchen
pünktchen14.11.2012:15
Problematischer finde ich die mangelnde Verschlüsselung der Daten auf iCloud.
+3
Peter Eckel14.11.2012:22
pünktchen
Problematischer finde ich die mangelnde Verschlüsselung der Daten auf iCloud.
... die aber ein alter Hut ist.

Aber ja, problematisch ist die auch, und ein Grund, warum ich iCloud nicht nutze.
„Ceterum censeo librum facierum esse delendum.“
+2
beanchen14.11.2012:30
winfel
... sondern dass man es nicht mehr ändern kann. Wobei ich hier auch unsicher wäre, denn es wird nur die Möglichkeit mit Tools wie Little Snitch beschrieben wird. Funktioniert die Variante mit der hosts-Datei unter Big Sur nicht mehr?
Man kann es auf dem Mac selbst nicht mehr unterbinden, weil Tools wie Little Snitch und VPN-Clients keinen Zugriff mehr auf tiefe Systemfunktionen haben. Wer die seither sowieso nicht benutzt hat, für den änder sich auch nichts. Wer seither den Schutz zwischen Mac und Internet hatte, auch nicht.


Die Vermutung es handele sich um einen Check der Systemintegrität, finde ich naheliegend. Nach dem Update wurde ich vermehrt auf potentiell schädliche Programme aufmerksam gemacht.
Was mich an dem Artikel allerdings nachdenklich macht, ist die unverschlüsselte Kommunikation. Das sollte Apple besser hin bekommen, wenn ihnen der Datenschutz tatsächlich so viel wert ist, wie sie immer wieder betonen.
„Unterwegs in Analogistan: https://www.zdf.de/comedy/heute-show/heute-show-spezial-vom-19-januar-2024-100.html“
+3
blackboxberlin14.11.2012:32
Danke, Peter! Eine sehr gute Erklärung!
Peter Eckel
Eine generelle Abschaltung des trustd oder eine Abschottung des Daemons vom Netz ist auch keine Lösung, denn damit verhindert man, daß man vom Rückruf von Zertifikaten Kenntnis erhält und bekommt unterm Strich ein viel größeres und schwerer wiegendes Sicherheitsproblem - wobei ich die signierte Software für den uninteressanteren Aspekt halte als z.B. die Validierung der Zertifikate von Banken und ähnlichen sicherheitskritischen Kommunikationspartnern.
...
An diesem Aspekt geht der Artikel von Jeffrey Paul leider zu weit vorbei, als daß er - außer als Diskussionsanstoß - nützlich sein könnte.

Programme wie LittleSnitch sind nur eine Möglichkeit, noch kein Konzept für einen sicheren Mac! Solche Artikel erhaschen vielleicht erstmal Aufmerksamkeit, aber bieten auch keine Lösungsvorschläge!
So what?!

Die Jungs von http://objective-see.com/ bspw. haben ein paar gute Apps und zumeist hilfreiche Hintergrundinfos!
+3
Tayfun
Tayfun14.11.2012:43
Wenn man den Artikel so liest dann könnte man schon fast annehmen das Apple mit dem iPhone fast das perfekte Überwachungswerkzeug geschaffen hat.

Zuerst kam die iCloud damit man fleißig Daten über den Nutzer sammeln ( Kontakte, Bilder etc ) kann.

Dann kam Touch ID damit man zu dieser Person auch die biometrischen Daten zur Verfügung hat.

Danach Face ID denn man möchte ja wissen wem dieser Fingerabdruck gehört

Zuletzt die Apple Watch um zusätzliche biometrische Daten zu sammeln.

Sooo genug werde mal mein Alu Hut absetzen und wünsche ein angenehmes Wochenende.
-3
spheric
spheric14.11.2013:07
Peter Eckel
[fundierte Einordnung der Situation]

Vielen, vielen Dank, dass Du Dir Zeit genommen hast für diese Einschätzung.
„Früher war auch schon früher alles besser!“
+2
Peter Eckel14.11.2013:31
beanchen
Was mich an dem Artikel allerdings nachdenklich macht, ist die unverschlüsselte Kommunikation. Das sollte Apple besser hin bekommen, wenn ihnen der Datenschutz tatsächlich so viel wert ist, wie sie immer wieder betonen.
Nochmal: OCSP (das Standardprotokoll, über das die Validierung von Zertifikaten stattfindet, wenn keine CRLs zum Einsatz kommen) ist grundsätzlich unverschlüsselt, das ist so standardisiert.

Der Grund ist auch einfach: Wenn OCSP verschlüsselt stattfinden sollte, dann müßte es zum Zweck der Absicherung der OCSP-Verbindung ein Zertifikat geben. Dieses wiederum müßte man validieren können, und diese Validierung könnte nicht über die CA erfolgen, die das OCSP-Zertifikat ausgestellt hätte, denn zur Validierung brauchte man ja wieder OCSP, und damit beißt sich die Katze in den Schwanz.

Wenn also etwas zu kritisieren ist, dann daß das OCSP-Protokoll blöd ist (wie gesagt: Das ist nicht allein Apples Problem, das haben alle). Und das nicht nur weil es Informationen leakt, sondern auch weil es letztlich ziemlich unvollkommen ist: Wenn man das DDoS-Problem lösen will, das durch einen Angriff auf den OCSP-Server entstehen kann, bleibt einem nicht viel anderes übrig, als fehlgeschlagene OCSP-Versuche zu ignorieren. So machen das auch fast alle Clients, und damit hat man dann einen schönen Angriff auf die negative Validierung zurückgerufener Zertifikate.

Leider ist das aber nicht das einzige Problem der X509-PKI. Wenn man sich die Gesamtsituation anschaut, dann ist sie ziemlich kaputt und es ist verwunderlich, daß nicht mehr Schindluder mit Zertifikaten getrieben wird. Das fängt schon bei den derzeit grob geschätzt 200 "vertrauenswürdigen" CAs an, die mit macOS X 10.15 ausgeliefert werden.

Da werden dann als Notnagel irgendwelche Mechanismen drangestrickt wie CAA, Public Key Pinning etc., die mehr oder weniger effektiv Schwächen des Vertrauenskonzepts patchen und dafür entweder andere Schwächen aufreißen (CAA ohne DNSsec ist z.B. recht sinnfrei) oder größere Probleme verursachen, wenn etwas schiefgeht (wenn man z.B. Public Key Pinning einsetzt und es irgendwie hinbekommt, seine Schlüssel zu verlieren, ist die Domain dauerhaft tot).

In speziellen Ausnahmesituationen kann man das Problem lösen, indem man eine eigene (sinnvoll abgesicherte) CA betreibt und nur deren Zertifikate akzeptiert. Das mache ich z.B. bei der internen Kommunikation meiner Server untereinander so. Eine generelle Lösung ist das aber nicht, weil man natürlich nicht jedem potentiellen Besucher einer Webseite oder Betreiber eines Mailservers die erforderlichen Root- und/oder Intermediate-Zertifikate zukommen lassen kann.

Aber ja, OCSP ist doof, und es ist unverschlüsselt, und es leakt Daten. Das ist aber nicht erst seit macOS 11 so.

Das eigentliche Problem von Big Sur ist aber die dämliche Whitelist.
„Ceterum censeo librum facierum esse delendum.“
+9
beanchen14.11.2013:33
Ich hab das in deinem ersten Post überlesen. Danke für die eineuerliche Aufklärung!
„Unterwegs in Analogistan: https://www.zdf.de/comedy/heute-show/heute-show-spezial-vom-19-januar-2024-100.html“
+1
X-Ray
X-Ray14.11.2013:43
@Peter
Danke für die ausführlichen und fundierten Erklärungen. Das gibt Licht in die Angelegenheit.
Und ich denke man kann über den guten Sinn der Sicherheitsfunktionen einig sein, ebenso wie über den Unsinn der mässigen Kommunikation dieser Änderungen seitens Apple.

Nochmals danke
„Planung ersetzt den Zufall durch Irrtum ( Einstein )“
+3
sierkb14.11.2016:01
Weil im obig genannten Essay vom Hacker und Sicherheitsforscher
Jeffrey Paul (20.11.2020): Your Computer Isn't Yours
gleich eingangs darauf Bezug genommen wird, hier der ebenso sehr lesens- und nachdenkenswerte Essay von

GNU.org, Richard Stallman (1997): Das Recht zu lesen
0
sierkb14.11.2018:58
X-Ray
[…]

Das lässt doch nachdenklich werden wenn solche Türen stillschweigend eingebaut werden.

Dass dort Infos über jeden Programmstart übertragen werden....
Und Tools wie Little Snitch da nicht mehr eingreifen können.

[…]
Peter Eckel
[…]

Wenn Apple nicht die - aus meiner Sicht vollkommen idiotische und Vertrauen verspielende - Idee gehabt hätte, da eine Ausschlußliste von Applikationen einzubauen, die eben nicht abgefangen werden können.

[…]

Aber ja, OCSP ist doof, und es ist unverschlüsselt, und es leakt Daten. Das ist aber nicht erst seit macOS 11 so.

Das eigentliche Problem von Big Sur ist aber die dämliche Whitelist.


Vom Hersteller von Little Snitch dazu – nicht nur trustd steht auf jener Whitelist, sondern darüberhinaus noch ein paar weitere macOS Systemdienste und Frameworks und Apple Apps – u.a. dieses Statement:

Objective Development Software GmbH: Hilfe für Little Snitch: The traffic of some Apple processes isn’t shown in Little Snitch 5.
+3
McErik15.11.2006:28
Peter Eckel

Im Übrigen macht es mir besondere Freude, immer wieder den modernisierten Cato zu lesen!
0
Super8
Super815.11.2009:39
Peter Eckel

Das eigentliche Problem von Big Sur ist aber die dämliche Whitelist.

Das denke ich auch und frage mich, ob Little Snitch dann überhaupt noch eine Existenzberechtigung hat, wenn sie mir nicht jeglichen Traffic zeigen können.
„Es wird böse enden!“
0
Wellenbrett15.11.2010:06
Super8
Peter Eckel

Das eigentliche Problem von Big Sur ist aber die dämliche Whitelist.

Das denke ich auch und frage mich, ob Little Snitch dann überhaupt noch eine Existenzberechtigung hat, wenn sie mir nicht jeglichen Traffic zeigen können.
„Es wird böse enden!“
Unter dem Link, den sierkb dankenswerterweise genannt hat, schreibt Objective Development doch, dass sie davon ausgehen, dass Apple die Whitelist für zukünftige macOS-Versionen überdenken wird. Zudem arbeiten sie an einer Lösung die Whitelist-Verbindungen zumindest sichtbar zu machen. Little Snitch kann zudem natürlich weiterhin Drittanbieter-Apps daran hindern nach Hause zu telefonieren
+1
pünktchen
pünktchen15.11.2010:53
Ich denke mal Apples Programmierer möchten mit der Whitelist verhindern dass Malware seine Überprüfung verhindert.
+2
MikeMuc15.11.2010:57
Ich werde das Gefühl nicht los, das wir alle nur noch mit nem zwischengeschaltetem Raspi mit PiHole oder ähnlichem ins Netz gehen sollten. Der müßte dann nu noch einen Proxy für OSCP bieten der nich alle 5Minuten aktualisiert wird. Gibt es da schon was?
0
clayman15.11.2011:10
iMessages sind per se Ende zu Ende verschlüsselt. Auch wenn man iMessages in der Cloud aktiviert.

Problematisch wird’s, wenn man iCloud Backup aktiviert hat. Dann wird der Schlüssel für die verschlüsselten iMessages via iCloud Backup hochgeladen. Dann und erst dann hat Apple via Generalschlüssel für iCloud Backup Zugriff auf die iMessages.

Also kein iCloud Backup und damit auch kein Entschlüsseln der iMessages möglich.

„ Bei der Verwendung von "Nachrichten" in iCloud wird auch Ende-zu-Ende-Verschlüsselung eingesetzt. Wenn du "iCloud-Backup" aktiviert hast, enthält deine Backup eine Kopie des Schlüssels, der deine Nachrichten schützt. Dadurch wird sichergestellt, dass du deine Nachrichten wiederherstellen kannst, wenn du den Zugriff auf den iCloud-Schlüsselbund und deine vertrauenswürdigen Geräte verloren hast. Wenn du "iCloud-Backup" deaktivierst, wird auf deinem Gerät ein neuer Schlüssel generiert, um zukünftige Nachrichten zu schützen. Dieser Schlüssel wird nicht von Apple gespeichert.“

Quelle:

Für alle anderen Behauptungen gibts keine Quellen / Beweise

Weia
caba
Aber dass die iMessage-Nachrichten trotz ausgeschalteter iCloud trotzdem hochgeladen werden, überrascht dann doch. Oder auch nicht. Leider stehen in dem Artikel von Jeffrey Paul keine Quellen oder Beweise dafür.
Wieso trotz ausgeschalteter iCloud? Wenn du weder iCloud für Messages noch das iCloud-Back-up für dein iOS Gerät aktiviert hast, dann wird natürlich nichts hochgeladen – das ist seit eh und je so und steht auch so im Artikel. Der merkt nur an, dass dir das alles nichts nützt, wenn dein Kommunikationspartner iCloud für Messages oder iCloud-Back-up aktiviert hat – aber das ist ja trivial und liegt in der Natur der Sache.

Weder ich noch meine Kommunikationspartner kämen auf die Idee, iCloud für Messages oder iCloud-Back-up zu aktivieren; insofern kann das mir oder Leuten, die das so handhaben wie ich, egal sein.
+1
Wellenbrett15.11.2011:19
pünktchen
Ich denke mal Apples Programmierer möchten mit der Whitelist verhindern dass Malware seine Überprüfung verhindert.
Ich denke auch, das könnte ein Interesse Apples sein. Dazu müsste zunächst jedoch entweder der Anwender unbeabsichtigt oder die Malware natürlich absichtlich die Little Snitch-Regeln verändern. Apple hat sicherlich auch eigennütziges Interesse z.B. an Telemetrie-Daten.
+1
beanchen15.11.2011:41
MikeMuc
Ich werde das Gefühl nicht los, das wir alle nur noch mit nem zwischengeschaltetem Raspi mit PiHole oder ähnlichem ins Netz gehen sollten.
Wer ist "wir"? Bei der Zusammenkunft technisch versierter Menschen wird immer gerne vergessen, "wir" sind in der Minderheit. Die Mehrheit möchte ein funktionierendes Gerät um den neusten Kaufhaus-Newsletter zu lesen, sich über WhatsApp auszutauschen und Bilder mit Oma zu teilen. Dafür tut Apple viel und PiHole oder irgendwas anderes "zum Schutz" ist sowas von nicht nötig.
„Unterwegs in Analogistan: https://www.zdf.de/comedy/heute-show/heute-show-spezial-vom-19-januar-2024-100.html“
+6
Super8
Super815.11.2012:59
Wellenbrett
Super8
Peter Eckel

Das eigentliche Problem von Big Sur ist aber die dämliche Whitelist.

Das denke ich auch und frage mich, ob Little Snitch dann überhaupt noch eine Existenzberechtigung hat, wenn sie mir nicht jeglichen Traffic zeigen können.
„Es wird böse enden!“
Unter dem Link, den sierkb dankenswerterweise genannt hat, schreibt Objective Development doch, dass sie davon ausgehen, dass Apple die Whitelist für zukünftige macOS-Versionen überdenken wird. Zudem arbeiten sie an einer Lösung die Whitelist-Verbindungen zumindest sichtbar zu machen. Little Snitch kann zudem natürlich weiterhin Drittanbieter-Apps daran hindern nach Hause zu telefonieren

Das stimmt natürlich, ich konnte ja bisher immer sehen, wenn Apple seine Programmdaten checkte. Aber wenn ich das nicht mehr sehen kann, dann ist die Möglichkeit wieder da, dass jemand diese Anonymität ebenfalls „nutzt“. Das Snitchen werde ich behalten, aber wie lange kann ich denen noch trauen, dass sie mir den wirklich wichtigen Traffic anzeigen können ..
0
Wellenbrett15.11.2013:15
Super8
Wellenbrett
Super8
Peter Eckel

Das eigentliche Problem von Big Sur ist aber die dämliche Whitelist.

Das denke ich auch und frage mich, ob Little Snitch dann überhaupt noch eine Existenzberechtigung hat, wenn sie mir nicht jeglichen Traffic zeigen können.
„Es wird böse enden!“
Unter dem Link, den sierkb dankenswerterweise genannt hat, schreibt Objective Development doch, dass sie davon ausgehen, dass Apple die Whitelist für zukünftige macOS-Versionen überdenken wird. Zudem arbeiten sie an einer Lösung die Whitelist-Verbindungen zumindest sichtbar zu machen. Little Snitch kann zudem natürlich weiterhin Drittanbieter-Apps daran hindern nach Hause zu telefonieren

Das stimmt natürlich, ich konnte ja bisher immer sehen, wenn Apple seine Programmdaten checkte. Aber wenn ich das nicht mehr sehen kann, dann ist die Möglichkeit wieder da, dass jemand diese Anonymität ebenfalls „nutzt“. Das Snitchen werde ich behalten, aber wie lange kann ich denen noch trauen, dass sie mir den wirklich wichtigen Traffic anzeigen können ..
Also wie gesagt, LS kann derzeit in Version 5 die Apple-Systemdienste die Apple in die Whitelist eingetragen hat, nicht kontrollieren, alle Drittanbieter-Apps aber schon. Die "Mitbenutzung" von Apples Whitelist durch Malware oder Drittanbieter-Apps dürfte - wenn überhaupt (keine Ahnung, wie Apple diese implementiert) - nur durch Exploits veränderbar sein und das auch nur temporär, bis Apple die Lücke wieder geschlossen hat.
0
sierkb15.11.2014:38
sierkb
Objective Development Software GmbH: Hilfe für Little Snitch: The traffic of some Apple processes isn’t shown in Little Snitch 5.

Ergänzung:

Objective Development Software GmbH: Hilfe für Little Snitch: Kann Little Snitch 4 auf macOS 11 Big Sur installiert werden?
0
sierkb15.11.2014:57
Wellenbrett
pünktchen
Ich denke mal Apples Programmierer möchten mit der Whitelist verhindern dass Malware seine Überprüfung verhindert.
Ich denke auch, das könnte ein Interesse Apples sein. Dazu müsste zunächst jedoch entweder der Anwender unbeabsichtigt oder die Malware natürlich absichtlich die Little Snitch-Regeln verändern. Apple hat sicherlich auch eigennütziges Interesse …

Patrick Wardle (Objective-See, jamf) dazu aktuell via Twitter:
Patrick Wardle via Twitter, 14.11.2020
In Big Sur Apple decided to exempt many of its apps from being routed thru the frameworks they now require 3rd-party firewalls to use (LuLu, Little Snitch, etc.)

Q: Could this be (ab)used by malware to also bypass such firewalls?
A: Apparently yes, and trivially so
Q:
Patrick Wardle via Twitter, 14.11.2020
Demo: Big Sur Firewall Bypass
Q:
Patrick Wardle via Twitter, 14.11.2020
The (now confirmed?) security & privacy risks of this design decision, were of course communicated clearly to Apple prior to Big Sur's release @AppleSupport / FB8817119
Q:
-1
sierkb15.11.2015:02
Wellenbrett
Ich denke auch, das könnte ein Interesse Apples sein. Dazu müsste zunächst jedoch entweder der Anwender unbeabsichtigt oder die Malware natürlich absichtlich die Little Snitch-Regeln verändern. Apple hat sicherlich auch eigennütziges Interesse
blackboxberlin
Die Jungs von http://objective-see.com/ bspw. haben ein paar gute Apps und zumeist hilfreiche Hintergrundinfos!

Patrick Wardle (Objective-See, jamf) dazu via Twitter:
Patrick Wardle via Twitter, 14.11.2020
In Big Sur Apple decided to exempt many of its apps from being routed thru the frameworks they now require 3rd-party firewalls to use (LuLu, Little Snitch, etc.)

Q: Could this be (ab)used by malware to also bypass such firewalls?
A: Apparently yes, and trivially so
Q:
Patrick Wardle via Twitter, 14.11.2020
Demo: Big Sur Firewall Bypass
Q:
Patrick Wardle via Twitter, 14.11.2020
The (now confirmed?) security & privacy risks of this design decision, were of course communicated clearly to Apple prior to Big Sur's release @AppleSupport / FB8817119
Q:

[…]

Patrick Wardle/Objective-See: LuLu: Changelog :
Patrick Wardle/Objective-See – LuLu Changelog
VERSION 2.0.0 (11/12/2020)
Big Sur compatibility
ditched kext for Network Ext. Framwork
connection-level rules (multiple per process)
user specified block list
0
Wellenbrett15.11.2015:19
Ok. danke sierkb! Da muss ich mich erst einlesen. Mal sehen, wie das konkret funktioniert. Hast Du es schon verstanden?
0
X-Ray
X-Ray15.11.2017:16
Danke für die Zusatzinformationen.
Jetzt muss ich erst mal lesen - und verstehen 😇😁
„Planung ersetzt den Zufall durch Irrtum ( Einstein )“
0
pünktchen
pünktchen15.11.2023:13
Does Apple really log every app you run? A technical look

tldr; Nein
+2
MetallSnake
MetallSnake16.11.2006:05
Apple hat drauf reagiert: (ganz unten)
Gatekeeper performs online checks to verify if an app contains known malware and whether the developer’s signing certificate is revoked. We have never combined data from these checks with information about Apple users or their devices. We do not use data from these checks to learn what individual users are launching or running on their devices.
Notarization checks if the app contains known malware using an encrypted connection that is resilient to server failures.
These security checks have never included the user’s Apple ID or the identity of their device. To further protect privacy, we have stopped logging IP addresses associated with Developer ID certificate checks, and we will ensure that any collected IP addresses are removed from logs.
In addition, over the the next year we will introduce several changes to our security checks:
A new encrypted protocol for Developer ID certificate revocation checks
Strong protections against server failure
A new preference for users to opt out of these security protections
„Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.“
+8
Marcel_75@work
Marcel_75@work16.11.2009:15
Und in dem Zusammenhang sicher auch wichtig zu wissen: In "Big Sur" werden aktuell 56 Apple-eigene Apps/Prozesse speziell 'geschützt', so dass selbst Little Snitch & Co. deren Kommunikation 'nach draußen' nicht unterbinden kann.

Aber es gibt (wenn auch umständlich) einen 'workaround' dafür:

+1
DTP
DTP16.11.2010:02
MetallSnake
Apple hat drauf reagiert: (ganz unten)
Apple
In addition, over the the next year we will introduce several changes to our security checks:
[…]
  • A new preference for users to opt out of these security protections
Wow, das hätte ich nicht erwartet, denn normalerweise nimmt uns Apple ja an der Hand und zeigt uns, was gut für uns ist. Da haben die Proteste und der damit einhergehende mögliche Imageschaden vielleicht doch geholfen.

Chapeau Apple!
+1
Peter Eckel16.11.2010:28
Kurz zusammengefaßt:

• Apple will das OCSP-Protokoll zur Validierung der Softwarezertifikate durch ein verschlüsseltes Protokoll ersetzen. Das ist schon mal gut und sinnvoll. Das generelle Problem mit OCSP löst es nicht, aber das ist ja wie schon gesagt auch kein Apple-spezifisches und nicht so leicht aus der Welt zu räumen.

• Apple will eine Möglichkeit schaffen, die Gatekeeper-Prüfung wieder abzuschalten. Das begrüße ich sehr, und ehrlich gesagt überrascht es mich - ich war nicht davon ausgegangen, daß das kommen würde (wie ich ja auch weiter oben schrieb).

• Was mir leider immer noch fehlt ist eine Option, die Ausschlußliste für Netzfilter und VPNs zu umgehen oder ganz abzuschalten. Das ist eigentlich mein größter Kritikpunkt, zumal mir die entschieden zu lang ist. Aber das Problem ist eigentlich nicht wirklich der Inhalt der Liste, sondern ihre Existenz.

Andererseits: Zwei von drei in so kurzer Zeit ist schon mal nicht schlecht.
„Ceterum censeo librum facierum esse delendum.“
+4
Marcel_75@work
Marcel_75@work16.11.2010:52
Peter Eckel
• Was mir leider immer noch fehlt ist eine Option, die Ausschlußliste für Netzfilter und VPNs zu umgehen oder ganz abzuschalten.

Hatte ich 09:15 Uhr verlinkt, dort ist genau erklärt, wie man das (wie gesagt recht umständlich) hinbekommt:

0
beanchen16.11.2010:53
Peter Eckel
• Was mir leider immer noch fehlt ist eine Option, die Ausschlußliste für Netzfilter und VPNs zu umgehen oder ganz abzuschalten. Das ist eigentlich mein größter Kritikpunkt, zumal mir die entschieden zu lang ist. Aber das Problem ist eigentlich nicht wirklich der Inhalt der Liste, sondern ihre Existenz.
Irgendwelche Tools zu vermeintlichen Absicherung des Macs und/oder der eigenen Privatsphäre sind schnell installiert. Nur 99% der Mac-Besitzer haben keine Ahnung, was die eigentlich tun. Apple sichert unter anderem mit der Liste die Funktionalität des eigenen Systems. Wer einen Bedarf hat sich nicht ausschließlich auf Apples Versprechen der Privatsphäre zu verlassen, der wird entweder sein System ganz anders und extern absichern oder das Geld in die Hand nehmen und jemanden damit beauftragen.
Ich sehe immer noch nicht das Problem und würde mir wünschen, wenn du oder jemand anderes das mal anhand eines greifbaren Beispiel darstellen würdest.
„Unterwegs in Analogistan: https://www.zdf.de/comedy/heute-show/heute-show-spezial-vom-19-januar-2024-100.html“
0
Windwusel
Windwusel16.11.2012:22
Apple will bei App-Datenschutz nachbessern:
„MacBook Pro mit Touch Bar (15-inch, 2018), iPhone 12 Pro Max und iPhone X, AirPods (1. Gen) & AirPods Pro (1. Gen), Apple TV 4K (1. Gen) und HomePod (1. Gen)“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.