image

Let’s Encrypt meldt incident wegens 1 seconde te lang geldige certificaten

donderdag 10 juni 2021, 16:31 door Redactie, 19 reacties

Certificaatautoriteit heeft een incident gemeld omdat de certificaten die het uitgaf één seconde te lang geldig waren. Let's Encrypt geeft gratis tls-certificaten uit die websites voor het opzetten van een beveiligde verbinding met bezoekers kunnen gebruiken. De certificaten zijn maximaal negentig dagen geldig.

Hierbij nam de software van Let's Encrypt de uitgiftetijd en voegde daar precies 2160 uur aan toe, om zo te bepalen tot wanneer het certificaat geldig is. In Request for Comments (RFC) 5280 staat de geldigheidsduur van een certificaat echter omschreven als de periode waarbij de uitgiftetijd en eindtijd moet worden meegeteld. In het geval van Let's Encrypt werd dit niet gedaan, waardoor er certificaten werden uitgegeven die negentig dagen en één seconde geldig waren.

Aangezien de uitgegeven certificaten niet aan de regels voldoen heeft Let's Encrypt nu melding van een incident gemaakt. Het probleem werd op 8 juni aan de certificaatautoriteit gemeld, die de volgende dag een oplossing had doorgevoerd waardoor certificaten voortaan nog maar 7775999 seconden geldig zijn. Aangezien de impact van het probleem meevalt is besloten om al uitgegeven certificaten niet in te trekken.

Reacties (19)
10-06-2021, 16:48 door Anoniem
Wel netjes dat ze dit gewoon volgens de regels melden. Het lijkt onbetekend maar het versterkt het vertrouwen in de zorgvuldigheid van een CA
10-06-2021, 16:49 door Anoniem
Weinig computers hebben een klok die zo nauwkeurig is.

(daarom ntpupdate installeren)
10-06-2021, 17:17 door Anoniem
Slordig. En netjes gereageerd...
10-06-2021, 19:05 door Anoniem
Mijn God! Hebben die certificaatverstrekkers niets nuttigers te doen als dit? Valt me mee dat ze niet het rootcertificaat waar ze op zitten hebben ingetrokken. Dit is immers zeer ernstig en brengt miljoenen websites in gevaar.
10-06-2021, 19:45 door Anoniem
Door Anoniem: Wel netjes dat ze dit gewoon volgens de regels melden. Het lijkt onbetekend maar het versterkt het vertrouwen in de zorgvuldigheid van een CA

Het geeft inderdaad een goede indruk. En niet melden zou een slechte indruk gegeven hebben.

Er wordt soms wel misbruik gemaakt van die perceptie - hypercorrect de kleinste dingen melden , maar een grote zaak 'vergeten' (of die sneeuwt onder in de vloed van kleine frutsels ).

Op een ietwat andere manier : de term 'bike shedding' is waarschijnlijk bekend.
https://en.wiktionary.org/wiki/bikeshedding
(enorm lang discuzeuren over minimale details (materiaal/kleur van een fietsenstalling) en daarna in twee minuten een beslissing van 100M nemen ) .
Een ervaren vergaderaar zou bewust eerst enkele 'bikeshed' onderwerpen kunnen agenderen, waarna een heikel punt makkelijk erdoor geduwd kan worden .
10-06-2021, 21:26 door Anoniem
Als ik https://bugzilla.mozilla.org/show_bug.cgi?id=1715672 lees, lijken er ook mensen te zijn die vinden dat alle letsencrypt certificaten gerevoked moeten worden. Dat zou wat zijn...
10-06-2021, 21:35 door Anoniem
Zeikers hierop letten, maar stug doorgaan met die amazon cloud, zodat de vs lekker makkelijk illegale letsencrypt certificates kan gebruiken voor de mim.
En de domme massa is meteen weer verblindt/gemanipuleert met de schijn kwaliteit.
11-06-2021, 00:11 door Briolet
In Request for Comments (RFC) 5280 staat de geldigheidsduur van een certificaat echter omschreven als de periode waarbij de uitgiftetijd en eindtijd moet worden meegeteld.

Vreemd, want dan zou je juist verwachten dat hij 1 seconde tekort was. Dat niemand hierboven daarover valt.

In het originele verhaal van Let's Encrypt staat dat deze begin en eindtijd niet meetellen.

the duration between the “not before” and the “not after” timestamps, inclusive.

De toevoeging 'inclusive' houdt in dat ook de exacte tijden uitgesloten moeten worden.
11-06-2021, 02:27 door Anoniem
Denk dat het probleem van origine was begonnen bij de terminologie 'date', waar een programmeur misschien aannam dat een geldigheid van 1 dag dan 2x dezelfde datum krijgt. Om een nul-count te verhelpen werd bijvoorbaat één seconde bijgeteld.

De resolutie om 1 seconde minder dan 90 dagen te tellen is eigenlijk ook in principe incorrect.

De date-timestamps hebben voldoende precisie om exact op de seconde te evalueren.

(geneuzel in de marge)
11-06-2021, 06:45 door botbot - Bijgewerkt: 11-06-2021, 07:06
Door Briolet:
In Request for Comments (RFC) 5280 staat de geldigheidsduur van een certificaat echter omschreven als de periode waarbij de uitgiftetijd en eindtijd moet worden meegeteld.

Vreemd, want dan zou je juist verwachten dat hij 1 seconde tekort was. Dat niemand hierboven daarover valt.

In het originele verhaal van Let's Encrypt staat dat deze begin en eindtijd niet meetellen.

the duration between the “not before” and the “not after” timestamps, inclusive.

De toevoeging 'inclusive' houdt in dat ook de exacte tijden uitgesloten moeten worden.

ter verduidelijking met die laatste zin bedoel je: "not before 12:00 and not after 13:00, inclusive" -->

[12:00 <------->13:00] (inclusive) en dus niet [12:00 <----> 12:59] (exclusive).

Want dat betekenen de termen inclusive en exclusive namelijk. Inclusief de genoemde minuut. Of exclusief de genoemde minuut.
11-06-2021, 06:49 door botbot
Door Anoniem: Zeikers hierop letten, maar stug doorgaan met die amazon cloud, zodat de vs lekker makkelijk illegale letsencrypt certificates kan gebruiken voor de mim.
En de domme massa is meteen weer verblindt/gemanipuleert met de schijn kwaliteit.

Ehh illegale certificates? Leg uit... Het staat er nogal zwaar. Dan is een verduidelijking wel op zijn plaats vind ik.
11-06-2021, 07:04 door botbot - Bijgewerkt: 11-06-2021, 08:02
Moeilijk te lezen artikel, wat er nou precies bedoelt word.

In Request for Comments (RFC) 5280 staat de geldigheidsduur van een certificaat echter omschreven als de periode waarbij de uitgiftetijd en eindtijd moet worden meegeteld. In het geval van Let's Encrypt werd dit niet gedaan, waardoor er certificaten werden uitgegeven die negentig dagen en één seconde geldig waren.

Maar ze hebben het juist wel gedaan en dat is fout:

In hun definitie hebben ze gezegd geldigeheid van 2160 uur. (laten we even 1 uur zeggen voor de het gemak)

In omschrijving hebben ze ervolgens gezegd: niet voor 12 uur en niet na 13 uur, inclusive. Dat werd dus vervolgens berekend als:
[12:00, 12:01, 12:02, ... , 13:00] (inclusive).

Maar 1 uur is 60 minuten. En [12:00, 12:01, 12:02, ... , 13:00] (inclusive) is 61 minuten.

Wat ze hadden moeten doen is: [12:00, 12:01, 12:02, ..., 12:59] (inclusive) want dat zijn 60 minuten.

Het wordt trouwens nog wat "lastiger" omdat ze in hun RFC de komma vreemd hebben staan:


The validity period for a certificate is the period of time from
notBefore through notAfter, inclusive.

Het is namelijk inclusief de eerste seconde, en exclusief de laatste seconde. Dat is altijd weer lastig bij programmataal omschrijven in spreektaal. Omdat je van 0 tot 1 ook meetelt. Mensen tellen in spreektaal niet vanaf 0, maar vanaf 1. En da's weer gelijk aan de eeuwige array discussie. Moet je starten vanaf 0 of vanaf 1. Er zijn programeertalen die zeggen:

myArray = ["a","b","c"] lees je uit als myArray[1], myArray[2], myArray[3].

Maar de meeste programmeertalen zeggen:

myArray = ["a","b","c"] lees je uit als myArray[0], myArray[1], myArray[2]. (Waarom eindig ik op 2 als er 3 elementen in zitten? Redelijke vraag want in spreektaal niet logisch)
11-06-2021, 07:52 door botbot - Bijgewerkt: 11-06-2021, 07:55
De impact van deze fout is trouwens nog minimaler dan wordt verteld. Als je Let's Encrypt instelt zoals wordt aangevolen, dan laat je certbot elke dag draaien. Certbot kijkt of certificaten vernieuwd moeten worden. De geldigheid van certificaten is 90 dagen. Maar certbot begint met het vernieuwen van certificaten na 60 dagen. Dus 30 dagen voor tijd.

Certbot documentatie https://certbot.eff.org/docs/using.html?highlight=renew :

certbot renew

This command attempts to renew any previously-obtained certificates that expire in less than 30 days.

Dus als mensen Let's Encypt installeren zoals dat wordt aanbevolen, dan krijgen ze nooit met deze fout te maken. En ook al zouden ze dat niet doen. Ik krijg van Let's Encrypt keurig ver voor het eindigen van de geldigheid van mijn certficaten een mailtje als dat nog niet in die 30 dagen voor tijd gebeurd is. Dus wil men last krijgen van deze fout moet met a) Let's Encrypt niet installeren zoals wordt aanbevolen. b) waarschuwingen negeren die Let's Encrypt geeft. c) zelf geen maatregelen hebben genomen die de geldigheid van je certificaten checkt.

Zelf heb ik een monitor-progje lopen die keurig dagelijks let's encrypt certificaten checkt die bij al onze klanten zijn geinstalleerd. Mocht er ergens iets falen (en een cerificaat 1 week voor eind nog niet vernieuwd is) omdat een of andere lokale sysadmin certbot uit de crontab heeft gegooid, krijg ik in ieder geval in een Slack channel een bericht.

En ja ik heb het meegemaakt: "Ik ken ik niet, ik ben te beroerd om op te zoeken wat het is, ik ben ook te beroerd om aan de installateur van de server te vragen wat het is, ik comment het gewoon uit of verwijder de regel, en ik zie wel wat er gebeurt" en een dag later denken: "zie je wel de server draait nog en piept niet, was dus niet nodig, laat ik het nu vergeten en verder gaan met mijn leven."
11-06-2021, 08:07 door Anoniem
Door Anoniem: Mijn God! Hebben die certificaatverstrekkers niets nuttigers te doen als dit?
Die seconde is op zich totaal onbenullig. Toch zegt dit nieuwsbericht iets belangrijks.

Bij implementatie van encryptiesystemen doen alle details ertoe, kleine foutjes kunnen tot grote beveiligingslekken leiden. Voor CA's geldt dat nog eens in het kwadraat, omdat er ongelofelijk veel afhankelijk is van hoe goed zij hun werk doen. Daarom moet je van CA's verwachten dat ze extreem pietluttig zorgen dat alle details tot in de puntjes kloppen, en zich niet permitteren dat ze iets overslaan vanuit de inschatting dat een detail in de praktijk niet belangrijk is. Juist dat soort inschattingen kunnen enorme blunders opleveren in dit soort systemen. De houding die je van een CA wil is daarom niet dat ze pragmatisch om probleempjes heen navigeren maar dat ze principieel elke onvolkomenheid die zich aandient corrigeren, geen uitzonderingen maken en daar volkomen dogmatisch in zijn.

Dit bericht laat dat soort dogmatisme zien, en voor een CA is dat precies de houding die nodig is. Die fout van een seconde op zich is onbenullig, hoe ze ermee zijn omgegaan is juist in de verste verte niet onbenullig, en daarom is dit nieuws.
11-06-2021, 13:08 door Reinder
Door Anoniem: Mijn God! Hebben die certificaatverstrekkers niets nuttigers te doen als dit? Valt me mee dat ze niet het rootcertificaat waar ze op zitten hebben ingetrokken. Dit is immers zeer ernstig en brengt miljoenen websites in gevaar.

Nee. Dit is waar zij voor zijn. Hiertoe zijn zij op aard, om certificaten te verstrekken en daarin nauwkeurig te zijn. Dit is hun taak. Ze houden zich niet bezig met het bestrijden van ziekten of het oplossen van oorlog en geweld, daar zijn ze niet voor, dat kunnen ze niet, dat doen ze niet. Ze signen certificaten, punt, en te lang is te lang. De impact van 1s te lang is nihil, dus meer doen dan wat ze gedaan hebben lijkt me inderdaad overbodig, maar het is netjes en zorgvuldig dat ze het gemeld hebben, want te lang is te lang. Een paspoort met een geldigheidsduur van 10 jaar is 1 dag na het verlopen ook ineens ongeldig. Hetzelfde gaat op voor jouw creditcard, om maar eens wat te noemen.

Als je roept "hebben ze niets nuttigers te doen", wat bedoel je dan? Wat voor anders nuttigs zouden ze moeten doen? Wat verwacht je dat ze doen, wat zou je willen? Is het een oproep aan de mensen van LetsEncrypt om de toko op te doeken en zich om te scholen tot bejaardenverzorger of zo? Ze doen precies en exact datgene dat ze moeten zijn: nauwkeurig en precies zijn bij de uitgifte van certificaten.
11-06-2021, 14:43 door Anoniem
@Reinder: Ik ben maar eens gaan kijken naar de RFC in het artikel. Om te kijken of er een verplichting was voor certificaatverstrekkers om alle certificaten 7775999 seconden geldig te laten zijn om ze te laten werken met andere computers. Maar ik kwam iets veel interessanters tegen.

Namelijk dat SSL 1.0 uit ~1995 niet millenniumproof was! En we zijn ondertussen al een paar versies verder dus misschien is het nuttig niet al te veel energie in kleinigheden te steken die de werking van encryptie niet aantasten. En ons te concentreren op echte fouten in de software die we gebruiken en die de werking wel aantasten en het internet onveilig maken.

Anoniem 19:05
11-06-2021, 17:14 door Roger63 - Bijgewerkt: 11-06-2021, 17:54
Gezien de definitie van "validity period" in RFC 5280 zijn Let's Encrypt certificaten 90 dagen + 1 seconde geldig. Er is uiteraard geen enkele regel die dat verbiedt. Maar in v3.2 van hun CPS (Certification Practice Statement) stond bij DV-SSL End Entity Certificate Validity Period "90 days". Daardoor waren de uitgegeven certificaten strijdig met het CPS en was er formeel sprake van een incident. Dat heeft ISRG (de organisatie achter Let's Encrypt) netjes gemeld. Technisch is het uiteraard een totaal non issue.

Ze hebben het probleem opgelost door het CPS aan te passen. In v3.3 (geldig vanaf 8 juni 2021) staat er "Less than 100 days".
15-06-2021, 17:12 door Reinder
Door Anoniem: @Reinder: Ik ben maar eens gaan kijken naar de RFC in het artikel. Om te kijken of er een verplichting was voor certificaatverstrekkers om alle certificaten 7775999 seconden geldig te laten zijn om ze te laten werken met andere computers. Maar ik kwam iets veel interessanters tegen.

Namelijk dat SSL 1.0 uit ~1995 niet millenniumproof was! En we zijn ondertussen al een paar versies verder dus misschien is het nuttig niet al te veel energie in kleinigheden te steken die de werking van encryptie niet aantasten. En ons te concentreren op echte fouten in de software die we gebruiken en die de werking wel aantasten en het internet onveilig maken.

Anoniem 19:05

Dat is a) veel redelijker en bedachtzamer geformuleerd, zonder dat schreeuwerige "zomg wtf hebben ze niets beters te doen!!", waarvoor mijn dank en complimenten, en b) totaal niet relevant. Let's Encrypt gaf certificaten uit voor X + N seconden, terwijl ze volgens de specificaties waaronder ze die certificaten uitgaven slechts geldig mochten zijn voor X seconden. Of N nu 1 seconde is of 1 jaar is niet zo relevant: het was te lang, en dus hebben ze dat opgelost en gemeld. Het al of niet y2k compliant zijn van verouderde specificates waar Let's Encrpyt niets mee doet maakt verder niet uit.

Vraag: Als je het onzinnig acht om het te melden als de door hen uitgegeven certificaten 1 seconde te lang geldig waren, vanaf hoeveel seconden vind je dan dat ze het wel hadden moeten melden? Wat als ze 10s te lang geldig waren, wat had je dan gezegd? en 1 uur? 1 dag? 1 week? 1 maand? Als ze van de specificiaties die ze zelf zeggen te hanteren zouden moeten afwijken, wie bepaald dan op basis waarvan wat dan wel te lang is? Als je zegt "1 dag mag", waarom dan wel 24h en niet 24h plus 1s ? Of dan toch stiekem ook wel want het is maar 1s? Dit is waarom die specificaties er zijn, en daar hebben ze zich heel netjes aan gehouden, en dat sterkt het vertrouwen in die partij die vertrouwen als meest belangrijke dienst heeft.
15-06-2021, 18:44 door Anoniem
Door Reinder: Dat is a) veel redelijker en bedachtzamer geformuleerd, zonder dat schreeuwerige "zomg wtf hebben ze niets beters te doen!!", waarvoor mijn dank en complimenten,

Ik geloof dat dat is wat mijn leraar Nederlands een hyperbool noemde.

en b) totaal niet relevant. Let's Encrypt gaf certificaten uit voor X + N seconden, terwijl ze volgens de specificaties waaronder ze die certificaten uitgaven slechts geldig mochten zijn voor X seconden. Of N nu 1 seconde is of 1 jaar is niet zo relevant: het was te lang, en dus hebben ze dat opgelost en gemeld. Het al of niet y2k compliant zijn van verouderde specificates waar Let's Encrpyt niets mee doet maakt verder niet uit.

Wat als N 0 is? Of mag N alleen een natuurlijk getal van 1 en hoger zijn?

Vraag: Als je het onzinnig acht om het te melden als de door hen uitgegeven certificaten 1 seconde te lang geldig waren, vanaf hoeveel seconden vind je dan dat ze het wel hadden moeten melden? Wat als ze 10s te lang geldig waren, wat had je dan gezegd? en 1 uur? 1 dag? 1 week? 1 maand? Als ze van de specificiaties die ze zelf zeggen te hanteren zouden moeten afwijken, wie bepaald dan op basis waarvan wat dan wel te lang is? Als je zegt "1 dag mag", waarom dan wel 24h en niet 24h plus 1s ? Of dan toch stiekem ook wel want het is maar 1s? Dit is waarom die specificaties er zijn, en daar hebben ze zich heel netjes aan gehouden, en dat sterkt het vertrouwen in die partij die vertrouwen als meest belangrijke dienst heeft.

Van mij hoeft er helemaal geen verloopdatum te zijn. Dit was met PGP 2.x ook niet zo.

Dit is uit RFC 1991:
6.6 Public Key Packet

Purpose. A public key packet defines an RSA public key.

Definition. A public key packet is the concatenation of the
following fields:

(a) packet structure field (2 or 3 bytes);
(b) version number = 2 or 3 (1 byte);;
(c) time stamp of key creation (4 bytes);
(d) validity period in days (0 means forever) (2 bytes);
(e) public-key-cryptosystem (PKC) type (1 byte);
(f) MPI of RSA public modulus n;
(g) MPI of RSA public encryption exponent e.

The validity period is always set to 0.

Volgens sommige hardcore cypherpunks, waaronder ikzelf, is PGP 2.6.3i nog steeds de veiligste versie van PGP. Alleen al omdat het zo weinig sourcecode betreft. De algoritmes die gebruikt worden zijn natuurlijk helemaal ruk en het is 16 bit, dus het draait niet op een 64 bit processor. Maar als je nog een 8086 computer met MS-DOS 6.22 hebt staan... Ik denk dat je Grapperhaus daar wel hoofdpijn mee zou kunnen bezorgen. De FBI vond deze versie ook niet leuk.

Anoniem 19:05
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.