×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Verlopen ontwikkelaarscertificaten zorgden voor niet-startende apps op macOS

Door , 53 reacties

Verlopen ontwikkelaarscertificaten zorgden er dit weekend voor dat verschillende macOS-apps niet meer startten. Daaronder was de populaire wachtwoordmanager 1Password. Het probleem is te verhelpen door de applicaties handmatig van een update te voorzien.

Andere getroffen apps zijn Soulver en PDFPen, schrijft MacRumors. Gebruikers hebben te maken met het probleem als zij de apps buiten de App Store om direct van de site van de ontwikkelaar zelf hebben gedownload. Deze programma's zijn voorzien van een ontwikkelaarscertificaat, om aan te tonen dat het om legitieme software gaat die niet is aangepast. In het verleden had het verlopen van een dergelijk certificaat geen gevolgen, maar door een wijziging van Apple is dat veranderd.

Volgens MacRumors ligt de oorzaak bij provisioning profiles, waaruit blijkt welke systeemfuncties een app mag uitvoeren. Deze werden ingevoerd in macOS Sierra. Dit profiel maakt ook gebruik van het ontwikkelaarscertificaat en stopt met werken als dit verloopt. De apps die de problemen ondervinden, hebben volgens MacRumors gemeen dat ze allemaal gebruikmaken van de iCloud-rechten in hun profiel.

1Password-ontwikkelaar AgileBits laat via een blogpost weten dat een handmatige update naar versie 6.5.5 het probleem verhelpt. Voor Soulver lost versie 2.6.1 de problemen op en ook voor PDFPen is er een nieuwe versie.

Door Sander van Voorst

Nieuwsredacteur

20-02-2017 • 15:42

53 Linkedin Google+

Reacties (53)

Wijzig sortering
Dat is een effectieve manier om oude software automatisch onbruikbaar te maken. Ik weet niet of dit wenselijk is.
Kort door de bocht: ja, dat is wenselijk.
Natuurlijk is dit voor de gebruiker even vervelend, maar gelukkig ook eenvoudig op te lossen: voer handmatig een update uit.

Met een certificaat 'bewijs' je dat de applicatie daadwerkelijk bij jou als software maker vandaan komt. De geldigheidsduur van een certificaat geeft aan dat alle software die in de tussentijd wordt ondertekent met dat certificaat, dus ook van die softwaremaker is en te vertrouwen zou moeten zijn.
Maar helaas lekken er wel eens valide certificaten uit middels hacks. Als een oud en verlopen maar verder valide certificaat nog steeds alles zou mogen, is dat een potentieel enorm beveiligingslek. :)

Door het certificaat niet meer te vertrouwen als deze verlopen is, moet de softwareontwikkelaar actief actie ondernemen om aan te blijven tonen dat zijn software daadwerkelijk legitiem is door een nieuw certificaat te gebruiken, of te verlengen.
Dat wordt bewust gedaan zodat de gebruiker gewoon op het certificaat kan vertrouwen en zo min mogelijk actie hoeft te ondernemen. Het is ook erg lastig om als 'gemiddelde gebruiker' te verifieren of de software wel legitiem is... :)
(Ja, dat kan met hashes, maar welke gemiddelde gebruiker heeft een tool welke die hashes kan genereren en controleren, en als de software is gehackt kan de hash op een website natuurlijk ook gewoon mee zijn aangepast...)
Dus als ik op 1 februari 2016 een app download die in 2012 al volledig was uitontwikkeld, en die app op 1 februari installeer dan vind jij het wenselijk dat die app op 16 februari 2017 door het verlopen van het certificaat per die datum opeens niet meer werkt.

Nee als die app is uitontwikkeld (er zitten dus geen bugs meer in) en die is gecertificeerd en ge´nstalleerd en sindsdien niet meer gewijzigd dan moet die in mijn ogen blijven werken.

Sterker nog, als ik in maar 2017 een nieuw systeem koop en die app daarop wil installeren dan moet dat, volgens mij, in principe nog steeds mogelijk zijn, mits die app sinds de ondertekening niet is gewijzigd.
Dus als ik op 1 februari 2016 een app download die in 2012 al volledig was uitontwikkeld, en die app op 1 februari installeer dan vind jij het wenselijk dat die app op 16 februari 2017 door het verlopen van het certificaat per die datum opeens niet meer werkt.
Ja, dat vind ik wenselijk. :)
Niet zozeer omwille van de app in kwestie, maar wel omwille van alle andere apps, zowel legitiem als met minder frisse bedoelingen.

Als een app sinds 2012 niet meer geŘpdatet is, ga ik me persoonlijk eerder andere dingen afvragen.
Het is uiteraard mogelijk, maar dan zal het een relatief simpele app zijn die alle acties lokaal kan uitvoeren.
Zodra er gegevens over het net moeten, vraag ik me eerder af of de beveiliging Řberhaupt nog wel op orde is. Zeker zodra er meer persoonlijke gegevens over het net gaan, en dat is ongeacht of ik het bedrijf of de persoon achter de app wel of niet vertrouw.

Daarnaast is het, zolang de source code beschikbaar is, kinderlijk eenvoudig om het certificaat te vernieuwen. Als de source niet meer beschikbaar is wordt het lastiger.
Nee als die app is uitontwikkeld (er zitten dus geen bugs meer in) en die is gecertificeerd en ge´nstalleerd en sindsdien niet meer gewijzigd dan moet die in mijn ogen blijven werken.
Persoonlijk ben ik er niet echt van overtuigd dat een app zomaar uitontwikkeld is. :)
Het is uiteraard mogelijk, maar dan betreft het waarschijnlijk een app met een zeer specifiek doel.

Maar zelfs als dat gebeurd, dan nog blijft het zaak om de interface zo af en toe bij te blijven werken. Apple en Google zijn er vrij aardig op gebrand dat hun design guidelines worden gevolgd, en Apple begint bijvoorbeeld ook oude 'abandoned' apps te verwijderen.
Met een opfrissing van de UI kan natuurlijk gelijk een nieuw certificaat gebruikt worden bij het ondertekenen van de binary. :)
Sterker nog, als ik in maar 2017 een nieuw systeem koop en die app daarop wil installeren dan moet dat, volgens mij, in principe nog steeds mogelijk zijn, mits die app sinds de ondertekening niet is gewijzigd.
Dat impliceert dat malware, mits tijdig ondertekent en sindsdien niet meer aangepast, ˇˇk vrij spel hebben. :)
Persoonlijk heb ik dat liever niet, maar dat kan natuurlijk per persoon verschillen...
Als een app sinds 2012 niet meer geŘpdatet is, ga ik me persoonlijk eerder andere dingen afvragen.
Heel veel GNU code is feitelijk uitontwikkeld. Uiteraard betreft dat dan meestal apps zonder grafische interface. Echter ook voor heel veel andere code geld dat ze uitontwikkeld is, ook op het Windows platform
Het is uiteraard mogelijk, maar dan zal het een relatief simpele app zijn die alle acties lokaal kan uitvoeren. Zodra er gegevens over het net moeten, vraag ik me eerder af of de beveiliging Řberhaupt nog wel op orde is. Zeker zodra er meer persoonlijke gegevens over het net gaan, en dat is ongeacht of ik het bedrijf of de persoon achter de app wel of niet vertrouw.
Als de app gegevens over het net moet sturen dan veranderd de zaak wel. De code die de communicatie verzorgd zal wel de nieuwste protocollen moeten gebruiken. SSL 1.0 geld uiteraard niet meer als veilig.
Daarnaast is het, zolang de source code beschikbaar is, kinderlijk eenvoudig om het certificaat te vernieuwen. Als de source niet meer beschikbaar is wordt het lastiger.
Heel veel windows-apps zijn destijds enkel binair gedistribueerd. Wat jij wenst is dus in principe alleen beschikbaar bij open source software en voor de originele makers van de code.
Persoonlijk ben ik er niet echt van overtuigd dat een app zomaar uitontwikkeld is. :)
Het is uiteraard mogelijk, maar dan betreft het waarschijnlijk een app met een zeer specifiek doel.
Veel GNU code is dus echt uitontwikkeld.compileren moet uiteraard wel opnieuw als het platform zelf veranderd, bv van 32 naar 64bit.
Maar zelfs als dat gebeurd, dan nog blijft het zaak om de interface zo af en toe bij te blijven werken. Apple en Google zijn er vrij aardig op gebrand dat hun design guidelines worden gevolgd, en Apple begint bijvoorbeeld ook oude 'abandoned' apps te verwijderen.
We hadden het toch over apps die buitenom de store geinstalleerd moeten worden.
Met een opfrissing van de UI kan natuurlijk gelijk een nieuw certificaat gebruikt worden bij het ondertekenen van de binary. :)
Klopt maar dan moet de code wel beschikbaar zijn.
Dat impliceert dat malware, mits tijdig ondertekent en sindsdien niet meer aangepast, ˇˇk vrij spel hebben. :)
Daar heb je malware-scanners voor toch, en antivirus.
Daarbij, weet je dan ook waar het vandaan komt.
Heel veel GNU code is feitelijk uitontwikkeld. Uiteraard betreft dat dan meestal apps zonder grafische interface. Echter ook voor heel veel andere code geld dat ze uitontwikkeld is, ook op het Windows platform
Ook als de API's van het onderliggende platform veranderen, moet nog wel eens een aanpassing gedaan worden om de uitontwikkelde code weer beschikbaar te maken voor nieuwe versies van een besturingssysteem. :) (waar mogelijk weer bugs in optreden etc...)
Dus zelfs zonder grafische schil kan de applicatie prima feature-complete zijn, maar zolang het OS waarop het moet draaien ontwikkeld blijft worden en de applicatie relevant blijft, lijkt het me dat in ieder geval het supporten van de app (zorgen dat 'ie ook op nieuwe versies van het OS blijft draaien etc) niet zomaar klaar is :)
Heel veel windows-apps zijn destijds enkel binair gedistribueerd. Wat jij wenst is dus in principe alleen beschikbaar bij open source software en voor de originele makers van de code.
Inderdaad, omdat je wel zeker wil weten dat de software bij de maker vandaan komt... Als iemand een binary van een ander zomaar kan re-signen met zijn eigen certificaat, dan is het hele systeem zo lek als een mandje... :)
Veel GNU code is dus echt uitontwikkeld. Compileren moet uiteraard wel opnieuw als het platform zelf veranderd, bv van 32 naar 64bit.
Maar de source is wel beschikbaar... Dus dan is het mogelijk om opnieuw te compilen, en gelijk het certificaat te verversen.
Maar dat lijkt me alleen noodzakelijk als het certificaat op het moment van signen verlopen is, of de binary beveiligde verbindingen via het Internet wil opzetten. :)
Signen met een verlopen certificaat zou hoe dan ook niet mogelijk moeten zijn...
Klopt maar dan moet de code wel beschikbaar zijn.
Dat lijkt me ook noodzakelijk voor een UI refresh... :)
We hadden het toch over apps die buitenom de store geinstalleerd moeten worden.
Dat klopt, inderdaad. Het was meer bedoeld als indicatie dat een app welke 'in 2012 voor het laatst geŘpdatet' is het in de officiŰle stores niet zo lang vol zou houden. :)
Buiten de store om zou ik in die zin juist willen dat software niet zomaar vertrouwd wordt. Laat de ontwikkelaar maar bewijzen dat de software niet is aangepast; juist omdat er geen andere entiteit (in dit geval Apple) zorg voor draagt of verantwoordelijk voor is. :)
Ook als de API's van het onderliggende platform veranderen, moet nog wel eens een aanpassing gedaan worden om de uitontwikkelde code weer beschikbaar te maken voor nieuwe versies van een besturingssysteem. :) (waar mogelijk weer bugs in optreden etc...)
Dus zelfs zonder grafische schil kan de applicatie prima feature-complete zijn, maar zolang het OS waarop het moet draaien ontwikkeld blijft worden en de applicatie relevant blijft, lijkt het me dat in ieder geval het supporten van de app (zorgen dat 'ie ook op nieuwe versies van het OS blijft draaien etc) niet zomaar klaar is :)
Voor de GNU code is dat nauwelijks nodig. Deta´s ken ik echter niet.
Inderdaad, omdat je wel zeker wil weten dat de software bij de maker vandaan komt... Als iemand een binary van een ander zomaar kan re-signen met zijn eigen certificaat, dan is het hele systeem zo lek als een mandje... :)
Hoezo. als dat certificaat niet is gevalideerd zou het niet zomaar in het OS ge´nstalleerd moeten kunnen worden. Als jij die applicatie kent en op je eigen systeem wilt gebruiken kan jij hem toch met je eigen certificaat voor jouw systeem valideren? Distribueren zou niet mogelijk moeten zijn, maar dat mag meestal toch al niet.

Op Windows wordt trouwens heel veel unsigned code geinstalleerd. Daar is het buitenom drivers eerder uitzondering dat code gesigneerd is. Enkel voor het uitvoeren van macro's in Office vereist Microsoft dat tegenwoordig (zodat het uitvoeren van je zelf geschreven macro's ook al een probleem wordt 8)7 ) Vrijwel alle open source software is niet gesigned, het is aan de gebruiker zelf om de hash te controleren.

Windows doet zowel bij een msi als bij een exe-installer niets met de signing van het installatiepakket tenzij het een driver betreft.
Maar de source is wel beschikbaar... Dus dan is het mogelijk om opnieuw te compilen, en gelijk het certificaat te verversen.
Bij GNU code wel maar die wordt doorgaans via de repositories van de distributie ge´nstalleerd.
Signen met een verlopen certificaat zou hoe dan ook niet mogelijk moeten zijn...
Agreed, maar dan nog is het beter als unsigned code, dwz voor code die niet al via repositories of een store worden ge´nstalleerd.
Dat klopt, inderdaad. Het was meer bedoeld als indicatie dat een app welke 'in 2012 voor het laatst geŘpdatet' is het in de officiŰle stores niet zo lang vol zou houden. :)
Klopt want de steeds veranderende design-rules eisen dat de GUI steeds aangepast wordt en daarmee kunnen onnodig nieuwe bugs worden ge´ntroduceerd. Ook hebben we gezien dat dit in het geval van Windows (Metro/Modern) vele dumbed-down applicaties opleverde (ergste voorbeeld is Ms Office).
Buiten de store om zou ik in die zin juist willen dat software niet zomaar vertrouwd wordt.
Als je buitenom de store installeerd, dan heb je zelf de gelegenheid gehad om de oorsprong van de app te controleren. Je installeert immers niet zomaar buiten de store om. Uiteraard mag dat niet kunnen leiden tot een silent install zoals dat via websites en adds kon gebeuren op het Windows-platform. Dergelijke installs zijn crimineel en dat geldt mijns insziens ook min-of-meer voor de vele andere apps die ongevraagd meege´nstalleerd worden (zoals McAfee Security Scan Plus, Norton Security Scan, Ask toolbar, Yahoo ToolbarGoogle Toolbar (en vele andere toolbars), Uniblue Registry Booster, OpenCandy, RegistryCleanerPro, Google Chrome, Reg Clean Pro, enzovoorts)
Laat de ontwikkelaar maar bewijzen dat de software niet is aangepast; juist omdat er geen andere entiteit (in dit geval Apple) zorg voor draagt of verantwoordelijk voor is. :)
Dat doet het signing toch?
Kun je garanderen dat die applicatie nog steeds werkt op de laatste versie van het OS?
Wellicht zijn daardoor opeens bugs zichtbaar, of zijn workarounds niet meer correct?
En wellicht is het niet erg om de ontwikkelaar te vragen om de app (want die was immers volledig uitontwikkeld en foutvrij) even opnieuw te bouwen en te signen?
Die ontwikkelaar heeft immers al wel 5 jaar die app kunnen verkopen zonder er daar iets aan te hoeven doen (want immers volledig uitontwikkeld en foutvrij)...
Kun je garanderen dat die applicatie nog steeds werkt op de laatste versie van het OS?
Ik niet. Mijn 16-bits Civilization 2 doet het niet meer op 64-bits Windows 10 (tenzij in een VM) Daar werkt het gewoon helemaal niet.
Wellicht zijn daardoor opeens bugs zichtbaar, of zijn workarounds niet meer correct?
In een uitontwikkelde app speelt dat niet, die moet hooguit opnieuw gecompileerd worden, tenzij er api's uit het OS verdwenen zijn.
En wellicht is het niet erg om de ontwikkelaar te vragen om de app (want die was immers volledig uitontwikkeld en foutvrij) even opnieuw te bouwen en te signen?
Wat als die ontwikkelaar inmiddels niet meer bestaat?
Die ontwikkelaar heeft immers al wel 5 jaar die app kunnen verkopen zonder er daar iets aan te hoeven doen (want immers volledig uitontwikkeld en foutvrij)...
GNU apps worden niet verkocht. Van andere software die uit ontwikkeld is heb ik geen voorbeelden, maar dat deze kan bestaan lijkt mij duidelijk.

[Reactie gewijzigd door BeosBeing op 21 februari 2017 11:02]

Ik niet. Mijn 16-bits Civilization 2 doet het niet meer op 64-bits Windows 10 (tenzij in een VM) Daar werkt het gewoon helemaal niet.
Dus dan maakt het niet uit of het niet opnieuw gesigned wordt of niet...
In een uitontwikkelde app speelt dat niet, die moet hooguit opnieuw gecompileerd worden, tenzij er api's uit het OS verdwenen zijn.
Niet helemaal waar. Ontwikkelaars hebben soms workarounds voor bugs in APIs, als de bug dan gefixt wordt gaat het soms opeens anders mis...
Wat als die ontwikkelaar inmiddels niet meer bestaat?
Dat is dan wellicht een reden, maar blijft dat bugs die ontstaan door een ander OS (of OS update) dan dus ook niet gefixt worden, of veiligheidsproblemen die gevonden worden.
GNU apps worden niet verkocht
Maar nou net een verkeerd voorbeeld: De source daarvan per definitie beschikbaar, dus opnieuw compileren en uitbrengen is triviaal...
"Er zitten dus geen bug meer in" is geen haalbare status. 0% kans op fouten. Daarnaast is dit voor PKI maar ook voor eingebruikerbescherming zeer wenselijk.

Je kan zelf altijd de applicatie buiten LSServices om starten als je dat perse wil, en je kan als admin ook gewoon een stuk software draaien, alle beveiliging uitschakelen of zelf certificaten uitdelen. Dus echt onmogelijk is het ook niet.

Software is nooit 'af'. Er is geen enkele situatie waarbij je 'set and forget' kan doen. Sure, je kan hele simpele software hebben die heel goed uitontwikkeld is, maar dan nog zijn er zat variabelen die in systemen kunnen veranderen waardoor er nog steeds onderhoud nodig is. Tenzij je zelf de broncode hebt of een support contract voor alle software ooit hebt is er geen enkele manier om te kunnen garanderen dat de software die je draait veilig en up to date is.

De tijd dat je computer een eilandje was is zo'n beetje 10 jaar geleden wel afgelopen. Je kan niet meer een apparaat precies houden zoals het bij aankoop was en hopen dat het voor altijd blijft werken, hoe graag je het ook zou willen.
Vanuit de appstore? Jazeker. Je kunt namelijk helemaal niet garanderen dat die app bug vrij is. Sterker nog. Ik durf te wedden dat die Pp dat niet meer is. De software die in Snow leopard namelijk wel werkte is nu zo goed als niet meer bruikbaar door ingrijpende veranderingen in de onderliggende structuren.
Normaal gesproken wordt er een vergelijking gemaakt met het moment waarop de ondertekening is toegepast en of dat valt binnen de geldigheidsperiode. Een certificaat dat dus niet meer geldig is hoeft in dat geval geen melding te geven indien de periode van ondertekening wel binnen die geldigheidsperiode ligt.
Dan moet uiteraard wel de timestamp meegenomen worden in het signeerproces.
Hier lijkt het er op dat het moment na de valide periode lag, ˇf dat de timestamp niet is meegenomen.. :) /edit: iets te snel gelezen, gaat alleen om de verbinding met iCloud... Dan geeft een verlopen certificaat inderdaad problemen, gezien de identiteit niet geverifiŰerd kan worden... 8)7 /edit

Het meenemen van de timestamp werkt inderdaad ook prettiger bij het revoken van certificaten, en voorkomt het probleem dat @BeosBeing benoemt :)

Wel vind ik het jammer dat Apple verlopen certificaten tot op zekere hoogte toestaat gebruikt te worden in het signeerproces...

[Reactie gewijzigd door Raventhorn op 21 februari 2017 10:18]

Nee, dat is NIET wenselijk.. waarom zou je een update moeten draaien puur vanwege een certificaat dat verlopen is.
Ik zou er niet blij van worden als ik om de haverklap weer software moet gaan bijwerken alleen maar omdat het certificaat verlopen is. IK bepaal wel wat er wel en niet op mijn systeem gedraaid mag worden, het OS mag mij hooguit op de hoogte stellen dat het certificaat niet meer geldig is, maar IK bepaal of de applicatie dan wel/niet meer mag starten..
Ja precies. Waarom gebruiken ze uberhaupt nog een certificaat, browsers laten je ook al niet meer toe op sites die een verlopen certificaat hebben. Die betutteling!

/s

Je ondermijnt het hele idee achter certificaten.
Nee, certificaten ansich is niets mis mee, zolang het mij waarschuwt, maar blokkeren vind ik te ver gaan, IK ben uiteindelijk degene die bepaald of ik toch door wil gaan met de 'onveilige' applicatie, niet het OS. Probleem zal zich vooral voordoen met oudere software waar gewoonweg geen ondersteuning meer op zit, maar deze wel nog gewoon perfect werkt, moet deze dan maar geblokkeerd worden omdat het certificaat verlopen is omdat de developer pleite is? nee echt niet dus.
Ik ondermijn dus helemaal niet het hele idee achter certificaten, ik bevestig juist het idee achter certificaten, dat deze dus moet waarschuwen wanneer er iets aan de hand is..
En dan heb ik het dus over desktop/mobile software, als we het over certified devices hebben die eigenlijk maar 1 purpose hebben dan wordt het een ander verhaal.
Certificaten zijn voor een chain of trust, als die gebroken word, is de trust weg, jij wil dat negeren en daarmee ondermijn je dus het hele bestaan van certificaten.

Laptop van developer word gestolen hij meld dat zijn certificaat ongeldig moeten worden verklaard, hacker gebruikt zijn ongeldige certificaat om een apps met verkeerde bedoelingen de wereld in te sturen, SuperDre zegt: prima, certificaat boeit mij niet, waarom zit ie er uberhaupt op, ik ben kundig genoeg om te bepalen of het wel of niet goed is...lol

Zo kun je dus alle certificaat toko's opdoeken.
Uhm, ik heb het dan dus wel even over software die ik al heb draaien, als ik nieuwe software binnenkrijg en daar is het certificaat niet meer van geldig, dan denk ik wel even na.. DAT is de beslissing die IK! neem niet het OS.. Juist het is een chain of trust waarbij ikzelf kan beslissen voor MIJZELF of ik iets wel of niet wil vertrouwen..
Certificaten hoef je dus helemaal niet op te doeken. Maar blijkbaar ben jij niet kundig genoeg om dat te begrijpen.
Het punt is dat jij niet kan beslissen of het wel of niet te vertrouwen is, daar zijn CA's voor. Met jouw idee had diginotar nog kunnen blijven bestaan.

Jij bent te dom om te begrijpen hoe dit concept werkt.
Met mijn idee en diginotar heeft juist alleen maar aan hoe CA's juist niet 100% te vertrouwen zijn.
Het is eerder jij die te dom is om te begrijpen hoe dit concept werkt. Als jij blind op certificaten vertrouwt dan ben je dus echt heel erg dom.
En ik zeg dus niet dat je geen certificaten moet gebruiken, ik zeg alleen maar dat IK zelf wel wil beslissen of een applicatie start als het certificaat niet correct is (maar dus wel dat ik eerst een vette waarschuwing krijg). Zelf nadenken mag ook nog best wel in deze tijd hoor.
Nee, dat is NIET wenselijk.. waarom zou je een update moeten draaien puur vanwege een certificaat dat verlopen is.
Omdat de beveiliging van een applicatie of de verbinding met een webservice, in dit geval iCloud, niet gegarandeerd kan worden met een verlopen certificaat.
Net als dat jij je niet mag identificeren met een verlopen identiteitskaart of paspoort, mag een applicatie dat niet met een verlopen certificaat.
Ik zou er niet blij van worden als ik om de haverklap weer software moet gaan bijwerken alleen maar omdat het certificaat verlopen is. IK bepaal wel wat er wel en niet op mijn systeem gedraaid mag worden, het OS mag mij hooguit op de hoogte stellen dat het certificaat niet meer geldig is, maar IK bepaal of de applicatie dan wel/niet meer mag starten..
Het gaat hier om de verbinding met iCloud, waardoor de applicatie blijkbaar niet meer kan werken.
Certificaten zijn, normaal gesproken, meerdere jaren geldig (volgens mij standaard 5, maar kan voor langere perioden).
Daarnaast, kan jij inschatten wat een applicatie allemaal doet of kan? ;) Dat dacht ik inderdaad ook niet.

Net als dat onze overheid garandeert dat jij echt de persoon bent die bij jouw identiteitskaart of paspoort hoort, garandeert een certificate authority dat een applicatie of verbinding ondertekent met een certificaat van de persoon of instantie afkomstig is waar dat certificaat aan uitgegeven is.
Helaas zijn er een hoop certificaten gelekt, ook de private keys. Als je een verlopen of teug getrokken (revoked) certificaat vertrouwd, kan je simpelweg niet meer bewijzen dat de verbinding of applicatie veilig is.

Dus ja, ik vind het wenselijk dat een certificaat verloopt, en standaard niet vertrouwd wordt als deze verlopen of revoked is. :)
Alleen al omdat ik niet kan zien wat een applicatie onder water allemaal doet.
Ik zie nergens in het verhaal dat het specifiek over iCloud verbindingen gaat, maar zelfs dan vind ik het eigenlijk nog dat ik als gebruiker zelf moet kunnen beslissen of ik wel of niet door wil gaan, een goed voorbeeld is dus van perfect werkende software maar welke niet meer verder ondersteund wordt en de developer pleitte is.
Dus dat een certificaat verloopt en niet vertrouwd wordt heb ik geen problemen mee, maar dat ik als gebruiker niet kan beslissen om dan toch de software te kunnen starten, daar heb ik wel een probleem mee.
En zelfs MET certificaten weet je nog steeds niet wat een applicatie allemaal onderliggend doet. Er is al veel malware wat gewoon netjes digitaal ondertekend is.
En we weten inmiddels ook wel dat certificaten ansich ook niet alles meer zeggen.
Dat het gaat om iCloud verbindingen maakte ik op uit het volgende stukje :)
De apps die de problemen ondervinden, hebben volgens MacRumors gemeen dat ze allemaal gebruikmaken van de iCloud-rechten in hun profiel.
De software lijkt naar wat ik er van begrijp (ik heb geen Mac beschikbaar) overigens wel te starten, maar geen verbinding te kunnen maken met iCloud en zich vervolgens af te sluiten. Dat heeft dus niet te maken met of jij de software vertrouwd, maar dat Apple de verbinding niet vertrouwd ;)
De applicaties in kwestie hebben blijkbaar de rechten op de iCloud omgeving nodig om fatsoenlijk te kunnen opereren... Dat lijkt me ook iets dat mogelijk aangepast kan worden om functionaliteit te behouden als het certificaat verlopen is of het protocol niet meer ondersteund wordt.
Als iCloud werkt, gebruik dan die, anders sla je het lokaal op... Maar ook dat is aan de developers. :)
Uiteraard is dat erg kort door de bocht.
De gebruiker moet bepalen of hij een programma wilt vervangen of verwijderen.
De app was geaccepteerd in de app store dus was in orde.
Dus waarom na vijf jaar niet meer? Als er iets fout gaat is het door veranderingen van Apple.
Ik heb diverse app's van Ą100-700 plus, en die zouden dan zo maar kunnen stoppen met werken.
Als een ontwikkelaar er mee stopt, om wat voor reden dan ook,
- overlijden,
- stopt met werken,
- te weinig verdiensten er mee,
stopt mijn gekregen/gekochte app.

Apple zou meer moeten kijken waar een app contact mee maakt. Ik heb hier een gecertificeerde app die maar liefst met 23 niet nodige sites, niet eens app gerelateerd, communiceert. Met little snitch bekeken. Dan gemeten hoelang het duurde en duurde 8 seconden voordat ik de app kon gebruiken. Heb de app aankoop terug gedraaid.
Maar worden ze bij het ondertekenen dan niet van een timestamp voorzien? Of ondersteund iOS dat niet? Het verlopen van een certificaat zou namelijk, indien goed gedaan, er niet voor mogen zorgen dat de handtekening niet meer geldig is.
Zonder de exacte technische details te weten vermoed ik dat het komt doordat het certificaat ook gebruikt wordt om een connectie met iCloud te authenticaten. Als het certificaat dan verlopen is dan kan er geen verbinding gemaakt worden (het certificaat is immers niet meer geldig) en zal de app uit voorzorg afsluiten omdat kritieke delen van de code niet uitgevoerd kunnen worden.

Zie ook dit stuk uit het artikel:
De apps die de problemen ondervinden, hebben volgens MacRumors gemeen dat ze allemaal gebruikmaken van de iCloud-rechten in hun profiel.
Zie het als een verlopen of revoked SSL certificaat, je wilt als safeguard dat een niet(meer) geldig certificaat gewoon geen toegang krijgt.

[Reactie gewijzigd door Donvermicelli op 20 februari 2017 16:01]

Het verlopen van een certificaat is de facto het invalideren van een handtekening. Het gaat hier overigens over OSX (nu macOS) en niet iOS. Het is overigens op iOS precies hetzelfde behalve dat sideloaden normaalgezien niet toegestaan is op legitieme apparaten en het certificaat via de appstore loopt.
Daarom net dat je timestamping hebt bij code signing. Op die manier vervalt de handtekening niet wanneer de geldigheid van het certificaat vervalt. Ook die timestamp wordt cryptografisch opgeslagen.
Hm, kreeg deze melding gister inderdaad bij mijn 1Password installatie. De handeling die beschreven wordt werkt inderdaad, even nieuwe installatie over de huidige zetten.

Vind het wel apart verhaal dat een signature na verlopen van het certificaat een melding geeft, dit zou niet zo moeten zijn.
Het is een apart verhaal dat een certificaat kan verlopen zonder dat een ontwikkelaar op tijd weet dat dat het geval is en er een update gepusht moet worden. Maar sowieso raar dat je met een niet startende applicatie zit opeens.

Ze zitten echt te slapen bij Apple wat betreft macOS development. Of ze willen iedereen naar de Mac AppStore dwingen.
Je kunt je natuurlijk afvragen of de ontwikkelaar hier vanaf moet weten of dat ze hiervan (verlopen certificaat) door Apple op de hoogte gebracht dienen te worden.

Als Apple het vereist dan ben ik van mening dat ze ook best een automatisch berichtje kunnen laten sturen naar de devs over het verlopen van de certificaten. Misschien dat dit al gebeurd en is bijvoorbeeld AgileBits (1Password) laks geweest met renewal, maar ik kan me dat niet voorstellen.
Weet iemand of dit ook geldt voor applicaties die buiten de AppStore om ge´nstalleerd worden? Ik had op een gegeven moment ook het gevoel dat mijn certificaat niet meer gepikt werd door Sierra machines maar daar speelden zo veel dingen op dat moment in die applicatie dat ik nu niet meer kan zeggen dat het updaten van mijn profiel echt een van de problemen was die er voor zorgden dat de applicatie nu weer werkt.

----

Edit: lezen lezen lezen ja dus

Als mijn iOS certificaten verlopen sturen ze me tien mailtjes van te voren, mijn macOS applicaties mogen blijkbaar zomaar verlopen. Vind het niks gek dat een drukke ontwikkelaar dat soort dingen niet direct door heeft :(

[Reactie gewijzigd door BikkelZ op 20 februari 2017 16:20]

Hmm. Dat is wel raar.

Gaat gatekeerper al direct af of kan je app nog wel openen via Option+click-> open?
Voor de volledigheid: CTRL + klik (of 'two finger tap') en dan openen.

Maar nee, 1password heeft zelfs de app opnieuw aangeboden met een video tutorial hoe je die opnieuw installeert.
Apps getekend met een developerscertificaat zijn ook niet bedoeld om lang te gebruiken. Je moet je apps installeren via de App Store. Dat het vroeger wel kon, leek me eerder een fout.
Het gaat hier om MacOS, niet om IOS. Op een desktop lijkt het me de normaalste zaak van de wereld om software te kunnen installeren buiten de app store om.

Wat ik wel vreemd vind is dat er bij de laatste updates via het Sparkle framework geen nieuwe certificaten zijn meegenomen.
Apps getekend met een developerscertificaat zijn ook niet bedoeld om lang te gebruiken. Je moet je apps installeren via de App Store. Dat het vroeger wel kon, leek me eerder een fout.
Er zijn meerdere soorten certificaten die je van Apple kunt krijgen, ÚÚn daarvan is uitsluitend wel bedoeld voor het signeren van apps die je buiten de AppStore om wilt verspreiden.
ÚÚn daarvan is uitsluitend wel bedoeld voor het signeren van apps die je buiten de AppStore om wilt verspreiden.
En is dat het developerscertificaat? Als ze het verkeerd certificaat hebben gebruikt, kan men Apple moeilijk iets verwijten.
Nee, dat is gewoon een distribution certificaat. Anders kan je niet eens software buiten de Store aanbieden, wat natuurlijk op OSX niet acceptabel zou zijn.
Jawel, je kunt wel software installeren zonder certificaat. Het systeem klaagt erover, maar door het programma (voor de eerste keer) op een bepaalde manier te openen kun je het toch gebruiken. Je moet dan uiteraard wel de programmeur vertrouwen.
Dan weten we in ÚÚn keer ook hoe goed (of slecht) 1password z'n spullen beheert. Op het moment dat je een certificaat aanmaakt weet je al wanneer het gaat verlopen en de geldigheid staat ook nog eens in het certificaat zelf vermeld. Daarnaast hebben de meeste certificaatboeren de mogelijkheid om een waarschuwingsmailtje te ontvangen als het bijna tijd is Het is dus heel eenvoudig om te voorspellen of te monitoren wanneer een certificaat gaat verlopen.

Als dit fout gaat dan vraag ik me af hoe de rest van de infrastructuur beheerd wordt. Voor een bedrijf dat je vraagt om je wachtwoorden door hun te laten beheren vind ik dat geen fijne gedachte dat ze hun monitoring niet op orde hebben. Wat kan er nog meer fout gaan zonder dat 1password het merkt?
Wat een kant en klare onzin.....1password is een prima app, draait lokaal, doet wat het moet doen, doet geen dingen uitzichzelf en doet het altijd. eventueel kan je het syncn met andere devices via dropbox en t is niet cloudbased zoals lastpass.
En dan moet van alle apps juist je password manager getroffen zijn, is dat balen!
Aan de ene kant slordig van 1Password, aan de andere kant kan ik het ook wel begrijpen als je ziet wat @BikkelZ net zegt:
Als mijn iOS certificaten verlopen sturen ze me tien mailtjes van te voren, mijn macOS applicaties mogen blijkbaar zomaar verlopen. Vind het niks gek dat een drukke ontwikkelaar dat soort dingen niet direct door heeft
Als workaround bij beveiliging en privacy in je configuratie scherm / tab algemeen:

sta programma's toe die zijn gedownload uit:
- elke willekeurige bron.

Aanzetten.

Heb je dit probleem zoiezo niet.
Beveiliging is een mooi goed, maar je kan het ook overdrijven.

Voor de mensen die dit er niet tussen hebben staan:
Terminal openen > sudo spctl --master-disable

En nog keer terug naar het security/privacy scherm, en je kan elke bron aanzetten.

edit: kleine toevoeging.

[Reactie gewijzigd door itlee op 20 februari 2017 18:02]

En hoevaak heeft een normale gebruiker hier last van? In al die jaren dat ik Apple gebruik hoef je het niet uit te zetten voor normale software. Alleen voor de wat exotischere maar dan gebruik je de rechtmuisknop-->open.
Juist door het uit te zetten kan adware zich zelf ook aanzetten. Goeie tip...
Ik doe beheer over ruim 300 macs, en die optie staat overal uit/installeren vanaf elke bron.

Nog nooit malware gehad op een mac/of een virus.

Je zal nog steeds door een installer van dmg heen moeten lopen. Plus dat een goed ssl cert niet voorkomt dat je een virus/malware kan installeren. (Als je de download/installer draait)
De oplossing voor een probleem mag NOOIT bestaan uit het verlagen van de veiligheid.
Dit is gewoon te debiel voor woorden. Is net zoals mp3 DRM. Zodra de server wegvalt of het certificaat verloopt, kun je het niet meer gebruiken.
en dat is waarom ik niet van vendor lockin houd.

apple heeft hiermee dus de macht om, zodra de ontwikkelaar niet meer wil dokken, hun apps uit te schakelen. het wordt nu gebruikt voor security, maar we weten hopelijk allemaal wat een zekere ben franklin daarover gezegd heeft.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*