Security Professionals
- ipfw add deny all from eindgebruikers to any
Apple certificate crazyness
PROBLEEM
Naar verluidt [1] heeft Apple aangekondigd dat haar Safari webbrowser, https certificaten uitgegeven op of na 1 september 2020, nog slechts iets meer dan één jaar (398 dagen) als geldig zal accepteren (nu nog ruim 2 jaar).
Nb. het verslag van de meeting van het CA/B forum, waarin Apple dit decreet zou hebben opgelegd, zijn op dit moment nog niet gepubliceerd [2]. Het feit dat digicert in [3] hierover schrijft, betekent waarschijnlijk dat het artikel van The Register klopt.
Eerder deed Ryan Sleevi van Google een vergelijkbaar voorstel [4] dat werd weggestemd door de leden van het CA/B forum. Naar verluidt [3] passeert Apple hiermee democratische besluitvorming in genoemd forum (waarbij opgemerkt moet worden dat veel partijen in dat forum hun eigen agenda hebben, die niet in het belang van de internetveiligheid hoeft te zijn).
[1] https://www.theregister.co.uk/2020/02/20/apple_shorter_cert_lifetime/
[2] https://cabforum.org/category/proceedings/minutes/
[3] https://www.digicert.com/position-on-1-year-certificates/
[4] https://www.theregister.co.uk/2019/08/13/site_certificate_lifetimes/
WAAROM EEN SLECHT PLAN
Ik heb geen enkele relatie met welke certificaatuitgever dan ook, maar vind dit een heel slecht plan. De primaire reden daarvoor is dat het organisaties meer geld zal kosten om betrouwbare certificaten te kopen: het fatsoenlijk vaststellen van de identiteit van de aanvrager, en of deze legitiem in het bezit is van een domeinnaam, kost tijd en dus geld.
Een voordeel zou kunnen zijn dat dit certificaatuitgevers dwingt om de verlenging van certificaten te automatiseren, waarbij het certificaatbezit uiteindelijk niet duurder hoeft te zijn. Echter elke wijziging op een systeem brengt risico's met zich mee, waar aanvallers misbruik van kunnen proberen te maken. Als vóór elke verlenging geen nieuw sleutelpaar wordt gegenereerd (d.w.z. het oude sleutelpaar hergebruikt wordt), is het hele proces natuurlijk zinloos. De kans op onbeschikbaarheid neemt ook toe (als er iets fout gaat in het update-proces, of kort na de update de server defect raakt terwijl de private key nog niet geback-upped is).
Als certificaatuitgevers niet snel het verlengen automatiseren, zou het gevolg hiervan kunnen zijn dat het organisaties naar DV (Domain Validated) certificaten drijft, die uitsluitend op de (slechte) betrouwbaarheid van DNS gebaseerd zijn. Certificaten die bovendien niets zeggen over of de aanvrager de legitieme eigenaar van een domein is. Zie ook [5].
[5] https://www.security.nl/posting/509888/Let's+Encrypt+net+zo+onveilig+als+DNS#posting510166
MOGELIJKE REDENEN VOOR APPLE
Redenen voor Apple om dit te doen zouden kunnen zijn (naast dat zij wellicht zelf certificaten willen verkopen):
1) Als een private key van een webserver "gestolen" wordt (in de zin van ongeautoriseerd gekopieerd), beperk je de tijd waarin daarmee kwaad kan worden gedaan. Dit is echter dezelfde drogreden als regelmatig je wachtwoord vervangen: criminelen slaan meestal zo snel mogelijk daarna hun slag, omdat er vaak snel meerdere manieren zijn om hun kwaadaardige acties te mitigeren.
2) De angst dat bijvoorbeeld quantum cryptografie sneller dan verwacht een doorbraak beleeft waarmee de private key uit de public key in een certificaat herleid zou kunnen worden. Ook zouden de gebruikte cryptografische protocollen om een andere reden onveilig kunnen worden geacht.
M.b.t. beide argumenten heeft Apple boter op haar hoofd (Google ook trouwens: [6]). In het recente Eclypsium rapport [7], waar [8] naar verwijst, staat dat Apple, als enige, code signing signatures goed voor elkaar heeft. Ook daar worden certificaten voor gebruikt. En die verlopen niet al na 398 dagen, want dan zou de betreffende code al snel onbruikbaar zijn. Private keys behorende bij code signing certificaten kunnen ook gestolen worden, en het apparaat waar ze in zitten kan zelfs misbruikt worden om namens de bezitter van de private key code te ondertekenen (de aanvaller hoeft dan zelf geen toegang tot de private key te hebben).
[6] Uit https://developer.android.com/studio/publish/app-signing (het advies is minstens 25 jaar geldig):
[8] https://www.security.nl/posting/644537/Laptops+Dell%2C+HP+en+Lenovo+accepteren+ongesigneerde+firmware
CONCLUSIE
Na het schrappen van het tonen van EV (Extended Certificate) gegevens, het recentelijk verlagen van de geldigheidsduur van 3 naar 2 jaar is dit de volgende stap in de afbraak van de betrouwbaarheid van https certificaten. Dit is heel slecht voor het vertrouwen dat internetters in de authenticiteit van belangrijke websites moeten kunnen hebben, met name van organisaties die financiële gegevens (o.a. banken), persoons- en/of medische gegevens verwerken.
Als Apple in Safari voortaan de gebruiker een helder onderscheid zou laten zien tussen de verschillende soorten certificaten (DV, OV en EV) zou ik vrede hebben met dit -anders onzalige- plan.
Naar verluidt [1] heeft Apple aangekondigd dat haar Safari webbrowser, https certificaten uitgegeven op of na 1 september 2020, nog slechts iets meer dan één jaar (398 dagen) als geldig zal accepteren (nu nog ruim 2 jaar).
Nb. het verslag van de meeting van het CA/B forum, waarin Apple dit decreet zou hebben opgelegd, zijn op dit moment nog niet gepubliceerd [2]. Het feit dat digicert in [3] hierover schrijft, betekent waarschijnlijk dat het artikel van The Register klopt.
Eerder deed Ryan Sleevi van Google een vergelijkbaar voorstel [4] dat werd weggestemd door de leden van het CA/B forum. Naar verluidt [3] passeert Apple hiermee democratische besluitvorming in genoemd forum (waarbij opgemerkt moet worden dat veel partijen in dat forum hun eigen agenda hebben, die niet in het belang van de internetveiligheid hoeft te zijn).
[1] https://www.theregister.co.uk/2020/02/20/apple_shorter_cert_lifetime/
[2] https://cabforum.org/category/proceedings/minutes/
[3] https://www.digicert.com/position-on-1-year-certificates/
[4] https://www.theregister.co.uk/2019/08/13/site_certificate_lifetimes/
WAAROM EEN SLECHT PLAN
Ik heb geen enkele relatie met welke certificaatuitgever dan ook, maar vind dit een heel slecht plan. De primaire reden daarvoor is dat het organisaties meer geld zal kosten om betrouwbare certificaten te kopen: het fatsoenlijk vaststellen van de identiteit van de aanvrager, en of deze legitiem in het bezit is van een domeinnaam, kost tijd en dus geld.
Een voordeel zou kunnen zijn dat dit certificaatuitgevers dwingt om de verlenging van certificaten te automatiseren, waarbij het certificaatbezit uiteindelijk niet duurder hoeft te zijn. Echter elke wijziging op een systeem brengt risico's met zich mee, waar aanvallers misbruik van kunnen proberen te maken. Als vóór elke verlenging geen nieuw sleutelpaar wordt gegenereerd (d.w.z. het oude sleutelpaar hergebruikt wordt), is het hele proces natuurlijk zinloos. De kans op onbeschikbaarheid neemt ook toe (als er iets fout gaat in het update-proces, of kort na de update de server defect raakt terwijl de private key nog niet geback-upped is).
Als certificaatuitgevers niet snel het verlengen automatiseren, zou het gevolg hiervan kunnen zijn dat het organisaties naar DV (Domain Validated) certificaten drijft, die uitsluitend op de (slechte) betrouwbaarheid van DNS gebaseerd zijn. Certificaten die bovendien niets zeggen over of de aanvrager de legitieme eigenaar van een domein is. Zie ook [5].
[5] https://www.security.nl/posting/509888/Let's+Encrypt+net+zo+onveilig+als+DNS#posting510166
MOGELIJKE REDENEN VOOR APPLE
Redenen voor Apple om dit te doen zouden kunnen zijn (naast dat zij wellicht zelf certificaten willen verkopen):
1) Als een private key van een webserver "gestolen" wordt (in de zin van ongeautoriseerd gekopieerd), beperk je de tijd waarin daarmee kwaad kan worden gedaan. Dit is echter dezelfde drogreden als regelmatig je wachtwoord vervangen: criminelen slaan meestal zo snel mogelijk daarna hun slag, omdat er vaak snel meerdere manieren zijn om hun kwaadaardige acties te mitigeren.
2) De angst dat bijvoorbeeld quantum cryptografie sneller dan verwacht een doorbraak beleeft waarmee de private key uit de public key in een certificaat herleid zou kunnen worden. Ook zouden de gebruikte cryptografische protocollen om een andere reden onveilig kunnen worden geacht.
M.b.t. beide argumenten heeft Apple boter op haar hoofd (Google ook trouwens: [6]). In het recente Eclypsium rapport [7], waar [8] naar verwijst, staat dat Apple, als enige, code signing signatures goed voor elkaar heeft. Ook daar worden certificaten voor gebruikt. En die verlopen niet al na 398 dagen, want dan zou de betreffende code al snel onbruikbaar zijn. Private keys behorende bij code signing certificaten kunnen ook gestolen worden, en het apparaat waar ze in zitten kan zelfs misbruikt worden om namens de bezitter van de private key code te ondertekenen (de aanvaller hoeft dan zelf geen toegang tot de private key te hebben).
[6] Uit https://developer.android.com/studio/publish/app-signing (het advies is minstens 25 jaar geldig):
If you plan to publish your apps on Google Play, the key you use to sign your app must have a validity period ending after 22 October 2033
[7] https://eclypsium.com/wp-content/uploads/2020/02/Eclypsium-Unsigned-Peripheral-Firmware-Research.pdf[8] https://www.security.nl/posting/644537/Laptops+Dell%2C+HP+en+Lenovo+accepteren+ongesigneerde+firmware
CONCLUSIE
Na het schrappen van het tonen van EV (Extended Certificate) gegevens, het recentelijk verlagen van de geldigheidsduur van 3 naar 2 jaar is dit de volgende stap in de afbraak van de betrouwbaarheid van https certificaten. Dit is heel slecht voor het vertrouwen dat internetters in de authenticiteit van belangrijke websites moeten kunnen hebben, met name van organisaties die financiële gegevens (o.a. banken), persoons- en/of medische gegevens verwerken.
Als Apple in Safari voortaan de gebruiker een helder onderscheid zou laten zien tussen de verschillende soorten certificaten (DV, OV en EV) zou ik vrede hebben met dit -anders onzalige- plan.
Reacties (10)
21-02-2020, 11:07 door
johanw
Misschien is de beste reactie om dit gewoon te negeren en Safari gebruikers te melden dat ze maar een betere browser moeten gebruiken als ze er niet op komen.
Door johanw: Misschien is de beste reactie om dit gewoon te negeren en Safari gebruikers te melden dat ze maar een betere browser moeten gebruiken als ze er niet op komen.
En als dat niet mogelijk is (ik meen dat het gebruik van de browser engine van Apple op iPhone en iPad niet te vermeiden is, mensen adviseren om naar een ander systeem over te stappen.
21-02-2020, 11:39 door
Erik van Straten
De redactie heeft hier zojuist een artikel over gepubliceerd, zie https://www.security.nl/posting/645057/Apple+wil+levensduur+TLS-certificaten+verkorten+naar+13+maanden.
@ErikvanStraten. Nou heb ik Apple, maar de browser Safari gebruik in alleen in uitzonderlijke gevallen. Zelf gebruik ik gewoon standaard Firefox en die is zo ingesteld (about:config) dat er websites zijn die niet altijd werken. Dus een groot probleem zal het voor mij niet worden als Apple deze certificaten issue gaat doorvoeren. Bovendien lijkt het mij gewoon wijzer dat op een systeem meerdere browsers geïnstalleerd zijn.
Het laten expireren van certificaten levert problemen op.
Het schijnt dat een website zelfs compleet onbereikbaar wordt als de site ook is opgenomen in de HSTS preload lijst.
En dat kan natuurlijk hele kwalijke gevolgen hebben.
Door nu een vaste, gemakkelijk te onthouden periodeduur te kiezen, vergeet men minder snel om het te vervangen.
Een ander punt is dat je niet wil dat probleemcertificaten te lang geldig blijven.
En als de max. geldigheidsduur dus niet te lang is, verlopen ze na niet al te lange tijd vanzelf.
13 maanden is helemaal zo gek nog niet, want dat is 1 jaar + max. 1 maand om een nieuw certificaat te regelen.
Zo is er een jaarlijks ritme, en wordt het minder snel vergeten.
Het is alleen een beetje pech dat een jaar maar ca. 365 dagen duurt en een geschiktere simpele periode is er eigenlijk niet: een kwartaal is wel erg kort, en een decenium of een eeuw duurt te lang met wederom kans op vergeten.
Overigens denk ik dat er wel een alternatief is.
Er zou eigenlijk standaard een tool actief moeten zijn die bijv. een maand voor expiratie dagelijks een waarschuwing geeft
aan de administrator (of aan de CA, die vervolgens de houder van het certificaat inlicht)
Volgens mij is dat zelfs wel te automatiseren.
Maar of de wil er is?....
Het schijnt dat een website zelfs compleet onbereikbaar wordt als de site ook is opgenomen in de HSTS preload lijst.
En dat kan natuurlijk hele kwalijke gevolgen hebben.
Door nu een vaste, gemakkelijk te onthouden periodeduur te kiezen, vergeet men minder snel om het te vervangen.
Een ander punt is dat je niet wil dat probleemcertificaten te lang geldig blijven.
En als de max. geldigheidsduur dus niet te lang is, verlopen ze na niet al te lange tijd vanzelf.
13 maanden is helemaal zo gek nog niet, want dat is 1 jaar + max. 1 maand om een nieuw certificaat te regelen.
Zo is er een jaarlijks ritme, en wordt het minder snel vergeten.
Het is alleen een beetje pech dat een jaar maar ca. 365 dagen duurt en een geschiktere simpele periode is er eigenlijk niet: een kwartaal is wel erg kort, en een decenium of een eeuw duurt te lang met wederom kans op vergeten.
Overigens denk ik dat er wel een alternatief is.
Er zou eigenlijk standaard een tool actief moeten zijn die bijv. een maand voor expiratie dagelijks een waarschuwing geeft
aan de administrator (of aan de CA, die vervolgens de houder van het certificaat inlicht)
Volgens mij is dat zelfs wel te automatiseren.
Maar of de wil er is?....
Door Anoniem:
En als dat niet mogelijk is (ik meen dat het gebruik van de browser engine van Apple op iPhone en iPad niet te vermeiden is, mensen adviseren om naar een ander systeem over te stappen.
Door johanw: Misschien is de beste reactie om dit gewoon te negeren en Safari gebruikers te melden dat ze maar een betere browser moeten gebruiken als ze er niet op komen.
En als dat niet mogelijk is (ik meen dat het gebruik van de browser engine van Apple op iPhone en iPad niet te vermeiden is, mensen adviseren om naar een ander systeem over te stappen.
Veel success met je winkel. Je bent meteen klanten kwijt.
Een mogelijk voordeel is wel: als je iets elke 2 jaar doet vergeet je het. Als je het elk jaar doet gaan we dit allemaal op den duur rond de 1e van een maand doen en onthoud iedereen het.
Nadeeel:
Vergeten we vast straks om het intermediate certificaat te vervangen als dat vervalt ;)
Nadeeel:
Vergeten we vast straks om het intermediate certificaat te vervangen als dat vervalt ;)
22-02-2020, 15:05 door
Briolet
Door Anoniem: Een mogelijk voordeel is wel: als je iets elke 2 jaar doet vergeet je het. Als je het elk jaar doet gaan we dit allemaal op den duur rond de 1e van een maand doen en onthoud iedereen het.
Eens per jaar kun je ook vergeten. En ik heb al 6 keer een lustrum niet vergeten.
Ik verwacht dat elk serieus bedrijf deze vervangingsdatum in een agenda zet. En dat kun je jaren in de toekomst doen. Op er een entry van maken die elke tig jaar herhaalt. Vergeten is dus geen argument. Wat wel kan is dat de routine verdwijnt. Zeker als ook de personele bezetting regelmatig wisselt.
Erik van Straten De primaire reden daarvoor is dat het organisaties meer geld zal kosten om betrouwbare certificaten te kopen: het fatsoenlijk vaststellen van de identiteit van de aanvrager, en of deze legitiem in het bezit is van een domeinnaam, kost tijd en dus geld.
Dat lijkt me juist geen reden bij het vaker verlengen. De kosten van controle zitten in de eerste aanvraag en niet in de verlengingen want die gebruiken dezelfde domeinnaam(en) en je stuurt het verlengde certificaat naar hetzelfde bedrijf.
Door Briolet:
Dat lijkt me juist geen reden bij het vaker verlengen. De kosten van controle zitten in de eerste aanvraag en niet in de verlengingen want die gebruiken dezelfde domeinnaam(en) en je stuurt het verlengde certificaat naar hetzelfde bedrijf.
Bij DV-certificaten is dat simpel, want daar speelt het aspect "bedrijf" geen enkele rol. Erik van Straten De primaire reden daarvoor is dat het organisaties meer geld zal kosten om betrouwbare certificaten te kopen: het fatsoenlijk vaststellen van de identiteit van de aanvrager, en of deze legitiem in het bezit is van een domeinnaam, kost tijd en dus geld.
Dat lijkt me juist geen reden bij het vaker verlengen. De kosten van controle zitten in de eerste aanvraag en niet in de verlengingen want die gebruiken dezelfde domeinnaam(en) en je stuurt het verlengde certificaat naar hetzelfde bedrijf.
Overigens was de tot voor kort door Let's Encrypt gebruikte methode minder veilig dan menigeen beweerde, zie halverwege https://security.nl/posting/645176.
Zo simpel ligt dat echter niet bij OV- en EV-certificaten. Iedereen kan een sleutelpaar genereren, een CSR (Certificate Signing Request) maken voor bijvoorbeeld politie.nl en daar een "certificaatverlenging" voor aanvragen. Dat zal niet snel lukken, maar wat als je de mailbox van admin@ gehacked hebt? Elke CSP (Certificate Services Provider) zal zich op z'n minst aan haar eigen regels voor het verstrekken en verlengen van certificaten moeten houden. Naast vaststellen dat de aanvrager (nog steeds) geautoriseerd is, zal elke fatsoenlijke CSP moeten vaststellen dat alle hoofddomeinen, waar het certificaat geldig voor is, (nog steeds) in handen van de betreffende organisatie zijn.
En als dat allemaal niet nodig zou zijn bij verlenging (en bijv. het aantonen van het bezit van de private key horend bij het huidige certificaat zou volstaan), vraag ik me helemaal af waarom de veiligheid voor gebruikers zou toenemen - zoals Apple als reden opgeeft in haar decreet.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
