Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Nach Zertifikats-Desaster: Apple macht Rückzieher bei versprochener Systemeinstellung

Als Apple am 12.11.2020 das Upgrade auf macOS 11 (Big Sur) zum Download freigab, brach nach kürzester Zeit Chaos im Apple-Software-Universum aus. Zunächst scheiterte lediglich ein Download des Big-Sur-Installers. Doch weitete sich das Problem schnell aus: Titel aus dem iOS und Mac App Store ließen sich nicht herunterladen, iMessage zeigte sich unzuverlässig. Auch ohne Big Sur wurden Macs-Apps in Mitleidenschaft gezogen, ihr Start dauerte 10 bis 60 Sekunden. Schon bald offenbarte sich eine Störung der integrierten Zertifikatsüberprüfung (OCSP). Trotzdem dauerte es einen halben Tag, bis alle Dienste und Apps ihre Arbeit ohne merkliche Verzögerung verrichteten. Im Nachgang wollte Apple den Zertifikatsprozess überarbeiten. Nun stellt sich heraus: Apple löschte anscheinend lieber Spuren des damaligen Versprechens, als allen angekündigten Verbesserungen nachzukommen.


Infolge des mehrstündigen Ausfalls äußerten einige Mac-Entwickler Kritik an Apples Zertifikatsüberprüfung. Neben weitreichender Auswirkungen einer einzelnen Komponente habe die Online-Zertifizierung in macOS wie iOS einige Schwachstellen, was die Privatsphäre anginge. So laufe der Überprüfungsprozess unverschlüsselt ab; außerdem konnten Mac-Anwender den Zertifizierungsvorgang nicht temporär deaktivieren. Einzige Abhilfe stellte ein Trennen der Internetverbindung dar. Apple versprach, binnen Jahresfrist strukturelle Probleme zu beseitigen, namentlich:

- Ein neues verschlüsseltes Protokoll für die Überprüfung der Entwickler-ID
- Stabiler Schutz vor Server-Versagen
- Eine neue Voreinstellung für Anwender, sich von diesen Sicherheitsüberprüfungen abzumelden.

Keine Spur seit September 2023
Der Entwickler Jeff Johnson hat indessen entdeckt, dass Apple dieses Versprechen klammheimlich von seinen Support-Seiten entfernt hat. Zur Veröffentlichung von macOS 14 (Sonoma) bearbeitete Apple das entsprechende Hilfe-Dokument. In der Wayback Machine des Internet Archive konnte er dies nachvollziehen. Sein Vorwurf: Apple wolle offenbar Spuren der dritten Ankündigung verwischen, die bis heute nicht umgesetzt wurde.

Mindestens ein Versprechen eingehalten
Der erste Punkt scheint in den folgenden Updates umgesetzt worden zu sein, gesteht Johnson ein: Apple verschlüssele den Datenaustausch zwischen Mac und OCSP-Server mittlerweile. Ob ein zuverlässiger Schutz vor einem erneuten Versagen des Servers bestünde, ließe sich von außen nicht beurteilen. Dass Apple aber in Monterey, Ventura, Sonoma und dem bald erscheinenden Sequoia keine Option zum Deaktivieren der Zertifikatsüberprüfung integriert habe, sei offensichtlich, so Johnson. Um einen Datenaustausch mit Apples Zertifikatsservern beim Start einer App zu verhindern, müsse man Apps wie Little Snitch verwenden, so der Indie-Entwickler.

Kommentare

Rosember13.08.24 17:15
Ich weiß nicht, ob das etwas miteinander zu tun hat, aber es nervt auch, dass die gültigen Zertifikate von Sybology-NAS nicht akzeptiert werden und der Zugang per Safari nur durch Einschränkung der Sicherheit möglich ist (jedenfalls bei mir, trotz Befolgen der Synology-Anleitung).
-5
Marcel Bresink13.08.24 18:12
Rosember
Ich weiß nicht, ob das etwas miteinander zu tun hat

Das hat überhaupt nichts miteinander zu tun. Im Artikel geht es darum, dass Apple möglicherweise gegen den Datenschutz verstößt, weil sie bei jedem Aufruf einer App persönliche Daten des Aufrufers sammeln.

Zum Problem: Es reicht normalerweise nicht aus, dass ein Zertfikat gültig ist, denn Jeder kann Zertifikate erstellen und unterschreiben.

Damit ein Zertifikat als sicher gilt, muss das prüfende Programm die gesamte Kette der Zertifikatsaussteller kennen und alle deren Zertifikate müssen ebenso gültig sein.
+2
ruphi
ruphi13.08.24 19:54
MTN
Der erste Punkt scheint in den folgenden Updates umgesetzt worden zu sein, gesteht Johnson ein
[language matters] Tatsächlich muss der Entwickler hier nichts eingestehen, denn er hat es ja nie geleugnet. Lediglich Apple müsste eingestehen, den dritten Punkt nicht umgesetzt zu haben, nachdem es versprochen wurde.
Ich finde das wichtig, um klarzustellen, dass der Entwickler hier einen berechtigten Vorwurf erhebt.
+1
aMacUser
aMacUser14.08.24 11:22
Marcel Bresink
Rosember
Ich weiß nicht, ob das etwas miteinander zu tun hat

Das hat überhaupt nichts miteinander zu tun. Im Artikel geht es darum, dass Apple möglicherweise gegen den Datenschutz verstößt, weil sie bei jedem Aufruf einer App persönliche Daten des Aufrufers sammeln.
Nein, das hat ebenfalls nichts mit dem Artikel zu tun. Der Artikel spricht davon, dass macOS bei jedem Start eine App prüft, ob diese noch valide ist, bzw. der Entwickler der App noch vertrauenswürdig ist. Das hat mal für einen halben Tag nicht funktioniert und für Chaos gesorgt. Apple macht daraufhin drei Versprechen, um den Prüfungsprozess zu verbessern. Das dritte Versprechen scheinen sie jetzt zu ignorieren.
Den Teil mit dem Datenschutzproblem wegen unverschlüsselter Kommunikation hat Apple behoben.
+1
Megaseppl14.08.24 14:15
Rosember
Ich weiß nicht, ob das etwas miteinander zu tun hat, aber es nervt auch, dass die gültigen Zertifikate von Sybology-NAS nicht akzeptiert werden und der Zugang per Safari nur durch Einschränkung der Sicherheit möglich ist (jedenfalls bei mir, trotz Befolgen der Synology-Anleitung).

Auch wenn das tatsächlich nix mit dem Thema zu tun hat:
Das Synology-Default-Zertifikat, von dem Du sprichst, ist _nicht_ gültig in diesem Kontext.
Ein Browser validiert bei einem TLS-Zertifikat nicht nur das Gültigkeitsdatum (in dem Aspekt ist das Synology-Zertifikat ok), sondern auch die URL über die es aufgerufen wird. Egal ob du deine NAS über dessen IP oder einen lokalen Host-Namen aufrufst: Das Synology-Zertifikat ist dafür nicht zugelassen, da es nicht den Domain Namen deiner NAS enthält - und kann es auch niemals, es sei denn du kaufst bzw. lässt gültige Zertifikate für die Domain deiner NAS generieren.
Valide Zertifikate (sicher) im LAN zu nutzen ist komplex/aufwändig: Erfordert eine gültige Domäne im LAN mit einem lokalen DNS oder eine eigene lokale Zertifizierungsstelle mit entsprechender Vertrauensstellung der Clients.
Mit einem Let's Encrypt Reverse Proxy kann man das durchaus sogar kostenlos im LAN machen (hab ich auch so, ein solches Proxy-Programm auch vor Jahren mal geschrieben und bei Github hochgeladen, allerdings für Windows/IIS als "Zwischenwirt"), aber in aller Regel lohnt der Aufwand überhaupt nicht bei Privatnutzern oder kleinen Usergruppen.
Die Warnmeldung im Browser und das Akzeptieren des Zertifikats-Sicherheitsproblems sorgt übrigens nicht dafür, dass du unverschlüsselt kommunizierst: TLS-Verschlüsselung funktioniert hier trotzdem! Nur meckert der Browser halt weil er den Hostnamen der NAS nicht mit dem Zertifikat validieren. Innerhalb eines privaten LANs, ist dies aber ein zu vernachlässigendes Problem.

Ich habe auf meinen Synologies privat und in der Firma überall eigene, weltweit gültige Zertifikate installiert mit deren jeweiligen (Sub-)Domain-Namen. Gehe ich allerdings über die IP statt über den Domain-Namen auf das Gerät, bekomme ich auch dann wieder die Dir bekannte Fehlermeldung. Grund hier: Für IP-basierte Adressen können grundsätzlich keine (öffentlichen) Zertifikate erzeugt werden.
+1
Rosember14.08.24 14:59
Megaseppl:
Danke dir sehr für die Auskunft. Dass es im privaten Netzwerk unproblematisch ist, habe ich schon vermutet. Aber es nervt dennoch, die Freigabe wöchentlich zu erneuern. Seltsam auch, dass Synology in seinen Ausführungen zu Zertifikaten nicht näher auf das problem eingeht.
0
Megaseppl14.08.24 16:55
Rosember
Megaseppl:
Danke dir sehr für die Auskunft. Dass es im privaten Netzwerk unproblematisch ist, habe ich schon vermutet. Aber es nervt dennoch, die Freigabe wöchentlich zu erneuern. Seltsam auch, dass Synology in seinen Ausführungen zu Zertifikaten nicht näher auf das problem eingeht.
Das sollte eigentlich nicht so häufig passieren. "Gefühlt" ändert Synology das Zertifikat seltener. Natürlich muss man es dann auf jedem Gerät erneut akzeptieren. Das Zertifikat von denen hat auch immer eine Laufzeit von 12 Monaten. Ich hätte eher gesagt, dass vielleicht alle 6 Monate mal deren eigenes Zertifikat getauscht wird.
Genauer kann ich sagen, wie oft es bei mir getauscht wird (Let's Encrypt-Zertifikat). Hier der Verlauf der letzten 12 Monate (ist aber nicht vergleichbar, da ich wie gesagt ein eigenes, valides Zertifikat verwende):

Hier waren es 7 Zertifikatserneuerungen in den letzten 365 Tagen. Das Zertifikat von Synology selbst sollte aber eigentlich weit seltener getauscht werden.
0
sudoRinger
sudoRinger14.08.24 17:45
Hier ist erklärt, wie man ein Wildcard Zertifikat für eine Synology-Domain einrichtet Mit einem Reverse Proxy kannst du dann, z.B. cloud.rosember.synology.me, nas.rosember.synology.me usw. einrichten. Alle haben ein gültiges Let's Encrypt-Zertifikat.
0
Rosember14.08.24 17:50
Megaseppl
Bei mir findet sich leider überhaupt kein Synology-Zertifikat auf dem Rechner oder zumindest im Schlüsselbund. Ich schalte die beiden NAS-Seiten jede Woche in Safari frei – und entsprechend beschwert sich Safari sobald die Freigaben wieder verfallen. Und so st es schon seit Jahren, obwohl ich den Anleitungen von Synology genau gefolgt bin. Hast du vielleicht einen Tipp? Wie hast Du das hinbekommen? – Meine Zertifikate sind nämlich eigentlich auch noch lange gültig, aber Apple sieht und akzeptiert die nicht, warum auch immer.
0
Rosember14.08.24 17:51
sudoRinger
Hier ist erklärt, wie man ein Wildcard Zertifikat für eine Synology-Domain einrichtet Mit einem Reverse Proxy kannst du dann, z.B. cloud.rosember.synology.me, nas.rosember.synology.me usw. einrichten. Alle haben ein gültiges Let's Encrypt-Zertifikat.
Danke! Schaue ich mir mal an!
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.