Degenen die online diensten maken en onderhouden hebben het het er zelden over hoe moeilijk het kan zijn om alles werkend te houden maar de realiteit is dat websites en andere internet-diensten veel onderhoud vereisen. We hebben de laatste tijd verschillende incidenten gehad die je misschien zijn opgevallen.

TidBITS#1683 probleem met aflevering van e-mail

De e-mailuitgave van TidBITS#1683 van vorige week had een afleverprobleem dat we niet hebben kunnen oplossen of reproduceren. Na het versturen naar ongeveer 19.000 mensen begon Sendy, de app die uitgaande e-mailberichten beheert op basis van adressen van onze WordPress-server, 403- of 503-fouten te ontvangen bij het doorsturen van individuele berichten naar Amazon's Simple Email Service (SES) voor aflevering. Bij Amazon SES konden we niets vinden en met de overige 5.500 adressen was er niets aan de hand. Daaropvolgende verzendingen van individuele artikelen naar TidBITS-leden en van onze Nederlandse en Japanse vertalingen werkten prima. Na bijna een week hadden we niets meer te proberen, dus annuleerden we de resterende verzendingen van TidBITS#1683 om te voorkomen dat Sendy de schijf zou vullen met foutenlogboeken.

Het resultaat is dat als je de e-mailuitgave van vorige week niet hebt ontvangen, mijn excuses! Je kan TidBITS#1683 op onze website lezen, samen met alle andere oude nummers. Ik hoop oprecht dat alles beter werkt voor TidBITS#1684, omdat er vóór de laatste uitgave niets is veranderd en sindsdien hebben we ook niets veranderd. We zijn van plan binnenkort een update voor Sendy te installeren maar aangezien we nog nooit eerder een probleem hebben gehad, is het moeilijk voor te stellen dat deze de door kosmische straling veroorzaakte problemen van vorige week zal oplossen.

E-mailverificatie voor nieuwe accounts

Een paar maanden geleden hebben we e-mailverificatie voor nieuwe accounts geïmplementeerd. Jarenlang voerden we een verloren strijd tegen spambots die duizenden nepaccounts in ons WordPress-systeem aanmaakten. Ik weet niet waarom ze dit doen, aangezien deze accounts geen noemenswaardige mogelijkheden hebben. Ik vermoed dat we slechts een van de willekeurige slachtoffers waren van rondzwervende spambots die een WordPress-server hebben gedetecteerd.

Spambots kunnen dit doen omdat WordPress potentiële gebruikers standaard direct accounts laat aanmaken. We hadden verschillende vormen van beveiliging: de plug-in Stop Spammers, niet-standaard URL's, reCAPTCHA en meer, maar niets heeft de spambots tegengehouden of zelfs maar echt vertraagd. En voor de duidelijkheid: het was verschrikkelijk. Op het hoogtepunt maakten de spambots dagelijks honderden accounts aan. Zelfs het identificeren van de weinige legitieme accounts en het verwijderen van de valse accounts was moeilijk.

Uiteindelijk hebben we de WordPress-plug-in User Verification geïnstalleerd. Het verhindert niet dat spambots accounts aanmaken maar nieuwe accounts worden gemarkeerd als Niet-geverifieerd totdat de gebruiker op een link in een e-mailbevestigingsbericht klikt. Hoewel het denkbaar is dat een spambot zich op een gecompromitteerd e-mailadres kan abonneren en vervolgens op de link in het ontvangen bevestigingsbericht kan klikken, doen de meeste dat niet. Ik hoopte dat we, nadat we al onze bestaande gebruikers als Geverifieerd hadden gemarkeerd en vertrouwd waren geraakt met Gebruikersverificatie, de optie konden inschakelen om automatisch accounts te verwijderen die na enige tijd niet-geverifieerd bleven.

Helaas, het mocht niet zo zijn. Om redenen die we nooit hebben ontdekt, werden, toen ik die functie inschakelde, 17 accounts verwijderd die waren gemarkeerd als Geverifieerd en verbonden met echte mensen. Ik kan er niet op vertrouwen dat er geen accounts meer worden verwijderd, dus ben ik teruggevallen op het handmatig verwijderen van spambot-accounts.

Wat ik echt wil is een systeem dat een met tokens beveiligde link e-mailt naar iemand die zijn e-mailadres opgeeft in een abonnementsformulier maar het account pas aanmaakt als de gebruiker handmatig op die link klikt. Dat is niet iets dat ik heb kunnen vinden in de wereld van WordPress-plug-ins en onze ontwikkelaar heeft momenteel geen tijd om zo’n systeem te bouwen. Suggesties zijn welkom.

Doordat ik kon zien welke accounts gemarkeerd bleven als Niet-geverifieerd, werd het proces van het verwijderen van de spambot-accounts een beetje vereenvoudigd en terwijl ik dat deed, merkte ik enige overeenkomst op tussen de IP-adressen die aan de spambot-accounts waren gekoppeld. (Stop Spammers geeft het bron-IP-adres weer in de WordPress-gebruikerslijst.) Toen ik ze opzocht, ontdekte ik dat veel ervan werden beheerd door een Russische ISP genaamd Biterika Group. Hoewel Scamalytics deze Biterika Group momenteel als een laag frauderisico beschouwt, was het destijds zeker verantwoordelijk voor de spambots die mijn server aanvielen. Mijn pogingen om bepaalde domeinen en Rusland als land te blokkeren met behulp van Stop Spammers hadden weinig effect, waardoor ik zo gefrustreerd en boos werd dat ik besloot om nucleair te gaan en hele IP-adresreeksen te blokkeren. Dat is over het algemeen een slecht idee omdat het legitieme gebruikers kan beïnvloeden en omdat de lijst moeilijk te beheren is. Maar ja.

(Trouwens, de truc om een groot deel van de 46.000 IP-adressen die gecontroleerd worden door Biterika te blokkeren, was CIDR-notatie. CIDR is een afkorting van Classless Inter-Domain Routing en is een methode om IP-adressen aan te duiden, waarbij een enkel IP-adres vele unieke IP-adressen met CIDR kan toekennen. Een CIDR IP-adres ziet er uit als een regulier IP-adres met een ‘/’ (slash) erachter, gevolgd door een getal dat het IP-netwerkprefix heet. Bijvoorbeeld: een aantal van de Biterika IP-adressen zaten rond de 109.248.204.0 en door 109.248.204.0/23 aan mijn Stop Spammers-bloklijst toe te voegen, wordt voorkomen dat spambots uit dat IP-bereik iets op mijn site zouden kunnen aanrichten. Ik gebruik deze CIDR-naar-IPV4-calculator om de juiste IP-netwerkprefix te bepalen.)

Het blokkeren van alle Biterika IP-adressen ging zo goed dat ik begonnen ben met het controleren van IP-adressen op alle spambot-accounts en ze toe te voegen aan de bloklijst als ze niet uit een land kwamen waar Engels, Nederlands of Japans gesproken wordt. Ik ben me volledig bewust van de mogelijke gevolgen en als een TidBITS-lezer die geblokkeerd is via e-mail contact met me opneemt, zal ik de beledigende IP-adresreeks verwijderen.

Gebruikers verplichten om op een link in een bevestigingsbericht te klikken in combinatie met het blokkeren van IP-adressen van spambots is zeer effectief gebleken. Een paar spambot-accounts zullen er zeker doorheen glippen maar een handvol per week kan ik wel aan vergeleken met honderden per dag.

Vanuit het oogpunt van de gebruiker hebben we enkele tegenslagen gehad en ik ben Lauri Reinhardt dan ook enorm dankbaar voor de manier waarop ze gebruikers geholpen heeft en voor het ontrafelen van onverwachte grillen, alsook Eli Van Zoeren voor hoe hij gewerkt heeft om alles technisch te installeren en configureren. Het heeft een tijd geduurd om de e-mailverificatieopties correct te configureren, conflicten op te lossen als gevolg van plug-ins die CAPTCHA-controle bieden, gebroken registratieknoppen diep in de site te verwijderen, de interactie tussen de TidBITS- en TidBITS Talk-sites (die een gezamelijk inlogsysteem hebben) uit te zoeken en verschillende randgevallen aan te pakken. Zelfs nu maken we ons nog zorgen dat er een fout zit in de gebruikersverificatie waardoor sommige accounts als ongeverifieerd worden gemarkeerd na het handmatige vernieuwen van het lidmaatschap, maar we hebben die fout nog niet op kunnen sporen.

Bestaande gebruikers zouden vrijwel geen last moeten hebben van deze wijzigingen, maar als je problemen ondervindt bij het gebruik van onze sites, laat het ons dan weten via [email protected]. We willen graag dat alles werkt!

Apple heeft updates uitgebracht voor al zijn huidige besturingssystemen (en macOS 13 Ventura), behalve tvOS. Ze zijn ontworpen om een handvol problematische bugs op te lossen die verband houden met updaten, de levensduur van de batterij en de betrouwbaarheid van Siri, hoewel ze mogelijk ook beveiligingsproblemen aanpakken die Apple zelf heeft ontdekt. Er zijn geen gepubliceerde CVE-vermeldingen.

iOS 17.1.1 en iPadOS 17.1.1

In iOS 17.1.1 zijn twee bugs verholpen, en iPadOS 17.1.1 lift mee op een van die oplossingen. Ten eerste zegt Apple dat Apple Pay en andere NFC-functies mogelijk niet meer beschikbaar zijn op iPhone 15-modellen na draadloos opladen in bepaalde auto's. (MacRumors zegt dat het BMW was.) Ten tweede kwamen de technici van Apple net op tijd in actie om de Weer-widget voor het toegangsscherm te repareren, die sneeuw niet altijd correct weergaf. 🌨

Tenzij je draadloos opladen in jouw auto gebruikt en afhankelijk bent van Apple Pay, raad ik je aan te wachten met het installeren van deze updates tot een moment dat het schikt.

macOS 13.6.2 Ventura

In de toelichting bij macOS 13.6.2 staat dat deze versie belangrijke oplossingen voor beveiligingsproblemen biedt en wordt aanbevolen voor alle gebruikers, maar dat lijkt niet helemaal juist. Op de pagina 'Beveiligingsreleases' van Apple wordt macOS 13.6.2 vermeld als alleen van toepassing op de “MacBook Pro (2021 en nieuwer) en iMac (2023)”. Het wordt dus niet voor alle gebruikers aanbevolen, en op mijn 27 inch-iMac uit 2020 wordt de update zelfs niet eens aangeboden.

Mr. Macintosh verdient echter een compliment omdat hij in Apples toelichting voor bedrijven voor Ventura heeft ontdekt dat in macOS 13.6.2 ook een bug verholpen is waardoor 14 inch- en 16 inch-MacBook Pro's met Apple silicon opstartten met een zwart scherm of een omcirkeld uitroepteken nadat de standaard vernieuwingsfrequentie van het ingebouwde beeldscherm was gewijzigd.

Bovendien schrijft Howard Oakley, hoewel ik niet weet waar hij die informatie vandaan heeft, dat macOS 13.62 twee update-problemen verhelpt:

• MacBook Pro-modellen met Apple silicon kunnen problemen ondervinden tijdens het updaten naar macOS 13.6.1, wat resulteert in een foutmodus met een zwart scherm.
• Sommige zojuist uitgebrachte 24 inch-M3-iMacs worden geleverd met macOS 13 Ventura geïnstalleerd in plaats van macOS 14 Sonoma. Dat is een gênante misstap van Apple, maar erger nog is het feit dat ze niet konden worden bijgewerkt of geüpgraded met behulp van updates.

Je hoeft macOS 13.6.2 niet te installeren, tenzij je van plan bent een MacBook Pro met Apple silicon te updaten naar macOS 13.6.1 of net een M3-iMac hebt gekocht die met Ventura is geleverd. Als ik het mocht zeggen, zou ik deze installeren, gewoon om dat maar gedaan te hebben.

macOS 14.1.1 Sonoma

Apple zegt alleen dat macOS 14.1.1 “verbeteringen, probleemoplossingen en beveiligingsupdates voor je Mac” bevat. Gezien wat Howard Oakley zegt over de M3-iMacs, vermoed ik dat macOS 14.1.1 bedoeld is om die gebruikers te laten upgraden naar Sonoma.

Craig Hockenberry meldt ook dat macOS 14.1.1 een macOS 14.1 window server-fout verhelpt die invloed had op de hulpfuncties in zijn app xScope en, wat waarschijnlijk deze snelle actie van Apple verklaart, Photoshop.

Het is niet te zeggen hoeveel apps last hebben van deze fout dus ik raad je aan snel te updaten, met name als je ongebruikelijk gedrag ziet van grafische apps.

watchOS 10.1.1

Bijna iedere iOS- of watchOS-update leidt tot klachten van gebruikers over een kortere batterijduur. Doorgaans zijn deze problemen snel opgelost als het besturingssysteem klaar is met caches en indexen opbouwen. Soms zijn echte fouten de oorzaak en dat lijkt ook hier het geval te zijn, want watchOS 10.1.1 “biedt belangrijke probleemoplossingen en verhelpt een probleem dat ertoe kon leiden dat de batterij sneller leegraakte”.

Ik ga deze direct installeren. Het zal niet verbazen dat mijn nieuweApple Watch Series 9 een uitstekende batterijduur had sinds ik hem kreeg, maar gisteren was hij na mijn fietstocht bijna leeg. Misschien had ik hem de avond ervoor niet juist op de oplader gelegd, maar als Apple zegt dat een update onnodig leeglopen van de batterij verhelpt dan klik ik direct op de Installeer-knop.

HomePod Software 17.1.1

Tijdens de pandemie installeerde ik een hoop HomeKit-schakelaars, dus wij zijn er thuis aan gewend het licht te bedienen met Siri op een originele HomePod. (Zie “Een jaar met HomeKit: een terugblik”, 17 december 2021.) Als je iedere keer met Siri praat als je iets aan je verlichting wilt veranderen, krijg je wel een beeld van hoe goed dat werkt. (Oké, ik geef toe dat, hoewel ik er bij het schrijven zoveel mogelijk voor probeer te waken, wij thuis Siri in het dagelijks leven volledig antropomorfiseren, zoals toen Tonya gisteravond geërgerd uitriep: Ze is vandaag wel heel erg dom”.)

Dus ja, ook al hebben we geen harde statistische gegevens, ons gevoel is dat Siri's betrouwbaarheid bij het uitvoeren van gewone HomeKit-commando's na het uitkomen van HomePod Software 17 verslechterd is. Soms moeten we twee of zelfs drie keer vragen voordat Siri het commando herkent. Het is niet zo erg dat we meteen maar naar de lichtknop lopen en deze handmatig bedienen, maar ik ga HomePod Software 17.1.1 wel meteen installeren op onze HomePods, temeer omdat Apple zegt dat het “een probleem [verhelpt] dat ertoe kon leiden dat sommige HomePod-luidsprekers traag reageerden of verzoeken niet volledig afhandelden”.

Een paar weken geleden vroegen we hoe vaak je Finder-tags gebruikt. Ik ben er eigenlijk sinds het begin (ze werden geïntroduceerd in OS X 10.9 Mavericks) al niet zo'n fan van, dus het verraste me niet dat 56% van de respondenten ze nooit gebruikt. 26% gebruikt ze af en toe, en 18% regelmatig. Maar misschien mist de meerderheid wel wat.

Uitgangspunten van Finder-tags

Het doel van Finder-tags is een alternatieve manier te bieden voor het ordenen van bestanden en mappen, naast de traditionele mappenhiërarchie. Een bestand kan slechts in een enkele map staan (hoewel je natuurlijk aliassen kan maken) terwijl een enkel bestand zoveel tags kan hebben als je wil. Hiermee wordt het mogelijk om bestanden die verspreid over verschillende mappen staan, of juist een klein aantal bestanden binnen een omvangrijke verzameling, toch bij elkaar te brengen.

Stel je voor dat je een map hebt met een paar honderd afbeeldingen en dat je er een paar wilt kiezen om op een website te gebruiken. Als je de weergave verandert naar Galerij kun je snel door de foto's heen gaan en een tag plaatsen op die foto's die je mooi vindt. Gebruik hiervoor het informatievenster of control-klik op het bestand en kies dan een tag uit het contextuele menu. Er zijn ook veel andere manieren om tags toe te passen.

Zodra je dat gedaan hebt kun je alleen die foto's laten zien door de kolom Tags toe te voegen aan de lijstweergave (control-klik op een van de kolommenheaders en kies voor Tags) en vervolgens erop te klikken om het op Tags te sorteren. Of je kunt een tag in de navigatiekolom van een Findervenster zetten door de tag aan te vinken onder Finder > Instellingen > Tags. Ook hier zijn veel andere manieren. Als je de tags niet meer nodig hebt verwijder je ze op dezelfde manier.

Voor meer details over het gebruik van tags verwijzen we naar het uitgebreide artikel van Josh Centers: “Alles over het taggen in de Mavericks-Finder” (14 november 2013). De details zijn in de afgelopen tien jaar misschien iets veranderd, maar het meeste is nog van toepassing. Howard Oakley schreef recentelijk ook over Finder-tags en Jeff Carlson heeft een paragraaf aan tags gewijd in Take Control of Managing Your Files.

Veelvoorkomende toepassingen van tags

Uit de reacties op onze peiling bleek dat tags voor sommige mensen en teams essentieel zijn. Zo schreef Gobit:

Op het werk gebruik ik ze voortdurend (ik heb een ontwerpstudio en maak materiaal klaar om af te drukken). Iedere opdracht krijgt een eigen map, iedere map komt op een server, en iedere map wordt getagd met een kleur en initialen. Dan kan ik snel zien wie (of welke groep) verantwoordelijk is voor de meer dan 600 actieve opdrachten op een bepaald moment.

En Anton Rang zei:

Ik heb duizenden technische documentatie en honderden documenten over standaarden op mijn Mac. Door de laatste te taggen kan ik een Spotlight-zoekopdracht eenvoudig tot die groep beperken. Ik gebruik tags ook bij andere zoekopdrachten (een bepaalde subgroep van standaarden bijvoorbeeld, of documenten van een bepaalde producent, en soms voor specifieke projecten).

Maar het kwam vaker voor dat mensen tags slechts af en toe gebruiken. Bijvoorbeeld op een van de volgende manieren:

• Tijdelijk documenten taggen zodat ze opvallen in een map
• Specifieke tags toekennen aan bestanden waar nog aan gewerkt wordt en documenten die afgerond zijn
• Tags gebruiken voor belangrijke bestanden die regelmatig nodig zijn
• Veelgebruikte mappen een specifieke tag geven zodat je ze makkelijk kunt herkennen
• Bestanden taggen die waarschijnlijk binnenkort weggegooid kunnen worden
• Tags gebruiken voor documentenbeheer, zodat je de laatste versie kunt onderscheiden van eerdere versies
• Bestanden die bij een specifieke klant horen een bepaalde tag geven
• Gerelateerde bestanden taggen die in verschillende mappen staan

Lees vooral alle reacties om meer praktijkvoorbeelden te zien van hoe mensen tags gebruiken.

Problemen met Finder-tags

Sommige mensen hebben geprobeerd Finder-tags te gebruiken, maar zijn daarmee gestopt vanwege bepaalde problemen:

• Te weinig kleuren: standaard biedt de Finder zeven tags aan: Red, Orange, Yellow, Green, Blue, Purple en Gray. (Het is jammer dat het ezelsbruggetje Roy G. Bpg niet zo makkelijk over de tong rolt als die voor de kleuren van de regenboog, Roy G. Biv.) Je kunt de tags een andere naam geven (hoewel er weinig reden is om dat te doen) maar je kunt geen andere kleuren kiezen. Omdat de kleuren de belangrijkste manier zijn om getagde bestanden te herkennen, is zeven kleuren onnodig beperkend.
• Het is moeilijker om getagde bestanden te herkennen dan in het begin: verscheiden mensen merkten op dat, nu niet meer de hele naam van een bestand met de corresponderende kleur van een tag aangemerkt wordt maar nog slechts een kleine gekleurde cirkel gebruikt wordt, de tags minder makkelijk te herkennen zijn. Het grootste voordeel van de cirkels is dat je eenvoudig bestanden met meerdere tags herkent.
• Tags overleven niet alle kopieeracties: bij het testen onder de huidige versies van Dropbox, Google Drive en iCloud Drive werden tags alleen naar een andere Mac (ingelogd op hetzelfde account) gekopieerd als ze verplaatst werden met Dropbox of iCloud Drive. In het geval van Google Drive leken de tags alleen zichtbaar te zijn op de Mac waarop ze aangebracht waren. Net zo verliezen getagde bestanden de tags tenzij de software die de bestanden verplaatst metadata ondersteunt. Tags kunnen getoond worden op andere apparaten, zoals in de app Bestanden op een iPad, maar zijn niet altijd consistent in andere diensten dan iCloud Drive.
• Tags van iemand met wie je samenwerkt kunnen je verzameling tags doorkruisen: als je een map met iemand deelt via Dropbox (maar interessant genoeg niet iCloud Drive) worden tags die die persoon aan bestanden heeft toegekend automatisch aan jouw verzameling tags toegevoegd. Dat is ook het geval voor getagde bestanden die je deelt met een USB-drive of op een andere manier waarbij metadata ondersteund worden. Dit is aan de ene kant logisch als tags onderdeel zijn van een bepaalde workflow bij het samenwerken, maar het kan ook betekenen dat je verzameling tags gaat bevatten die betekenisloos voor jou zijn omdat ze van anderen komen.
• Spotlight heeft soms problemen: hoewel diegenen die flink gebruikmaken van tags maar weinig problemen lijken te ondervinden, is bij anderen Spotlight minder snel en betrouwbaar in het vinden van tags. Ook al is Spotlight bijna altijd betrouwbaar, de zorg dat er misschien tags gemist worden is voor sommigen een te grote drempel om hun gegevens op andere manieren te ordenen dan veilig met map- en bestandsnamen.

Persoonlijk heb ik hernieuwde waardering gekregen voor hoe ik Finder-tags zou kunnen gebruiken. Ik zal nooit een zware gebruiker worden omdat ik te afhankelijk ben van Google Drive, waarbij tags tussen Macs verloren gaan, maar ik vond het de afgelopen tijd handig om bestanden te taggen die ik maar tijdelijk wilde bewaren. Nu ik door deze peiling weer aan tags herinnerd werd zal ik ook bekijken of andere aspecten van mijn workflow misschien met doordacht gebruik van tags verbeterd kunnen worden. Hopelijk helpt het jou ook om aan tags te denken als ze een keer nuttig zouden kunnen zijn.

Apple vertrouwt op steeds verder verouderde opvattingen over end-to-end-versleuteling voor het uitwisselen van berichten tussen jou en andere mensen. Terwijl het bedrijf regelmatig oplossingen biedt om de beveiliging en privacy voor iMessage en de bijbehorende Berichten-app te verbeteren, heeft het de lessen en innovaties uit de branche niet opgevolgd. Apple belooft dit jaar een belangrijk onderdeel van iMessage te veranderen door een optionele functie toe te voegen die momenteel al beschikbaar is voor de ontwikkelaarsbèta’s van iOS 17.2, iPadOS 17.2, macOS 14.2 en watchOS 10.2. Het bedrijf heeft op 27 oktober 2023 op het blog van Apple Security Research het proces en de tijdlijn hiervan aangekondigd.

De functie heet Sleutelverificatie van contacten en doet zijn naam eer aan: je kunt een handmatige verificatiestap aan een iMessage-gesprek toevoegen om te bevestigen dat de andere persoon is wie het apparaat zegt dat zij zijn. (SMS-gesprekken hebben geen betrouwbare verificatiemethode, excuses aan onze vrienden in de groene bubbels). In plaats van te vertrouwen op Apple om de identiteit van de andere persoon te controleren aan de hand van informatie die veilig opgeslagen is op de servers van Apple, lezen jij en de andere partij elkaar een korte verificatiecode voor, face to face of tijdens een telefoongesprek. Zodra je het gesprek hebt gevalideerd, onderhouden beide apparaten een vertrouwensketen waarin noch jij noch de andere gebruiker persoonlijke versleutelingsgegevens aan elkaar of aan Apple heeft gegeven. Als er iets verandert in de encryptiesleutels die jullie hebben geverifieerd, zal de Berichten-app dit opmerken en een waarschuwing geven.

Apples bericht is geschreven voor de beveiligingsgemeenschap, en verwijst dan ook naar talrijke complexe cryptografieconcepten. Omdat Sleutelverificatie van contacten alleen bedoeld is voor mensen die belangrijke redenen hebben om aan te nemen dat vijandige partijen met significante middelen hun communicatie willen compromitteren, zal ik drie niveaus van uitleg geven: het eerste is een kort overzicht, het volgende geeft meer details en het laatste gaat dieper in op de onderbouwing.

Eerst en vooral wil ik duidelijk stellen dat er maar weinig mensen zijn die dit niveau van berichtbeveiliging nodig hebben. Als je een journalist, publiek figuur, voorvechter van mensenrechten, politicus, bekende financier of ander mogelijk doelwit van dieven, overheden of technisch onderlegde stalkers bent, lijkt het extra veiligheidsniveau van Sleutelverificatie van contacten misschien een uitkomst. De rest van ons kan beslissen of we ons genoeg zorgen maken over de kleine kans dat iemand zich als iemand anders voordoet in een iMessage-gesprek om de extra verificatiestap te accepteren.

Alleen de feiten

Toen je iMessage voor het eerst ging gebruiken binnen Berichten, heeft Apple je apparaat een versleuteling laten instellen, waarvan een openbaar deel wordt gedeeld met Apple, die het namens jou opslaat. Dat openbare gedeelte van de versleuteling helpt Apple bij het maken van een beveiligde verbinding wanneer je een Berichten-chat hebt met blauwe-bubbelvrienden.

Met Sleutelverificatie van contacten ga je een stap verder om imitatie te detecteren en te voorkomen: jij en de persoon met wie je communiceert verifiëren jullie identiteiten in Berichten. Dit doe je door een numerieke code te delen waarmee je handmatig cryptografisch vertrouwen kunt opbouwen tussen je accounts en apparaten.

Als er iets is dat het cryptografische vertrouwen verbreekt, wordt de Berichten-app hiervan op de hoogte gebracht - Apple hoeft zich hier niet mee te bemoeien. Berichten waarschuwt jou, de andere partij of jullie allebei met een bericht waarin wordt uitgelegd waarom, en het stelt acties voor die je kunt ondernemen nu je de verbinding niet langer kunt vertrouwen.

High-level rondleiding door Sleutelverificatie van contacten

Laten we eens in een beetje meer detail kijken naar elke stap van hoe Sleutelverificatie van contacten werkt.

• Nu worden alle iMessage gesprekken end-to-end beveiligd door een van je apparaten in eerste instantie een publiek-privé sleutelpaar te laten maken. Het bewaart, beveiligt en synchroniseert de privésleutel tussen je apparaten en deelt de openbare sleutel met Apple. Apple bewaart de openbare sleutel in een sleuteldirectory waarmee het iMessage-deelnemers kan verbinden.
• Met Sleutelverificatie van contacten genereren je apparaten een andere encryptiesleutel die alleen tussen je apparaten veilig wordt gesynchroniseerd en op geen enkele manier met Apple wordt gedeeld. Die nieuwe sleutel wordt gebruikt om je eerder verstrekte openbare sleutel te valideren via een proces dat bekend staat als ondertekenen. Je apparaat stuurt Apple het ondertekende bericht, dat niets van de oorspronkelijke sleutel onthult. Apple beschikt nu over je openbare sleutel en een afzonderlijke verifieerbare handtekening die kan worden gebruikt om te controleren of de openbare sleutel is gewijzigd in de sleuteldirectory van Apple.
• Om Sleutelverificatie van contacten te gebruiken, vraagt Apple jou en een andere partij om een korte numerieke code met elkaar te bevestigen om elkaar identiteit in iMessage-conversatie te bevestigen. (Andere berichtenapps, zoals Signal en WhatsApp, bieden een gelijkaardige verificatie-optie.)
• Deze verificatiestap waarbij een numerieke code wordt bevestigd, is cryptografisch sterk omdat er geen privé-informatie tussen jullie wordt verzonden. Bovendien is Apple geen partij in het verificatieproces: er zijn geen Apple-servers, bemiddeling of opslag bij betrokken.
• Apple speelt echter wel een rol in de verificatie. Zij publiceren continu een cryptografisch versleutelde en geanonimiseerde lijst met publieke sleutels van iMessage-gebruikers en de ondertekende component die wordt afgeleverd wanneer iemand Sleutelverificatie van contacten activeert. Deze lijst wordt algemeen een transparantielogboek genoemd. Apple is al begonnen met een dergelijk logboek, dat meer dan twee miljard vermeldingen per week genereert! (Apple zegt in zijn blogpost dat WhatsApp al een soortgelijk logboek heeft gelanceerd).
• Als iemand die Sleutelverificatie van contacten heeft aangezet communiceert met iemand anders die iMessage gebruikt, raadplegen de apparaten van beide partijen onafhankelijk het openbare transparantielogboek om te verzekeren dat noch het logboek, nog de sleutels die ze uitwisselen gecompromitteerd zijn. Tijdens dit proces openbaren de apparaten niets over hun private of lokale sleutels aan Apple (of een willekeurige andere partij).
• Messages waarschuwt je als er iets ongewoons of gevaarlijks voorvalt, zoals een ander apparaat dat aan het account van de andere persoon wordt toegevoegd zonder correcte validatie, een sleutel die niet overeenkomt met een eerdere geverifieerde sleutel of als je gesprekspartner een sleutel gebruikt die te oud is vergeleken met de informatie in het transparantielogboek.
  

Stel je, als praktijkvoorbeeld van wat er zou kunnen gebeuren, voor dat een overheidsinlichtingendienst journalisten, politici of anderen die via iMessage communiceren met mensenrechtenjuristen, spionnen, of anderen, in de gaten houdt. Het doel van die inlichtingendienst is om zich voor te doen als de eerstgenoemde partijen en het vertrouwen van laatstgenoemden te winnen om zo hun lokatie, met wie ze nog meer communiceren, en andere vertrouwelijke informatie te ontdekken.

Misschien breekt de dienst wel in bij Apples adresgegevens en slagen ze er in om de publieke sleutels van de eerstgenoemde groep te vervangen door sleutels die de dienst beheert, zonder dat Apple er erg in heeft, of vinden ze een hack waardoor ze Berichten alternatieve publieke sleutels kunnen lagen accepteren. (Let wel, deze scenario's zijn erg onwaarschijnlijk, maar Apple geeft toe dat het niet absoluut onmogelijk is om de uitgifte van publieke sleutels vanuit een centrale opslag te hacken.)

Zonder verificatie van sleutels zou een inlichtingendienst, op basis van een dergelijke hack kunnen communiceren met personen in de laatstgenoemde groep via wederrechtelijk verkregen accounts, en iMessage zou niks in de gaten hebben - omdat de end-to-end verbinding gewoon zou overschakelen naar de nieuwe sleutel die aan het contact werd toegekend, wat een normale gebeurtenis is als publieke sleutels wijzigen. De conversatie zou gewoon doorgaan. Een journalist of politicus zou niet in de gaten hebben dat ze feitelijk communiceren met medewerkers van een inlichtingendienst.

Met Sleutelverificatie van contacten echter zou de publieke sleutel nog steeds ongemerkt gewijzigd kunnen worden, maar de handtekening die geassocieerd is met die publieke sleutel niet. Berichten zou proberen omd de informatie te valideren via het openbare transparantielogboek, erachter komen dat de sleutel was gewijzigd zonder een nieuwe één-op-één validatiestap, en zou de gebruikers waarschuwen.

Achtergrond: Het draait allemaal om de sleutelopslagdienst

Het feitelijke doel van Sleutelverificatie van contacten is om beveiligingsonderbouwing te verstrekken aan online interacties. Apple helpt je niet om te verifiëren dat de andere persoon is wie je denkt dat het is. Dat is aan jou! Je zult er zelf voor moeten zorgen dat je weet wie je tegenpartij is, dat je hun telefoonnummer of e-mailadres kent en bij voorkeur dingen over ze weet die je niet online kunt vinden.

Als je Sleutelverificatie van contacten gebruikt met iemand die je al kent, wijzig je een bestaande conversatie van "Ik denk dat ik weet met wie ik praat" naar "Ik ken deze persoon, en we hebben nu een onafhankelijke versleutelingsverificatie om onze conversatie veilig en bestand tegen inbraak te houden."

Het enige wat je hoeft te doen is een bestaande conversatie selecteren en een betrouwbare methode te kiezen om de verstrekte code te lezen, zoals je hieronder kunt zien. Als de codes overeenkomen kun je allebei aangeven dat het geverifieerd is.

Dit nummer zou je wel moeten delen via een andere weg dan Berichten: alle Berichten-communicatie is in-band (maakt gebruik van dezelfde verbinding als die je probeert te beveiligen); je hebt een aparte out-of-band-verbinding nodig die niet gecompromitteerd kan worden. Beveligingsexperts raden over het algemeen aan om dit in levenden lijve te doen, of via een beveiligde videoverbinding waarbij je elkaar kunt zien (FaceTime, of Zoom met end-to-end modus geactiveerd). Je zou ook gebruik kunnen maken van een niet-beveiligde telefoonverbinding, maar dan verdient het wel aanbeveling om een aantal antwoorden op standaardvragen of codewoorden af te spreken, om te voorkomen dat een aanvaller die gebruik maakt van een AI-voicebot je voor het lapje houdt — met voldoende fragmenten van de spraak van een persoon kun je geloofwaardige stemmen genereren.

Het doel van deze out-of-band-methoden is om te bevestigen dat de tegenpartij de volledige en exclusieve beschikking heeft over hun Apple ID en apparaten; het verificatieproces bevestigt wie het account-wachtwoord en de tweede factoren beheert.

Als de getallen niet overeenkomen in bovengenoemd proces, maar je weet zeker dat jullie beiden de persoon zijn die de ander denkt dat je bent, dan is er iets heel erg mis gegaan: mogelijk een soort man-in-the-middle-aanval tussen jullie beiden of manipulatie van Apples sleutelserver of transparantielogboek. Op dit punt moet je contact opnemen met een autoriteit om uit te zoeken wat er gebeurd is: dat kan een werkgever zijn of een vertrouwd persoon bij een niet-overheidsgebonden organisatie zoals Citizen Lab, Apple of de FBI, afhankelijk van wie jij bent en de andere persoon is en wat voor informatie jullie wilden uitwisselen.

In bijna alle gevallen zou de valideringsfase van Sleutelverificatie van contacten echter gewoon moeten werken — de kans dat de beveiliging van Berichten of Apple's sleutelopslagdienst doorbroken is, is zo goed als verwaarloosbaar. Eigenlijk zou het bestaan van Sleutelverificatie van contacten alleen al geavanceerde aanvallen, die nu zullen mislukken omdat ze worden waargenomen, kunnen ontmoedigen.

Omdat dit systeem bovendien gebouwd is op voorafgaande bekendheid tussen de partijen en een reeds bestaande iMessage-conversatie, kan die conversatie niet overgenomen worden door een derde partij die net doet of ze de verificatiecode hebben die jij voorleest. Als die partij beweert "dat hun code overeenkomt" terwijl jouw code “1234 5678” is en die van hun “8765 4321”, en je aangeeft dat het geverifieerd is, levert ze dat niets op. Als ze aan dezelfde conversatie deelnemen zou de code identiek moeten zijn, onafhankelijk van hoe ze eraan komen; als ze niet in dezelfde conversatie zitten met jou komt de code niet overeen, en hebben ze er niks aan dat jij de code voorleest. Sterker nog, de verificatiecode kan ook aantonen dat er al iets is misgegaan, en het startpunt betekenen om toekomstige wijzigingen nauwgezet te controleren.

Anders gezegd, dit verklaart ook waarom Apple opmerkt dat iemand die "algemeen bekend" is, zonder gevaar online een verificatiecode zou kunnen openbaren. Als iemand een iMessage-conversatie wil beginnen met een publiek figuur, kan die erop vertrouwen dat die openbare code het bewijs is dat het publieke figuur is wie hij of zij zegt te zijn. En omdat Apple die openbare code koppelt aan het e-mailadres en telefoonnummers die bij hun Apple ID-account horen, zou iemand die met die persoon contact opneemt en de code verifieert uitsluitend in contact kunnen komen met een bedrieger als die het Apple ID-account van de bekende persoon gekaapt zou hebben.

Sleutelverificatie van contacten is een oplossing voor een probleem dat al jaren bekend is. Lang geleden, in 2016, legde beveiligingsonderzoeker Matthew Green een aantal fundamentele ontwerp-problemen in iMessage uit, met als een van de ernstigste “iMessage’s afhankelijkheid van een kwetsbare gecentraliseerde sleutelserver”. (Een andere was Apples omissie het iMessage-protocol te publiceren, wat tot op de dag van vandaag problematisch blijft. Ik heb een Macworld-column over deze gebreken geschreven in 2016.)

Apple geeft in het blog-bericht botweg toe dan hun iMessage-systeem kwetsbaar is voor dergelijke aanvallen:

Hoewel een sleutelopslagdienst als Apple's Identity Directory Service (IDS) sleutelontdekking aanpakt, is het een zwakke plek in het veiligheidsmodel. Als een machtige tegenstander de sleutelopslagdienst kan aanpassen, dan kan de dienst gecompromitteerde sleutels gaan uitgeven — publieke sleutels waarvan de tegenstander de privé-sleutels beheert — waardoor de tegenstander de versleutelde berichten kan onderscheppen of lezen.

Laten we wat dieper op de sleutelopslagdienst, Apple's Identity Directory Service, ingaan. Bij iMessage-gesprekken genereren je apparaten unieke privé-encryptiesleutels waar Apple nooit toegang toe heeft; deze sleutels worden nooit naar Apple verstuurd. Sinds iMessage, met diens beveiligde end-to-end versleuteling uitkwam, maakt het eerste apparaat waarmee je inlogde bij iCloud met je Apple ID-account een lokaal bewaard publiek-privé-sleutelpaar. Als je nieuwe apparaten toevoegt aan je iCloud-account, voert elk nieuw apparaat een sleutel-uitwisseling uit met de andere apparaten in je iCloud-verzameling zodat elk van die apparaten berichten kunnen ver- en ontsleutelen.

Je bent je wellicht in de war geraakt over deze sleutel-uitwisseling, want Apple legt het slecht uit. Als één van je apparaten zegt dat je het wachtwoord/de code van een ander aan je iCloud verbonden apparaten moet invoeren en dat het wachtwoord/de code niet naar Apple wordt verstuurd, dan zie je dit sleutel-uitwisselingsproces. Als je een apparaat aan je iCloud-verzameling toevoegt, dan moet je het geheim (het wachtwoord/de code) dat alleen jij kent van een ander apparaat in jouw bestaande iCloud-verzameling invoeren. Dat andere apparaat heeft diverse sleutel-informatie versleuteld, gebruik makend van dat wachtwoord/die code (en andere informatie).

Een voorbeeld uit de praktijk. Stel dat jouw iPhone en Mac ingelogd zijn op iCloud, en je koopt een nieuwe iPad. Als je inlogt bij iCloud op die nieuwe iPad, wordt jou gevraagd - na het verschijnen van het thuisscherm - om je inlogcode van je iPhone in te voeren, of het wachtwoord van het iCloud-account op je Mac dat hoort bij jouw Apple ID. Als je dit doet, dan krijgt je nieuwe iPad toestemming om informatie die hoort bij jouw iCloud-account te ontsleutelen. Je krijgt op de iPad toegang tot de in iCloud opgeslagen gegevens van Berichten, informatie in je iCloud-sleutelhanger en tot andere versleutelde informatie. Vervolgens versleutelt de nieuwe iPad zijn eigen unieke sleutels, die via iCloud gedeeld worden met andere apparaten. Dit proces waarin sleutels alleen op de apparaten zelf uitgewisseld worden, maakt dat jouw apparaten unieke informatie over de sleutels met elkaar kunnen delen, zonder dat Apple hier ook maar iets vanaf weet.

Voor iMessage-gesprekken geldt een ander proces. Apple's Identity Directory Service slaat het publieke deel van een publiek-privé-sleutelpaar op, in een proces dat bekend staat als publieke-sleutel cryptografie, dat Apple gebruikt in al zijn end-to-end versleutelingssystemen. Deze versleuteling via publieke sleutels wordt ook over het hele internet en in veel computersystemen breed ingezet. Hiermee kunnen mensen op een veilige manier versleutelde gegevens uitwisselen, zonder dat er van tevoren tussen hun al een relatie bestond. Dit komt doordat het publieke deel van de twee sleutels vrijelijk gedeeld kan worden, zonder dat daarmee enig deel van de privé-sleutel prijsgegeven wordt. Dat persoonlijke deel wordt gebruikt om informatie te ontsleutelen, en om data cryptografisch te ondertekenen: daarmee wordt de identiteit van de initiatiefnemer van de uitwisseling bewezen, plus dat niemand met de informatie gerommeld heeft. Jouw eigen apparaat bewaart en beschermt deze privé-sleutel, die het apparaat ook nooit verlaat. Intel Macs met een T2-chip en iedere iPhone, iPad of Mac met de Apple silicon-chip slaan de sleutel op in de slechts in één richting toegankelijke Secure Enclave. De publieke sleutel bevestigt de identiteit van alles dat met de privé-sleutel ondertekend wordt.

De zwakte van deze publieke sleutel-cryptografie is de volgende: er is geen inherent deel in het proces-protocol van het genereren van een sleutel waarin door een externe partij gevalideerd kan worden wie eigenaar is van een bepaalde publieke sleutel. Hier wordt de infrastructuur gebouwd. Vroeger had je Pretty Good Privacy (PGP) met heel veel sleutel-servers. Later kreeg je Keybase, dat een modernere oplossing bood, maar ook daarvoor moest je nog steeds veel vertrouwen hebben. Zoom bezit Keybase nu, maar het systeem werd nooit breed geaccepteerd. Apple's Identity Directory Service biedt Apple optimale controle over de kleinste onderdelen van encryptie-software, maar ook over hardware en servers, maar ondanks dat geeft Apple toe dat beveiligingsonderzoekers het bij het rechte eind hebben, en dat ook IDS niet voldoende is voor het hoogste beveiligingsniveau. Deze erkenning komt eruit voort Apple's ervaring met regeringsgeleide spyware-aanvallen op kwetsbaarheden in of via Berichten. Het bedrijf is hierom zelfs een rechtzaak begonnen tegen de NSO Group. (Zie “Apple spant rechtzaak aan tegen spywarebedrijf NSO Group,” 24 november 2021). De zaak loopt langzaam door het rechtssysteem.

Om de lijst met publieke sleutels zonder encryptie, die apparaten creëren, minder kwetsbaar te maken, voegt Sleutelverificatie van contacten de hierboven genoemde extra sleutel toe. Deze unieke sleutel wordt alleen gedeeld met jouw aan iCloud verbonden apparaten. Het cryptografische proces werkt in één richting, en voegt deze sleutel toe aan jouw publieke sleutel voor Berichten, met als resultaat een nieuwe handtekening. Deze handtekening kan niet nagemaakt worden - om hem te valideren heb je de originele sleutel nodig, en deze bestaat alleen op je eigen apparaten. (En let op: precies daarom is het van groot belang dat je fysieke toegang tot jouw apparaten en hun toegangscodes of wachtwoorden afschermt! Deel een toegangscode nooit met iemand die je geen toegang tot je bankrekening zou geven, en voer in openbare gelegenheden nooit een toegangscode zichtbaar in. Zie “Hoe een dief je digitale leven kan ruïneren als hij eenmaal je iPhone-wachtwoord heeft” (26 februari 2023), en dit artikel: “Hoe een toegangscode-dief jou, mogelijk permanent, kan uitsluiten van je iCloud-account,” (20 april 2023).

Deze ondertekening wordt uiteindelijk versleuteld ingedikt tot de code van acht cijfers. In de procedure moeten twee mensen dezelfde acht cijfers te zien krijgen: dit vormt het ontbrekende schakeltje in de beveiligingsketen. Nu worden de apparaten van deze twee mensen de "bron van waarheid" die aan de basis staat van hun Berichten-account, niet langer Apple's IDS-dienst. Als er iets verandert, dan herkennen de twee apparaten afwijkingen in Apple's IDS of in de hierboven genoemde transparantielogboek.

Beveiligingsonderzoekers vertellen Apple al langer dat een top-beveiliging van Berichten mogelijk is en Sleutelverificatie van contacten komt behoorlijk dicht in de buurt. Voor de gemiddelde gebruiker van Berichten zal dit alles niet zo belangrijk lijken, maar het is een enorme sprong voorwaarts voor mensen wier levensonderhoud of leven in gevaar kan komen als communicatie onveilig is.