Apple, GoDaddy en Google maakten fout bij uitgifte certificaten
Apple, GoDaddy, Google en verschillende andere certificaatautoriteiten hebben een fout gemaakt bij de uitgifte van honderdduizenden certificaten, waarop ook Logius, de ict-organisatie van het ministerie van Binnenlandse Zaken, een onderzoek heeft aangekondigd.
De fout deed zich voor in de software die voor de uitgifte van certificaten wordt gebruikt. Uitgegeven certificaten, die websites gebruiken voor het opzetten van een beveiligde verbinding, horen over een 64-bit serienummer te beschikken. Deze entropie in het serienummer moet voorkomen dat zogeheten hash collisions zijn te gebruiken om certificaten te vervalsen.
EJBCA, een programma waarmee certificaatautoriteiten certificaten genereren, zorgde ervoor dat het serienummer in werkelijkheid 63-bit was. Dit lijkt een klein verschil, maar het verschil tussen 2^64 en 2^63 is meer dan 9 triljoen, legt beveiligingsonderzoeker Adam Caudill uit. In eerste instantie werd gedacht dat er meer dan 2 miljoen foutieve certificaten waren uitgegeven, maar dat aantal is inmiddels naar beneden bijgesteld.
Volgens GoDaddy zijn er van de foutieve certificaten die het heeft uitgegeven nog 12.000 in omloop, terwijl Apple het op 558.000 actieve certificaten houdt. Google denkt dat er sinds 2016 iets meer dan 100.000 certificaten met een 63-bit serienummer zijn uitgegeven. Apple en Google gebruiken de certificaten met name intern en voor partners.
De richtlijnen voor certificaatautoriteiten stellen dat foutieve certificaten na ontdekking binnen vijf dagen moeten worden ingetrokken. Google stelt dat de meeste certificaten inmiddels zijn ingetrokken en de resterende 400 certificaten later deze maand zullen verlopen of worden ingetrokken. GoDaddy is van plan om alle certificaten in kwestie binnen de komende 30 dagen opnieuw uit te geven. Apple zal naar aanleiding van het voorval ook verschillende maatregelen doorvoeren, zo laat het aan Ars Technica weten.
Logius, dat PKIoverheid-certificaten uitgeeft waar overheidsdiensten gebruik van maken, kwam vandaag met de volgende verklaring: "Vanuit de stelselverantwoordelijkheid van Logius als Policy Authority (PA) voor PKIoverheid is een onderzoek gestart naar de uitgifte van servercertificaten. Dit naar aanleiding van een discussie omtrent een verduidelijking van de interpretatie van een bepaalde eis, waarbij mogelijk niet wordt voldaan aan internationaal geldende eisen. Wij houden u op de hoogte."
CAs MUST force the serialNumber to be a non-negative integer.
Dit is verwarrend, want er bestaan meerdere methoden om aan te geven of een (binair) getal negatief of positief is.
https://en.wikipedia.org/wiki/Signed_number_representations
Als het dan zonodig duidelijk een positieve integer moet zijn, dan staat daarmee het eerste bit (sign-bit) al helemaal vast. Vervolgens blijven er nog 63 bits over om serienummers mee te genereren.
Verder mag het serienummer ook langer zijn, want:
Certificate users MUST be able to handle serialNumber values up to 20 octets.
Conforming CAs MUST NOT use serialNumber values longer than 20 octets.
Opvallend is daarna ook de note in RFC5280:
Certificate users SHOULD be prepared to gracefully handle such certificates.
Vervolgens wordt met een enorm getal (meer dan 9 quintiljoen) groot opgeklopt alsof er met 63 bits te weinig entropie zou zijn om hash collisions te kunnen voorkomen. Ik zou zeggen: probeer er eerst maar eens eentje te vinden,
en ik verwacht dat het ontzettend tegenvalt.
Ga je naar 64 bits, dan heb je nog maar 2 keer zoveel als het aantal mogelijke bit-combinaties als van 63 bits.
Lijkt me niet iets om zo moeilijk en ingewikkeld over te doen om dat spul allemaal in te trekken en te vervangen.
Ze sterven vanzelf uit nadat alle cert-verstrekkers voor nieuwe certificaten naar minimaal 64 bits zijn overgestapt.
Gewoon de resterende looptijd van de certificaten met 63 bits serienummers "gracefully" toestaan,
zoals RFC5280 in feite ook al min of meer had gesteld.
Los daarvan is met zo'n groot getal smijten niet zo relvant, is alleen maar aandachttrekkerij. Want bij brute-force aanvallen moet je het wegzetten tegen rekenkracht en dat zijn ook erg grote getallen. Het betreft gewoon een factor 2 verschil. Dus een brute-froce aanval kost nog maar de helft van de eigenlijk beoogde tijd. En dat zou in de praktijk geen risico mogen zijn, anders is de oorspronkelijk boogde 64 bits al veel te krap gekozen. Maar een probleem is het wel, het is zeker een verzwakking. En het combineren van zulk soort problemen werkt exponentieel, dus met een paar van dit soort problemen bij elkaar kan een brute-force aanval haalbaar worden.
Certificate users SHOULD be prepared to gracefully handle such certificates.
Dit is al tientallen jaren gebruikelijk in RFC's. Je MOET je aan bepaalde afspraken houden. Je zou er vervolgens vanuit kunnen gaan dat anderen dat ook doen. Maar iedereen ook weet dat in software fouten zitten of dat sommige partijen RFC's anders uitleggen.
"Gracefull handle" betekent dat je eigen programma niet moet crashen als je een dergelijk certificaat tegenkomt. Je moet een foutmelding genereren zonder dat jouw gebruiker met een hangend systeem opgescheept zit.
"Gracefull handle" betekent niet dat je dat certificaat gewoon moet accepteren alsof het voldoet aan de eisen.
Peter
CAs MUST force the serialNumber to be a non-negative integer.
Dit is verwarrend, want er bestaan meerdere methoden om aan te geven of een (binair) getal negatief of positief is.
https://nl.wikipedia.org/wiki/Byte#Octet_(8_bits)
Om expliciet aan te geven dat men acht bits bedoelt, gebruikt men ook wel het woord octet (bij Philips octad (Engels) of octade (Nederlands)). Mogelijk werd de term byte vermeden omdat het intellectueel eigendom was van IBM.
"Gracefull handle" betekent niet dat je dat certificaat gewoon moet accepteren alsof het voldoet aan de eisen.
Peter
Maar...zou men dan bijv. niet beter kunnen spreken over "gracefully handle potential crashes in case of this issue"?
"Gracefully handle" is voor meerdere interpretaties vatbaar. Dus ook hier onduidelijkheid troef.
Het kan zijn dat men in een bepaalde omgeving met een bepaald jargon ergens ooit eens de vaste betekenis A aan gaf,
maar als buiten dat jargon (of na lange tijd waarin taalbetekenissen verschuiven) een uitdrukking ook (of misschien zelfs wel vaker) betekenis B heeft gekregen, dan kan later iemand anders die tekst gemakkelijk anders opvatten.
Daarom kan jargon denk ik beter worden vermeden in dergelijke officiële documenten.
Maar waar ik dan weer onzeker van wordt is de omschrijving:
Ho wacht, je zou natuurlijk ook het serienummer zelf altijd met een 0 -signbit kunnen laten beginnen
gevolgd door een serienummer van 63 bits....... ; )
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.
